SMTP o API de correo electrónico: ¿cuál debería usar tu aplicación?

Tarde o temprano, todo producto tiene que enviar correo, y la primera pregunta es cómo debe comunicarse tu código con el sistema de correo. Hay dos respuestas: hablar SMTP directamente o llamar a una API de correo por HTTPS.

Ambas funcionan. Sin embargo, imponen exigencias muy distintas a tu aplicación, y la elección correcta depende de dónde se ejecuta tu código y de cuánta infraestructura de correo quieres mantener tú.

En qué destaca SMTP

SMTP (Simple Mail Transfer Protocol) es el protocolo con el que los servidores de correo intercambian mensajes desde principios de los años ochenta. Todos los proveedores de buzones lo admiten y casi todos los frameworks incluyen un cliente SMTP integrado: Nodemailer, send_mail de Django, Laravel Mail, Action Mailer de Rails.

Puntos fuertes:

• Universal. Cualquier cuenta de correo y cualquier lenguaje pueden usarlo.
• Sin dependencia de un proveedor. Cambias de proveedor cambiando un nombre de host y una contraseña.
• Tu propio dominio y tu reputación. El correo sale por un servidor que controlas o alquilas, desde direcciones de tu dominio.

Dónde falla SMTP dentro de una aplicación

SMTP es un protocolo conversacional y con estado. Para enviar un mensaje, tu app abre una conexión TCP, saluda al servidor, eleva la conexión a TLS, se autentica y después recorre una serie de comandos y respuestas para el remitente, el destinatario y los datos. Cada paso es un viaje de ida y vuelta por la red.

En la práctica, eso provoca:

• Solicitudes lentas. El intercambio inicial con un servidor lejano puede tardar cientos de milisegundos antes de que el mensaje empiece siquiera a transmitirse.
• Puertos bloqueados. Muchas plataformas en la nube y entornos serverless restringen los puertos de salida 25, 465 y 587 para combatir el spam. HTTPS en el puerto 443 casi nunca está bloqueado.
• Credenciales por todas partes. Cada servicio que envía correo necesita la contraseña del buzón. Rotarla implica volver a desplegarlos todos.
• Poca visibilidad. Cuando algo falla, el error queda en los registros de un solo servicio, si es que llegó a registrarse.

Qué cambia una API de correo

Una API de correo encapsula el envío en una sola solicitud HTTPS con un cuerpo JSON. Tu código hace un POST y recibe un código de estado. El servicio de la API mantiene la conexión SMTP y las credenciales.

Puntos fuertes:

• Una solicitud rápida por el puerto 443, desde cualquier lugar: contenedores, funciones serverless, entornos edge, tareas de CI.
• Claves en lugar de contraseñas. Cada servicio recibe su propia clave de API con permisos limitados, y puedes revocar o rotar una sin tocar las demás.
• Visibilidad centralizada. Las llamadas a la API y los resultados de entrega se registran en un solo lugar.
• Errores HTTP sencillos. Un 401 o un 429 es mucho más fácil de gestionar que un código de respuesta SMTP enterrado en una traza de pila.

Contrapartida: con la mayoría de las API de correo, el correo sale por sus servidores, así que adoptas su configuración de dominio de envío y su reputación de IP, y migrar más adelante implica volver a verificarlo todo en otro sitio.

Inbixio: una API delante de tu servidor SMTP

Inbixio se basa en una idea sencilla: conservar la parte valiosa de SMTP, tu propio servidor de correo y tu identidad como remitente, y sustituir la parte que da problemas dentro de las aplicaciones.

1. Conectas tu servidor SMTP una sola vez en el panel: host, puerto, nombre de usuario y contraseña.
2. Tus servicios llaman a POST /api/send-email/ con una clave de API de Inbixio.
3. Inbixio inicia sesión en tu servidor SMTP mediante TLS y entrega el mensaje desde tu dirección.
4. Tu panel muestra el número de correos enviados, la tasa de entregas fallidas y la latencia de entrega, además de un registro de cada llamada a la API.

curl -X POST https://backend.inbixio.com/api/send-email/ \
  -H "X-API-Key: $INBIXIO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to_email":"user@example.com","subject":"Welcome!","message":"<h1>Hello</h1>"}'

Lo que obtienes:

• Tu contraseña SMTP se guarda en un solo lugar. Tus servicios solo ven claves de API.
• Las claves pueden fijarse a un servidor concreto, de modo que el servicio de facturación envía desde billing@ y el de autenticación desde security@.
• Los permisos de cada clave son explícitos, y una clave puede renovarse o eliminarse sin tocar el servidor de correo.
• Conservas tu dominio de envío, tu proveedor y tu reputación. Si cambias de proveedor de correo, actualizas una entrada de servidor y no cambia nada de tu código.

Comparativa

Entonces, ¿cuál deberías usar?

• Usa SMTP directamente para una sola aplicación pequeña en un servidor donde se permita el SMTP saliente y no te importe gestionar allí las credenciales.
• Usa una API de correo cuando tengas varios servicios, despliegues en plataformas que bloquean los puertos SMTP, quieras registros centralizados o quieras dejar de repartir contraseñas de buzones.
• Usa Inbixio cuando quieras las ventajas de una API pero también que el correo siga saliendo por tu propio servidor de correo y tu dominio.

¿Quieres probarlo? La guía de inicio rápido de cinco minutos te lleva del registro a un correo entregado.