Por qué los mismos 50.000 correos cuestan $5 o $66

La diferencia de precio, explicada

La diferencia de precio se reduce al modelo de negocio: infraestructura frente a plataforma. Amazon SES vende cómputo y ancho de banda sin procesar (infraestructura), mientras que proveedores como Postmark o Mailgun venden una experiencia gestionada (plataforma) que incluye una mejor interfaz, soporte especializado y grupos de IP seleccionados. Por 50.000 correos, SES en modalidad de pago por uso cuesta unos $5, mientras que los niveles de Postmark pueden llegar a $66. Lo que usted paga es la reducción de la carga operativa y la calidad de las herramientas que rodean a la API.

Las cuentas: 50.000 correos

Cuando reviso la cola de incidentes o la factura mensual de la nube, la disparidad de precios del correo es una de las partidas más chocantes. Para entender el motivo, hay que fijarse en las tarifas actuales del mercado a septiembre de 2026.

El enfoque de infraestructura: Amazon SES

Amazon SES es la referencia de costo. Según su página de precios, el envío en modalidad de pago por uso cuesta $0.10 por cada 1.000 correos.

• Cálculo: (50.000 / 1.000) * $0.10 = $5.00.

Sin embargo, AWS introdujo nuevos planes por niveles el 21 de julio de 2026. Si pasa al plan Essentials, el costo es de $0.16 por cada 1.000. El plan Pro cuesta $0.22 por cada 1.000 más una cuota mensual de $105 por región. El plan Enterprise cuesta $0.23 por cada 1.000 más $500 al mes. Para un equipo de producto pequeño, el modelo de pago por uso es el más barato, pero deja toda la carga de configuración en manos del ingeniero.

El enfoque de plataforma: Postmark y Mailgun

Proveedores como Postmark y Mailgun se centran en la experiencia del desarrollador. Según los precios de Postmark, su plan base cuesta $15 al mes por 10.000 correos. Los excedentes van de $1.80 a $1.20 por cada 1.000 correos.

• Cálculo (Postmark): $15 (primeros 10.000) + (40.000 / 1.000 * $1.20) = $15 + $48 = $63. (Según el nivel concreto, puede llegar a $66).

De forma similar, los precios de Mailgun empiezan en $15 al mes por 10.000 correos, con excedentes de entre $1.80 y $1.10 por cada 1.000. Estos proveedores ofrecen plantillas alojadas y analíticas más intuitivas, lo que justifica el sobreprecio para los equipos que no quieren construir sus propios paneles de monitoreo.

El punto intermedio moderno: Resend

Resend apunta al stack de producto moderno. Su página de precios muestra un plan gratuito de 3.000 correos al mes (con un máximo de 100 al día). Su plan Pro cuesta $20 al mes por 50.000 correos, con excedentes a $0.90 por cada 1.000.

• Cálculo (Resend): $20 fijos por los primeros 50.000.

Aceptación, entrega y llegada a la bandeja de entrada: la distinción clave

Un error habitual que veo en la documentación de ingeniería es usar estos tres términos como si fueran intercambiables. No son lo mismo, y ninguna API puede garantizar el último paso.

1. Aceptación: es la respuesta de la API. Cuando hace POST de un payload a un endpoint, el proveedor devuelve un 202 Accepted o un 200 OK. Esto solo significa que el proveedor recibió la solicitud y que superó la validación básica. No significa que el correo haya salido del edificio.
2. Entrega: es el handshake SMTP. El proveedor intenta entregar el mensaje al servidor receptor del destinatario. Un evento «delivered» significa que el servidor receptor dijo «me lo quedo».
3. Llegada a la bandeja de entrada: es el destino final. El servidor receptor (Gmail, Outlook, etc.) decide si el correo va a la bandeja de entrada, a la pestaña Promociones o a la carpeta de spam. Lo determinan los filtros internos del destinatario, la reputación del remitente y sus registros de autenticación.

Para mejorar sus probabilidades de entrega, debe configurar correctamente su DNS. Recomiendo usar un verificador de DNS para comprobar que sus registros se están propagando. Debería seguir una guía rigurosa sobre DKIM, SPF y DMARC para demostrar que usted es quien dice ser.

Ingeniería para la confiabilidad

Enviar un correo es un efecto secundario externo. En un sistema distribuido, los efectos secundarios son peligrosos porque pueden duplicarse o fallar en silencio.

El problema de la idempotencia

Si su servidor de aplicaciones agota el tiempo de espera mientras aguarda la respuesta de la API de correo, usted no sabe si el correo se envió. Si simplemente reintenta, el usuario recibe dos correos. Por eso una clave de idempotencia es imprescindible.

Una clave de idempotencia es un identificador único (normalmente un UUID) que se envía en el encabezado. Si la API ve la misma clave dos veces, devuelve la respuesta almacenada de la primera solicitud correcta en lugar de enviar un segundo correo.

{ "idempotency_key": "req_8823_abc_123", "from": "notifications@example.com", "to": "user@gmail.com", "subject": "Your Order has Shipped", "body": "Your package is on the way!" }

Gestionar el envío impulsado por agentes

Con el auge de los agentes de IA y los servidores MCP, vemos cada vez más comunicación «de agente a agente» (A2A). Los agentes nunca deberían tener acceso sin restricciones a una API de envío. Si un LLM entra en un bucle, puede agotar su cuota de 50.000 correos en minutos y destruir la reputación del remitente.

Implemente un flujo de aprobación para los agentes:

1. Fase de borrador: el agente genera el correo y lo guarda en una tabla pending_emails.
2. Intervención humana: un usuario o un agente supervisor revisa el contenido.
3. Ejecución: el sistema llama a la API solo después de que se establezca un indicador status = 'approved'.

Lista de verificación técnica para la migración

Si pasa de un proveedor de alto costo a uno de menor costo (o viceversa), no se limite a cambiar la clave de API. Use esta lista de verificación:

• Auditoría de DNS: verifique sus registros SPF. Asegúrese de no superar el límite de 10 consultas.
• Correspondencia de webhooks: cada proveedor usa nombres de evento distintos. Haga corresponder delivered del proveedor A con sent del proveedor B.
• Sincronización de supresiones: exporte sus listas de rebotes y quejas. Si importa 50.000 usuarios en un proveedor nuevo y envía a direcciones que ya se sabe que rebotan, su cuenta será suspendida de inmediato.
• Gestión de límites de frecuencia: implemente backoff exponencial para los errores 429 Too Many Requests.

Ejemplo de lógica de gestión de errores

async function sendWithRetry(payload, attempt = 1) { try { const response = await emailApi.send(payload); return response; } catch (error) { if (error.status === 429 && attempt <= 3) { const delay = Math.pow(2, attempt) * 1000; await new Promise(res => setTimeout(res, delay)); return sendWithRetry(payload, attempt + 1); } throw error; } }

Elegir la herramienta adecuada

Si es un desarrollador independiente que construye un prototipo, los planes gratuitos de Resend o los precios de pago por uso de SES son suficientes. Si forma parte de un equipo de producto que gestiona un flujo transaccional complejo y de alto impacto (como restablecimientos de contraseña o alertas de facturación), la seguridad operativa de un proveedor de plataforma suele valer la diferencia de $60.

Quienes construyen aplicaciones nativas de IA necesitan algo más que una simple tubería. Necesitan que el servicio esté preparado para agentes, por ejemplo con un servidor MCP y un archivo llms.txt estructurado que ayude a sus agentes a entender cómo interactuar con su capa de comunicación. Ahí es donde una API especializada se convierte en un multiplicador de fuerza en lugar de ser solo un centro de costos.

En última instancia, el costo de la API es la parte más pequeña de la ecuación. El costo real es el tiempo de ingeniería dedicado a depurar un registro DNS mal configurado o a limpiar una crisis de reputación provocada por la falta de gestión de supresiones. Tanto si elige el camino de $5 como el de $66, priorice la telemetría y las herramientas que mantienen sus correos en movimiento.

Descubra más infraestructura de correo pensada para desarrolladores en https://sendhq.cc.