Un proveedor puede aceptar tu volumen mensual y aun así limitar la ráfaga después de una caída en el checkout. Compara el contrato de envío con el trabajo que tu aplicación debe recuperar.
Elige Bird para envío transaccional junto con buzones con hilos y respuestas. Amazon SES encaja mejor en una aplicación AWS construida en torno a los comandos de envío sesv2.
¿Qué es el correo electrónico transaccional?
El correo electrónico transaccional atiende una transacción o actividad de cuenta del destinatario, como un recibo o un restablecimiento de contraseña. El propósito del mensaje determina su categoría. La cantidad de destinatarios y el envío automático no convierten contenido promocional en transaccional.
¿Qué debes evaluar?
Compara las capacidades que tu aplicación necesita y luego prueba las rutas de fallo antes de comprometerte.
- Entregabilidad y herramientas de reputación. ¿Puedes autenticar tu dominio con SPF, DKIM y DMARC fácilmente? ¿Hay IPs dedicadas disponibles si las necesitas, con orientación para calentarlas?
- Calidad de API y SDK. ¿Está bien documentada la API, con SDKs oficiales en los lenguajes que usas?
- SMTP y HTTP a la vez. Verifica qué interfaz de envío soporta tu entorno de ejecución. Los clientes SMTP existentes pueden usar un relay; una HTTP API atiende aplicaciones que envían solicitudes estructuradas.
- Plantillas. Las plantillas del lado del servidor con sustitución de variables te permiten cambiar el texto sin un despliegue y mantener el formato consistente en todos los mensajes.
- Webhooks y eventos. Los eventos de webhook en tiempo real para entrega, apertura, clic, rebote y queja son la forma de mantener tus propios registros precisos y activar lógica de seguimiento.
- Analíticas. Vistas agregadas de tasas de entrega, rebote e interacción, más un registro con búsqueda para investigar un mensaje individual.
- Gestión de supresión. El proveedor debe suprimir automáticamente los rebotes duros y las quejas para que tu aplicación pueda detener los envíos bloqueados por esas señales. Pregunta cómo se gestionan las listas de supresión y si puedes inspeccionarlas.
- Escalabilidad. ¿Puede manejar tu volumen pico (un lanzamiento de producto, un pico por temporada alta) sin intervención manual ni limitaciones inesperadas?
- Precio. Entiende el modelo (por mensaje, escalonado, volumen incluido) y a partir de dónde se cobra el excedente. Calcúlalo para tu volumen esperado y los períodos pico.
- Soporte. Cuando el correo deja de fluir a las 2 de la mañana, ¿cómo contactas a una persona y qué tan rápido responde? Revisa el nivel de soporte que incluye el plan que realmente comprarías.
- Cumplimiento normativo. Confirma que el proveedor cumple los requisitos de manejo de datos y regionales a los que está sujeto tu negocio antes de comprometerte.
¿Cuándo debes elegir un servicio de relay SMTP?
Elige un relay SMTP cuando tu aplicación ya construye mensajes de correo y soporta un servidor de correo configurable. Elige una HTTP API cuando necesites campos de solicitud estructurados o plantillas almacenadas.
Para Bird, compara las rutas de envío y recuperación antes de elegir la interfaz:
| Decisión o fallo | Relay SMTP | HTTP email API |
|---|---|---|
| Autenticación | Nombre de usuario bird, clave API como contraseña, con el scope emails. Usa TLS en el host regional SMTP. | Clave API en el encabezado Authorization: Bearer, con el scope emails. |
| Respuesta de envío | La respuesta final 250 contiene el ID del mensaje en cola. Guárdalo junto con el evento de la aplicación. | 202 contiene el ID del mensaje aceptado. Guárdalo junto con el evento de la aplicación. |
| Responsabilidad de reintento | Tu aplicación o el cliente SMTP gestiona los reintentos de envío. Reutiliza X-Bird-Idempotency-Key para el mismo mensaje lógico. | Tu aplicación o SDK gestiona los reintentos de envío. Reutiliza Idempotency-Key para el mismo mensaje lógico. |
| Expiración | Antes de reintentar un trabajo no enviado, tu aplicación verifica si su enlace o código sigue siendo válido. | Aplica la misma verificación antes de enviar otra solicitud. |
| Supuestos de rendimiento | Verifica los límites de conexiones concurrentes por separado de las cuotas de envío. Más conexiones abiertas no establecen una tasa de envío permitida. | Regula las solicitudes API usando los encabezados de limitación de solicitudes de la respuesta. La tasa de solicitudes y el volumen de destinatarios son cantidades distintas. |
| Evidencia de eventos | Sigue los eventos del destinatario después de la respuesta de cola. Bird reintenta la entrega diferida. | Sigue los mismos eventos del destinatario después de la aceptación. Bird reintenta la entrega diferida. |
| Selección de pool | La configuración de SMTP de la clave API selecciona el pool. Una clave sin configurar usa el pool predeterminado de la organización. | Establece ip_pool_id por envío, o usa el pool predeterminado de la organización. |
La guía de relay SMTP proporciona la configuración de conexión y el manejo de respuestas. La referencia de envío HTTP define la solicitud y respuesta API. Ambas interfaces usan el mismo pipeline de correo, incluida la gestión de supresión y la firma.
La aceptación del transporte significa que Bird puso el mensaje en cola. El evento email.delivered posterior significa que el servidor receptor lo aceptó. Ninguno de los dos establece la colocación en la bandeja de entrada ni la lectura.
Mantén tu propio registro de envío más allá de la ventana de retención de idempotencia, porque un reintento posterior puede crear otro mensaje. Un diferimiento ya está siendo reintentado por Bird; crear otro envío duplica trabajo que aún está en curso.
Las IPs dedicadas son opcionales para cualquiera de las dos interfaces. Revisa los requisitos de pool y calentamiento antes de enrutar una ráfaga a través de un pool dedicado.
¿Qué capacidades publicadas debes comparar?
Verifica la interfaz documentada detrás de cada funcionalidad. Recibir un correo parseado, almacenar su contenido y exponer una conversación API son capacidades distintas.
| Proveedor | Envío | Evidencia del destinatario | Infraestructura de recepción y envío |
|---|---|---|---|
| Bird | Envío HTTP y SMTP | Eventos, registro de mensajes y supresiones | Buzones e hilos; pools de IPs dedicadas |
| Amazon SES | SendEmail API y SMTP | Destinos de eventos y lista de supresión de cuenta | Reglas de recepción en regiones soportadas; IPs dedicadas estándar o gestionadas |
| SendGrid | Mail Send API y SMTP | Event Webhook y Email Activity | Inbound Parse webhook; IP pools |
| Mailgun | Messages API y SMTP | Eventos de entrega y registros de rebote | Rutas para reenviar o almacenar correo; IP pools |
| Postmark | Email API y SMTP | Webhooks y supresiones de stream | Inbound webhook; elegibilidad para IP dedicada |
| Resend | Email API y SMTP | Eventos de webhook y registros API | Contenido recibido y respuestas; IPs dedicadas gestionadas |
Confirma la elegibilidad y la retención para el plan que comprarías. Un enlace a una funcionalidad no establece una cuota de rendimiento ni un compromiso de tiempo de recuperación.
Para contenido almacenado, verifica qué cuerpos, encabezados, archivos adjuntos y registros de eventos siguen siendo recuperables. Para residencia de datos, obtén el alcance publicado de almacenamiento y procesamiento, incluidas las excepciones. Un endpoint regional por sí solo no establece ese contrato.
¿Qué cambia a diez millones de envíos al mes?
El tráfico pico y la capacidad de recuperación determinan la tasa de envío requerida. El volumen mensual por sí solo no.
En un mes ilustrativo de 30 días, diez millones de mensajes con un solo destinatario promedian unas 3,86 mensajes por segundo. Una ráfaga de 100.000 mensajes en diez minutos necesita unos 167 por segundo. Evalúa la ráfaga por separado de la cuota mensual.
Tras una interrupción de diez minutos a 100 mensajes nuevos por segundo, tu aplicación tiene 60.000 trabajos sin enviar. Si el trabajo nuevo continúa a 100 por segundo, drenar esa cola en veinte minutos requiere otros 50 por segundo. El objetivo de recuperación es entonces 150 mensajes aceptados por segundo, sin contar reintentos ni retrasos del servidor receptor.
Verifica cómo cada proveedor cuenta el trabajo. Las cuotas de SES cuentan destinatarios y se aplican por separado en cada región. Incluyen una cuota diaria acumulativa y una tasa de aceptación. SES también advierte que la aceptación real puede estar por debajo de la tasa máxima de la cuenta.
Los límites de Resend distinguen la tasa de solicitudes API de las cuotas de volumen de correo. Los encabezados de limitación de solicitudes de Bird informan la cuota de solicitudes efectiva. Traduce el tamaño de tu lote a solicitudes antes de comparar cualquiera de los dos con la tasa de destinatarios del escenario.
¿Cómo debes probar la recuperación ante incidentes?
Prueba cómo tu aplicación se reanuda después de que falla el envío o su manejador de webhooks deja de estar disponible. La página de estado del proveedor proporciona contexto del incidente; tus registros de mensajes establecen qué trabajo queda pendiente.
| Proveedor | Contrato publicado de límites o errores | Estado oficial |
|---|---|---|
| Bird | Cuotas efectivas y encabezados de reintento | Estado de Bird |
| Amazon SES | Cuotas de envío | Estado de los servicios AWS |
| SendGrid | Límites de tasa API | Estado de SendGrid |
| Mailgun | Contrato de errores y limitación de solicitudes API | Estado de Mailgun |
| Postmark | Contrato de respuesta y errores API | Estado de Postmark |
| Resend | Límites de uso | Estado de Resend |
Pausa un worker de prueba, acumula trabajos y reanuda dentro del límite efectivo de la cuenta. Mide cuánto espera el trabajo elegible más antiguo. Los trabajos de restablecimiento expirados necesitan una ruta de solicitud nueva en lugar de una repetición automática.
Preserva cada identificador de evento de negocio durante la recuperación. Verifica el contrato de envío duplicado del proveedor antes de reintentar un envío incierto. Postmark no documenta una funcionalidad de clave de idempotencia, así que su integración necesita salvaguardas en la aplicación. La retención de respuestas completadas de Bird es de tres horas. La recuperación más allá de esa ventana necesita tu propio registro de eventos.
Relaciona los eventos posteriores del destinatario con los IDs de mensaje guardados. La aceptación del servidor receptor no establece la colocación en la bandeja de entrada ni la lectura. El ciclo de vida del correo transaccional API explica estos resultados por separado.
¿Qué debe incluir la comparación de precios?
Compara las inclusiones publicadas para el plan exacto, el período de facturación y la moneda que comprarías. Mantén el volumen de envío separado de la infraestructura y la retención que necesita.
| Fuente de precios del proveedor | Inclusiones a verificar para tu carga de trabajo |
|---|---|
| Precios de Bird | Cuota de envío, excedente, infraestructura dedicada, contenido retenido y soporte |
| Precios de Amazon SES | Uso de salida y entrada, cargos por datos, IPs dedicadas y funcionalidades opcionales |
| Precios de SendGrid | Volumen del plan, excedente, elegibilidad para IP dedicada, retención de actividad y soporte |
| Precios de Mailgun | Volumen de envío, retención de registros y mensajes, IPs dedicadas y soporte |
| Precios de Postmark | Cuota de envío, volumen adicional, opciones de retención y elegibilidad para IP dedicada |
| Precios de Resend | Cuotas de envío y recepción, excedente, retención y elegibilidad para IP dedicada |
Verifica si una cuota indicada cuenta solicitudes, mensajes o destinatarios. Registra las funcionalidades excluidas junto al plan en lugar de asumir que están incluidas. Las comparaciones de proveedores de Bird contienen las comparaciones de producto individuales.
Preguntas frecuentes
¿Cuál es la diferencia entre correo transaccional y correo de marketing?
El correo transaccional atiende una transacción o actividad de cuenta. El correo de marketing promociona algo o entrega contenido por suscripción. El propósito del mensaje determina la distinción, incluso cuando ambos son automatizados.
¿Puede un solo proveedor manejar tanto correo transaccional como de marketing?
Un proveedor puede atender ambos flujos de trabajo. Verifica por separado la política de categoría, las identidades de envío autenticadas y la selección de pool de IPs. La infraestructura compartida puede exponer el correo operacional a problemas de reputación causados por el tráfico de marketing.
¿Necesito una IP dedicada?
No al principio. Los pools de IPs compartidas funcionan bien con volúmenes bajos y te ahorran el calentamiento de IP. Una IP dedicada tiene sentido cuando tu volumen es lo suficientemente alto y constante como para mantener su propia reputación. Elige un proveedor que te permita empezar con IP compartida y pasar a dedicada cuando los números lo justifiquen.
Dónde encaja Bird
Puedes enviar a través de SMTP o la HTTP API. Publica plantillas para contenido reutilizable. Suscríbete a eventos del destinatario. Inspecciona mensajes individuales en el registro de correo.
Selecciona pools de IPs por separado de la categoría del mensaje. Sigue la guía de calentamiento al cambiar el volumen de envío. Usa la lista de verificación operativa para probar el manejo de duplicados y la recuperación.
¿Cómo debes tomar la decisión final?
- Relaciona las interfaces documentadas y los controles de destinatarios con tu aplicación.
- Confirma las cuotas efectivas tanto para tráfico pico como para recuperación de cola.
- Prueba el manejo de fallos contra registros guardados de mensajes y eventos de negocio.
- Compara las inclusiones publicadas, la retención y el soporte del plan que vas a comprar.