Lista de verificación para llevar a producción una API de correo transaccional

Preparación para producción del correo transaccional

Para lanzar una API de correo transaccional, debe verificar tres capas distintas: la aceptación del proveedor (la API acepta su solicitud), la entrega (el servidor receptor acepta el correo) y la llegada a la bandeja de entrada (el correo llega al usuario). Un sistema listo para producción requiere registros DNS verificados, una estrategia de idempotencia sólida para evitar envíos duplicados, una gestión completa de webhooks para los eventos de entrega y un modelo de costos que escale con su volumen. Si alguno de estos elementos falla, se arriesga a perder datos o a dañar su reputación.

1. Verificación del dominio y del DNS

Enviar correo desde un dominio no verificado es la forma segura de activar los filtros de spam o de que el MTA (Mail Transfer Agent) receptor lo rechace directamente. Debe demostrar que el dominio de envío es suyo.

El trío esencial: SPF, DKIM y DMARC

• SPF (Sender Policy Framework): un registro DNS que enumera qué direcciones IP o servicios están autorizados a enviar correo en nombre de su dominio. Sin él, los receptores no pueden verificar si el remitente está suplantando su dominio. Consulte nuestra entrada del glosario sobre SPF para más detalles.
• DKIM (DomainKeys Identified Mail): agrega una firma criptográfica al encabezado del correo. Así se garantiza que el contenido no se alteró en tránsito.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): le indica al receptor qué hacer si SPF o DKIM fallan (none, quarantine o reject).

Antes de pasar a producción, use una herramienta como el Verificador de DNS de correo de SendHQ para comprobar que estos registros se propagan correctamente. Encontrará una guía paso a paso detallada en nuestra guía de DKIM, SPF y DMARC.

Lista de verificación

• El registro SPF incluye todas las fuentes de envío.
• Las claves públicas de DKIM están publicadas en DNS y coinciden con las claves privadas que usa la API.
• La política DMARC está configurada (comience con p=none para el monitoreo y luego pase a p=reject).
• El DNS inverso (rDNS) está configurado para sus IP de envío (si usa IP dedicadas).

2. Integración con la API y confiabilidad

Los correos transaccionales son eventos de la ruta crítica (restablecimientos de contraseña, facturas, 2FA). Tratar la API de correo como una llamada HTTP de «enviar y olvidar» es la receta perfecta para incidentes en producción.

Idempotencia y prevención de duplicados

Los timeouts de red son inevitables. Si su aplicación envía una solicitud a la API de correo pero la conexión se corta antes de que llegue la respuesta, su lógica de reintentos podría enviar el mismo correo dos veces. Esto es especialmente peligroso con agentes de IA o flujos de trabajo automatizados.

Implemente una clave de idempotencia en los encabezados de sus solicitudes. Así, si se envía la misma clave dos veces dentro de una ventana determinada, el proveedor devuelve la respuesta correcta original sin enviar un segundo correo.

{ "idempotency_key": "req_88234abc123", "to": "user@example.com", "template_id": "welcome_email", "variables": { "name": "Alice" } }

Agentes de IA y comunicación A2A

Al integrar agentes de IA (mediante servidores MCP o similares), debe tratar el correo como un efecto secundario externo. Los agentes pueden entrar en bucles o alucinar disparadores. Nunca permita que un agente desencadene un envío en producción sin al menos una de las siguientes medidas:

1. Intervención humana (HITL): un paso de aprobación manual en su interfaz.
2. Limitación de frecuencia estricta: una cuota por usuario o por agente para evitar spam accidental.
3. Restricciones de plantilla: obligar a los agentes a usar plantillas alojadas en las que solo se pueden cambiar las variables, para impedir que el agente escriba contenido arbitrario (y potencialmente dañino).

3. Gestión de errores y observabilidad

Su sistema debe distinguir entre errores transitorios (que se pueden reintentar) y errores permanentes (que no se pueden reintentar).

Clasificación de errores

Tipo de error | Ejemplo | Acción

Transitorio | 429 Too Many Requests, 503 Service Unavailable | Reintento con backoff exponencial

Permanente | 400 Bad Request (correo no válido), 401 Unauthorized | Registrar el error, alertar al desarrollador, no reintentar

Entrega | 550 User Unknown, 554 Message Rejected | Actualizar la lista de supresión, notificar al usuario

Integración de webhooks

Las respuestas de la API solo le indican si el proveedor aceptó el mensaje. Para saber si se entregó, necesita webhooks. Debería registrar estos eventos en su base de datos:

• Sent: el proveedor entregó el correo al MTA.
• Delivered: el servidor receptor aceptó el correo.
• Bounced: el servidor receptor rechazó el correo (rebote permanente o hard bounce = definitivo; rebote temporal o soft bounce = transitorio).
• Complained: el usuario marcó el correo como spam.

Ejemplo de payload de webhook para un evento de entrega:

{ "event": "delivered", "message_id": "msg_12345", "timestamp": "2026-09-15T10:00:00Z", "recipient": "user@example.com" }

4. Análisis de costos y compensaciones entre proveedores

Elegir un proveedor es un equilibrio entre la experiencia del desarrollador (DX), el costo y la carga de infraestructura. Según los datos de precios de septiembre de 2026, la variación de costos es considerable.

Comparativa de precios de proveedores

• Amazon SES: la opción de menor costo para volúmenes altos. El precio de pago por uso es de 0.10 USD por cada 1.000 correos (precios de Amazon SES). Los nuevos planes por niveles (21 de julio de 2026) incluyen Essentials (0.16 USD/1k), Pro (0.22 USD/1k + 105 USD/mes/región) y Enterprise (0.23 USD/1k + 500 USD/mes).
• Resend: centrado en la DX. El plan gratuito es de 3.000 correos/mes (con un máximo de 100/día). Pro cuesta 20 USD/mes por 50.000 correos, con excedentes a 0.90 USD por cada 1.000 (precios de Resend).
• SendGrid: Essentials empieza en 19.95 USD/mes. El plan gratuito ahora es una prueba de 60 días (precios de SendGrid).
• Mailgun: 15 USD/mes por 10.000 correos, con excedentes de entre 1.80 y 1.10 USD por cada 1.000 (precios de Mailgun).
• Postmark: 15 USD/mes por 10.000 correos, con excedentes de entre 1.80 y 1.20 USD por cada 1.000 (precios de Postmark).

La «brecha de escala»

Piense en el costo de enviar 50.000 correos transaccionales. Con Amazon SES en modalidad de pago por uso, cuesta aproximadamente 5 USD. Con los precios por niveles de Postmark, el mismo volumen cuesta unos 66 USD. Para la mayoría de las startups, la DX de una API especializada justifica el sobreprecio, pero para agentes de IA de gran volumen el modelo de SES suele ser necesario.

5. Lista de verificación final para producción

Antes de desplegar en producción, repase esta lista de verificación final:

Infraestructura

• Los registros DNS (SPF, DKIM, DMARC) están verificados y activos.
• Las claves de API tienen alcance por espacio de trabajo y se almacenan en una bóveda segura (no en el código).
• Los endpoints de webhook son públicos, seguros y pueden manejar picos de tráfico simultáneos.

Lógica

• Las claves de idempotencia están implementadas para todas las solicitudes de envío.
• La lógica de reintento usa backoff exponencial para errores 429 y 5xx.
• Se gestionan las listas de supresión (no intente reenviar a direcciones con rebote permanente).
• Los activadores de agentes de IA tienen un paso de aprobación humana o límites de frecuencia estrictos.

Monitoreo

• Hay alertas configuradas para aumentos repentinos de respuestas 4xx/5xx de la API.
• El panel rastrea las tasas de entrega frente a las tasas de rebotes.
• La telemetría minimiza los datos privados y cumple las leyes regionales (por ejemplo, almacenamiento solo en la UE).

Resumen

El correo transaccional es un efecto secundario que puede romper fácilmente la confiabilidad de su aplicación o la reputación de su dominio. Si separa la aceptación del proveedor de la entrega y se centra en la idempotencia y la verificación de DNS, construirá un sistema resistente a los fallos de red y a las caídas del proveedor. Para los equipos que necesitan un enfoque simplificado del envío desde dominios verificados y una infraestructura preparada para agentes, descubra las capacidades en https://sendhq.cc.