Manual de migración de correo transaccional

El reto central de la migración

Para migrar el correo transaccional sin perder observabilidad, debe desacoplar el disparador del envío de la implementación del proveedor. La estrategia consiste en implementar una capa de abstracción de proveedores que permita el envío dual (en sombra) y la correspondencia de eventos. Si enruta un pequeño porcentaje del tráfico al nuevo proveedor mientras sigue registrando los eventos de entrega mediante webhooks, puede verificar que el nuevo proveedor acepta el correo y que su canal de observabilidad captura los resultados antes de cambiar el flujo principal.

Por qué se producen las migraciones

La mayoría de las migraciones responden al costo, a la experiencia de desarrollo o al cumplimiento normativo. Por ejemplo, la diferencia de costo entre proveedores es considerable. Según los precios de Amazon SES, el envío a la carta cuesta 0.10 USD por cada 1.000 correos. En cambio, los precios de Postmark empiezan en 15 USD al mes por 10.000 correos, con excedentes de entre 1.80 y 1.20 USD por cada 1.000. Enviar 50.000 correos cuesta unos 5 USD con SES a la carta, frente a aproximadamente 66 USD con los planes de Postmark.

Otros motivos son la adopción de telemetría minimizada para la privacidad y alojada solo en la UE, o la necesidad de una mejor preparación para agentes (como la compatibilidad con servidores MCP). Sea cual sea el motivo, el riesgo es el mismo: un punto ciego en su canal de entrega durante la transición.

Fase 1: la capa de abstracción

Si su aplicación llama directamente al SDK de un proveedor desde la lógica de negocio, queda atada a él. Necesita un envoltorio que estandarice la solicitud y la respuesta.

El payload unificado

Defina un esquema interno independiente del proveedor. Así su aplicación no tiene que preocuparse de si la API subyacente espera to como array o como cadena única.

{ "message_id": "msg_12345", "recipient": "user@example.com", "template_id": "welcome_email", "variables": { "name": "Alex" }, "idempotency_key": "unique_request_id_789" }

Cuando trabaja con agentes de IA o flujos automatizados, es fundamental tratar el correo como un efecto secundario externo. Debe usar una clave de idempotencia para garantizar que un bucle de agente reintentado no envíe cinco veces el mismo correo transaccional a un usuario.

Fase 2: configuración de DNS e identidad

Antes de enviar un solo correo, debe establecer su identidad. Aquí es donde fallan la mayoría de las migraciones, por retrasos en la propagación del DNS o errores de configuración.

1. Verifique los dominios: agregue los registros DKIM y SPF del nuevo proveedor. Use una herramienta como el Verificador de DNS de correo de SendHQ para comprobar que sus registros están publicados y tienen el formato correcto.
2. Entienda los registros: asegúrese de comprender la diferencia entre SPF (que autoriza al servidor) y DKIM (que firma el mensaje). Si usa varios proveedores durante una migración, su registro SPF debe incluir a ambos.
3. Alineación DMARC: asegúrese de que su política DMARC esté en p=none durante la fase inicial de la migración para evitar rebotes permanentes si la alineación no es del todo correcta. Consulte la guía de SendHQ sobre DKIM, SPF y DMARC para ver los pasos de configuración detallados.

Fase 3: el envío en sombra (envío dual)

No haga un cambio brusco. En su lugar, implemente una lógica de enrutamiento que envíe al proveedor principal y, de forma asíncrona, envíe un duplicado (o un porcentaje muestreado) al nuevo proveedor.

Lógica de implementación

async function sendEmail(payload) { // Primary send (Current Provider) const primaryResult = await primaryProvider.send(payload); // Shadow send (New Provider) - do not await or block the main thread if (Math.random() < 0.1) { // 10% sample newProvider.send(payload).catch(err => console.error("Shadow send failed", err) ); } return primaryResult; }

Durante esta fase, está probando la aceptación por el proveedor: el momento en que el proveedor dice "Sí, acepto este mensaje". Es distinto de la entrega (el mensaje llega al servidor receptor) y de la llegada a la bandeja de entrada (el mensaje evita la carpeta de spam).

Fase 4: observabilidad y paridad de eventos

La observabilidad es la capacidad de seguir un mensaje desde sent hasta delivered o bounced. Cada proveedor tiene un esquema de webhook distinto.

Correspondencia de eventos

Cree una tabla de correspondencias para normalizar los eventos en su base de datos interna:

Evento interno | Amazon SES | Resend | Postmark | SendHQ

sent | Send | sent | Sent | sent

delivered | Delivery | delivered | Delivered | delivered

bounced | Bounce | bounced | Bounced | bounced

complaint | Complaint | complained | Complaint | complaint

Gestión de los payloads de webhook

Su listener de webhooks debe ser genérico. Si recibe un payload de un nuevo proveedor, debe pasar por un transformador antes de llegar a su motor de análisis.

function transformWebhook(provider, payload) { switch(provider) { case 'resend': return { event: payload.data.delivered ? 'delivered' : 'failed', id: payload.data.id }; case 'sendhq': return { event: payload.event, id: payload.message_id }; default: throw new Error("Unknown provider"); } }

Fase 5: el cambio gradual

Una vez que haya verificado que el nuevo proveedor acepta el correo y que sus webhooks asignan correctamente los eventos, pase a una distribución ponderada.

1. 1 % del tráfico: enrute el 1 % de todo el correo transaccional al nuevo proveedor. Supervise las tasas de rebote.
2. 10 % del tráfico: aumente la carga. Compruebe los límites de frecuencia. Por ejemplo, el plan gratuito de Resend tiene un máximo de 100 correos al día, lo que puede ser un cuello de botella durante las pruebas.
3. 50 % del tráfico: es la prueba de estabilidad. Asegúrese de que la latencia sigue siendo aceptable.
4. 100 % del tráfico: cambio definitivo.

Solución de los fallos de migración más habituales

La "pérdida silenciosa"

Algunos proveedores aceptan el correo (202 Accepted), pero lo descartan internamente por filtros de contenido o identidades de remitente no verificadas. Por eso la fase de envío en sombra no es negociable. Si tiene muchos eventos sent pero pocos eventos delivered, tiene un problema de entrega, no de API.

Picos por límites de frecuencia

Cada proveedor tiene límites de ráfaga distintos. Los precios de Mailgun y los precios de SendGrid (que ahora usa una prueba de 60 días como plan gratuito) suelen incluir cuotas de rendimiento diferentes. Si migra desde una cuenta con límites altos a una cuenta nueva, es posible que se le aplique un límite de frecuencia. Implemente una cola (como RabbitMQ o SQS) para suavizar los picos.

Fallos de idempotencia

Al cambiar de proveedor, podría provocar por accidente el reintento de un lote. Si usa agentes de IA para enviar correos, asegúrese de que el agente proporcione un ID de solicitud único. Si el agente usa un servidor MCP para interactuar con su API de correo, la API debería rechazar los valores de idempotency_key duplicados dentro de una ventana de 24 horas.

Lista de comprobación para la migración

• Capa de abstracción implementada (payload independiente del proveedor).
• Registros DNS (SPF, DKIM) agregados para el nuevo proveedor.
• DNS verificado mediante sendhq.cc/tools/email-dns-checker.
• El receptor de webhooks se actualizó para manejar los esquemas del nuevo proveedor.
• Tabla de asignación de eventos completada (Enviado, Entregado, Rebotado, Queja).
• Envío en sombra activo del 1 % al 10 %.
• Claves de idempotencia verificadas para envíos impulsados por agentes.
• Aumento gradual (1 %, 10 %, 50 %, 100 %).
• Claves de API del proveedor anterior revocadas después de 7 días de estabilidad del 100 %.

Reflexiones finales sobre la elección de proveedor

Elegir un proveedor es un equilibrio entre costo y velocidad de desarrollo. Si necesita el costo más bajo posible, Amazon SES es difícil de superar con 0.10 USD por cada 1.000 correos a la carta, aunque sus nuevos planes escalonados (Essentials a 0.16 USD, Pro a 0.22 USD) introducen estructuras de costo distintas desde el 21 de julio de 2026. Si necesita una API moderna con preparación para agentes integrada y telemetría minimizada para la privacidad y alojada solo en la UE, SendHQ ofrece una alternativa simplificada.

Sea cual sea el proveedor, el objetivo es que su equipo de ingeniería no quede atado al SDK de un proveedor concreto. Al tratar el correo como un efecto secundario estandarizado, convierte una migración de alto riesgo en un cambio de configuración rutinario.

Obtenga más información sobre cómo crear flujos de correo confiables en https://sendhq.cc.