¿Cuál es la diferencia, en una línea?
SMTP es el protocolo abierto que usa tu software para entregar correo a un servidor; una API de email es una interfaz HTTPS propia de cada proveedor que hace el mismo trabajo con payloads estructurados y retorno de eventos. El protocolo de envío no decide si llegas a la bandeja de entrada: lo deciden la autenticación y la reputación del dominio, y SPF, DKIM y DMARC se aplican igual a las dos vías. Así que elige por criterios de integración: portabilidad, gestión de errores, herramientas. Para todo lo que ocurre después de que tu proveedor acepta el mensaje, la guía es entregabilidad de email para startups.
¿Cómo funciona el envío por SMTP?
Tu aplicación abre una conexión con el servidor de tu proveedor, el relay SMTP —para el envío, normalmente el puerto 587 con autenticación, según RFC 6409— y le entrega el mensaje ya terminado. El protocolo de transferencia en sí es RFC 5321, estandarizado en su forma actual en 2008 y en uso desde mucho antes, por eso todo lo habla: cualquier framework, CMS, foro, herramienta de monitorización o script de hace décadas puede enviar así con solo un host, un puerto y unas credenciales. Esa es la ventaja discreta de SMTP: migrar es cambiar unas credenciales, así que cambiar de plataforma de email nunca obliga a reescribir el código de envío. También encaja de forma natural en los stacks autoalojados, donde el soporte SMTP viene incluido por defecto.
¿Cómo funciona el envío por una API de email?
Tu código llama al endpoint HTTPS del proveedor con un payload JSON: destinatario, contenido o una referencia a una plantilla, etiquetas, metadatos y, a menudo, una clave de idempotencia para evitar envíos duplicados. La respuesta es síncrona: éxito con un ID de mensaje, o un error que tu código puede capturar y reintentar. La documentación de Postmark deja clara la diferencia: su API REST devuelve un éxito o un error de inmediato, mientras que su endpoint SMTP acepta todos los mensajes y registra cualquier error como rebote, que aun así puedes recuperar con sus webhooks de rebotes. Una vez aceptado el mensaje, los webhooks envían de vuelta a tu app los rebotes, las quejas y las aperturas, y eso es lo que hace posible la supresión automática. Los SDK de los proveedores lo resumen todo en unas pocas líneas; a cambio, la integración es específica de ese proveedor.
SMTP vs. API: cara a cara
Toda la decisión se reduce a un intercambio: SMTP te da portabilidad y la API te da retorno de información y herramientas. Así se traduce punto por punto.
| SMTP | API de email | |
|---|---|---|
| Qué es | Protocolo abierto (RFC 5321), igual en todas partes | Interfaz de producto propia de cada proveedor, sobre HTTPS |
| Esfuerzo de integración | Casi nulo si el software ya habla SMTP: host, puerto, credenciales | Programar contra el endpoint o el SDK del proveedor |
| Portabilidad | Alta: cambiar de proveedor es cambiar unas credenciales | Baja: el formato de cada proveedor es distinto; cambiar implica reescribir la integración |
| Gestión de errores | Aceptado en el envío; algunos fallos aparecen después como rebotes asíncronos | Errores síncronos que puedes capturar y reintentar, más eventos asíncronos |
| Retorno de eventos | Nada en el protocolo: los webhooks de rebotes del proveedor siguen cubriendo el correo enviado por SMTP, pero los conectas aparte | Los webhooks envían a tu app los rebotes, las quejas y las aperturas |
| Plantillas y analíticas | Nada en el protocolo: envías un mensaje ya terminado | Referencias a plantillas, etiquetas y metadatos por mensaje |
| Encaje con el autoalojamiento | Natural: el software autoalojado habla SMTP de serie | Una dependencia más, específica de un proveedor, en tu stack |
¿Cuándo es SMTP la opción correcta?
- Software que ya lo habla: un CMS, un foro, un helpdesk o una aplicación heredada empieza a enviar a través de tu proveedor con solo unas credenciales nuevas.
- Máxima portabilidad: si quieres libertad para cambiar de proveedor sin tocar código, SMTP es la interfaz neutral.
- Stacks autoalojados: el soporte SMTP viene integrado en prácticamente todo lo que ejecutarías en tu propia infraestructura, sin necesidad de SDK.
- Correo operativo de bajo volumen: las alertas de cron y las notificaciones internas rara vez justifican una integración de API a medida.
¿Cuándo es la API la opción correcta?
Para el envío del producto a escala. Cuando el email está integrado en tu aplicación —onboarding, recibos, flujos de ciclo de vida—, los errores síncronos, las referencias a plantillas y los webhooks de eventos compensan su costo de integración, y una lista de supresión puede actualizarse sola en el momento en que una dirección rebota o se queja. Lo que la API no te da es reputación: esta vive en tu dominio de envío, no en tu vía de envío, así que calentar el dominio y la autenticación se aplican igual sea cual sea la vía.
¿Por qué fromHello admite las dos?
Como la elección es una decisión de integración y no de entregabilidad, fromHello incluye adaptadores para las dos: API HTTP (Resend, Postmark, SendGrid), cualquier servidor SMTP y buzones de Microsoft 365. Defines un proveedor por defecto para cada espacio de trabajo y puedes asignar a una plantilla su propio proveedor. En fromHello Cloud, en acceso anticipado, los planes Team y superiores incluyen el envío de email ya configurado; en Core o autoalojado, pones tú el proveedor. En cualquier caso, los límites están a nivel del proveedor: Resend, por ejemplo, documenta el mismo límite de peticiones para su endpoint SMTP que para su API. Y la plataforma aplica la supresión y el consentimiento sea cual sea la vía de envío: una dirección suprimida sigue suprimida tanto si el mensaje sale por HTTPS como por el puerto 587.