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.
¿Qué es el email transaccional?
El email transaccional sirve a la transacción o actividad de cuenta de un 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 los caminos 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 sobre su calentamiento?
- Calidad de API y SDK. ¿Está bien documentada la API, con SDKs oficiales en los lenguajes que usas?
- SMTP y HTTP ambos. Verifica qué interfaz de envío soporta tu entorno de ejecución. Los clientes SMTP existentes pueden usar un relay; una HTTP API sirve a 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 entre mensajes.
- Webhooks y eventos. Los eventos de webhook en tiempo real de 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 y engagement, más un registro de búsqueda para investigar un mensaje individual.
- Gestión de supresiones. El proveedor debe suprimir automáticamente los rebotes duros y las quejas para que tu aplicación pueda detener envíos bloqueados por esas señales. Pregunta cómo se gestionan las listas de supresión y si puedes inspeccionarlas.
- Escalabilidad. ¿Podrá manejar tu volumen pico (un lanzamiento de producto, un pico por festividades) sin intervención manual ni limitación inesperada?
- Precios. Entiende el modelo (por mensaje, escalonado, volumen incluido) y dónde se aplica el excedente. Calcúlalo para tu volumen esperado y periodos 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 con 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 email y soporta un servidor de correo configurable. Elige una HTTP API cuando necesites campos de solicitud estructurados o plantillas almacenadas.
Para Bird, compara los caminos de envío y recuperación antes de elegir la interfaz:
| Decisión o fallo | Relay SMTP | HTTP email API |
|---|---|---|
| Autenticación | Usuario bird, clave API como contraseña, con el alcance emails. Usa TLS en el host SMTP regional. | Clave API en el encabezado Authorization: Bearer, con el alcance emails. |
| Respuesta de envío | El 250 final 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 límite de tasa de la respuesta. La tasa de solicitudes y el volumen de destinatarios son cantidades diferentes. |
| 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 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 email, incluyendo la gestión de supresiones y la firma.
La aceptación de 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 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 email parseado, almacenar su contenido y exponer una conversación API son capacidades diferentes.
| 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 de IP dedicada |
| Resend | Email API y SMTP | Eventos de webhook y logs de API | Contenido recibido y respuestas; IPs dedicadas gestionadas |
Confirma la elegibilidad y 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, incluyendo excepciones. Un endpoint regional por sí solo no establece ese contrato.
¿Qué cambia con 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.
Después de 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 ese backlog 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.
Revisa cómo cada proveedor cuenta el trabajo. Las cuotas de SES cuentan destinatarios y se aplican por separado según la región. Incluyen una cuota diaria continua 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 email. Los encabezados de límite de tasa de Bird reportan la cuota efectiva de solicitudes. 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 del servicio AWS |
| SendGrid | Límites de tasa de API | Estado de SendGrid |
| Mailgun | Contrato de errores y límite de tasa de API | Estado de Mailgun |
| Postmark | Contrato de respuesta y errores de 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.
Conserva 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 protecciones a nivel de 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.
Vincula los eventos posteriores del destinatario con los IDs de mensaje guardados. La aceptación del servidor receptor no establece la colocación en bandeja de entrada ni la lectura. El ciclo de vida del API transaccional explica estos resultados separados.
¿Qué debe incluir la comparación de precios?
Compara las inclusiones publicadas para el plan exacto, periodo de facturación y moneda que comprarías. Mantén el volumen de envío separado de la infraestructura y 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 de IP dedicada, retención de actividad y soporte |
| Precios de Mailgun | Volumen de envío, retención de logs y mensajes, IPs dedicadas y soporte |
| Precios de Postmark | Cuota de envío, volumen adicional, opciones de retención y elegibilidad de IP dedicada |
| Precios de Resend | Cuotas de envío y recepción, excedente, retención y elegibilidad de IP dedicada |
Verifica si una cuota citada 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 por separado.
Preguntas frecuentes
¿Cuál es la diferencia entre email transaccional y email de marketing?
El correo transaccional sirve a 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 están automatizados.
¿Puede un solo proveedor manejar tanto correo transaccional como de marketing?
Un proveedor puede servir ambos flujos de trabajo. Revisa la política de categorías, las identidades de envío autenticadas y la selección de pool de IPs por separado. La infraestructura compartida aún puede exponer el correo operativo a problemas de reputación del 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 compartidas y pasar a dedicadas 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 email.
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 destinatario con tu aplicación.
- Confirma las cuotas efectivas tanto para tráfico pico como para recuperación de backlog.
- Prueba el manejo de fallos contra los registros guardados de mensajes y eventos de negocio.
- Compara las inclusiones publicadas, retención y soporte para el plan que comprarás.