Cada día, más de 300 mil millones de correos electrónicos atraviesan internet. Viajan entre servidores de los que nunca has oído hablar, a través de redes que nunca verás, usando un protocolo diseñado en 1982. Ese protocolo es SMTP—Protocolo simple de transferencia de correo—y, a pesar de su edad, sigue siendo la columna vertebral de la comunicación por correo electrónico.
La mayoría de los desarrolladores interactúan con el correo a través de APIs de alto nivel que abstraen la mecánica subyacente. Llamas a una función, pasas algunos parámetros y el correo sucede. Pero cuando las cosas salen mal—y saldrán mal—entender lo que realmente está ocurriendo bajo el capó marca la diferencia entre depurar eficazmente y dar palos de ciego.
La conversación SMTP
SMTP es un protocolo basado en texto, lo que significa que literalmente puedes tener una conversación con un servidor de correo usando telnet o netcat. Esto no es solo una curiosidad: es una técnica de depuración poderosa. Vamos a ver cómo es esa conversación.
Cuando tu servidor de correo quiere enviar un correo, primero busca el servidor del destinatario usando los registros MX de DNS. Si estás enviando a [email protected], consulta los registros MX de example.com para encontrar qué servidor gestiona el correo de ese dominio.
Luego abre una conexión TCP a ese servidor, típicamente en el puerto 25 (o 587 para envío, o 465 para TLS implícito). El servidor receptor responde con un saludo—normalmente un código de estado 220 y alguna información de identificación.
Tu servidor se presenta con EHLO (o el más antiguo HELO), anunciando su nombre de host. El servidor receptor responde con una lista de extensiones que admite—cosas como STARTTLS para cifrado, AUTH para autenticación y límites de SIZE.
Si ambos servidores admiten STARTTLS, negocian una conexión cifrada en este punto. Esto es cifrado oportunista—si falla, pueden volver a una transmisión sin cifrar (a menos que una de las partes requiera cifrado).
Ahora viene la transmisión real del correo. Tu servidor envía MAIL FROM con la dirección del remitente del sobre. Luego RCPT TO con la dirección del destinatario (repetido para múltiples destinatarios). El servidor receptor puede aceptar o rechazar en cada paso—quizá el destinatario no existe, o el remitente está en una lista negra.
Finalmente, tu servidor envía DATA, seguido por el contenido real del correo (cabeceras y cuerpo), terminado por una línea que contiene solo un punto. El servidor receptor acepta el mensaje (250 OK) o lo rechaza con un código de error.
Sobre vs. cabeceras
Aquí hay algo que confunde a muchos desarrolladores: las direcciones en la conversación SMTP (el 'sobre') están separadas de las direcciones en las cabeceras del correo. Pueden ser—y a menudo son—diferentes.
Las direcciones del sobre (MAIL FROM y RCPT TO) se usan para el enrutamiento. Determinan a dónde va realmente el correo y a dónde se envían los rebotes. Las direcciones de las cabeceras (From, To, Cc) son las que los destinatarios ven en su cliente de correo.
Esta separación existe por razones legítimas. Las listas de correo la usan: el remitente del sobre es la dirección de rebote de la lista, mientras que la cabecera From muestra al autor original. El reenvío la usa: el sobre cambia en cada salto, pero las cabeceras preservan al remitente original.
Pero esta separación también es lo que habilita la suplantación. Un atacante puede establecer la cabecera From a cualquier dirección que quiera mientras usa su propio servidor para el sobre. Por eso SPF comprueba el remitente del sobre, DKIM firma las cabeceras y DMARC requiere alineación entre ellos.
Reenvío y smart hosts
En los primeros días del correo, los servidores reenviaban mensajes para cualquiera. Podías conectarte a cualquier servidor SMTP y pedirle que entregara correo en tu nombre. Este modelo de relé abierto era conveniente, pero se volvió insostenible conforme el spam explotó.
Hoy, la mayoría de los servidores SMTP están configurados para reenviar solo para usuarios autenticados o rangos de IP específicos. Si intentas enviar a través de un servidor que no estás autorizado a usar, obtendrás un error '550 relay not permitted'.
Muchas organizaciones usan una configuración de 'smart host': los sistemas internos envían todo el correo saliente a un servidor central, que gestiona la autenticación, las colas y la entrega a internet. Esto centraliza la gestión del correo y facilita implementar políticas consistentes.
Los servicios de correo en la nube funcionan de manera similar. Cuando usas una API para enviar correo, esencialmente estás usando sus servidores como un smart host. Ellos manejan la complejidad de SMTP, mantienen la reputación de IP y se ocupan de los problemas de entrega para que tú no tengas que hacerlo.
Códigos de error y qué significan
SMTP utiliza códigos de estado de tres dígitos, y entenderlos te ayuda a diagnosticar problemas de entrega.
Los códigos que empiezan con 2 indican éxito. 250 es la respuesta estándar 'OK'. 251 significa que el usuario no es local pero el servidor reenviará el mensaje.
Los códigos que empiezan con 4 son fallos temporales. 421 significa que el servidor está temporalmente no disponible. 450 significa que el buzón está temporalmente no disponible (quizá por superar la cuota). 451 es un genérico 'inténtelo de nuevo más tarde'. Tu servidor debería reintentar estos automáticamente.
Los códigos que empiezan con 5 son fallos permanentes. 550 es el rechazo comodín—el usuario no existe, relé denegado, rechazo por política. 551 significa que el usuario se ha mudado. 552 significa que el mensaje es demasiado grande. 553 significa que la sintaxis de la dirección es inválida. 554 es un genérico 'transacción fallida.'
El segundo dígito proporciona más contexto: x0x es sintaxis, x1x es información, x2x es conexiones, x5x es estado del sistema de correo. Pero en la práctica, el texto legible por humanos después del código suele ser más informativo que el propio código.
Los servidores modernos a menudo incluyen códigos de estado extendidos (como 5.1.1 para 'bad destination mailbox address') y explicaciones detalladas. Al depurar problemas de entrega, mira siempre el mensaje de error completo, no solo el código.
SMTP en el mundo moderno
SMTP ha evolucionado significativamente desde 1982, aunque el protocolo central sigue siendo reconocible. Varias extensiones se han vuelto esenciales para el correo moderno.
STARTTLS habilita cifrado para conexiones SMTP. No es perfecto—es oportunista y vulnerable a ataques de degradación—pero está ampliamente desplegado y proporciona protección significativa contra la intercepción pasiva.
SMTP AUTH permite que los servidores requieran autenticación antes de aceptar correo para relé. Así es como inicias sesión para enviar correo a través de los servidores de tu proveedor.
CHUNKING y BINARYMIME permiten una transmisión más eficiente de mensajes grandes y contenido binario, evitando la sobrecarga de la codificación base64.
A pesar de estas mejoras, SMTP muestra su edad. Es síncrono y orientado a conexión, lo cual no escala bien. No tiene autenticación incorporada de remitentes (de ahí la necesidad de SPF/DKIM/DMARC). Es basado en texto, lo cual es genial para depurar pero ineficiente para grandes volúmenes.
Ha habido propuestas para reemplazar SMTP con algo más moderno, pero ninguna ha ganado tracción. La base instalada es demasiado grande, los requisitos de interoperabilidad demasiado estrictos. En el futuro previsible, SMTP sigue siendo la lengua franca del correo.
Frequently asked questions
¿Cuál es la diferencia entre los puertos 25, 465 y 587?
El puerto 25 es para comunicación entre servidores. El puerto 587 es para el envío del cliente (tu cliente de correo al servidor de tu proveedor) con STARTTLS. El puerto 465 es para TLS implícito (cifrado desde el inicio). La mayoría de los proveedores ahora prefieren 587 o 465 para conexiones de cliente.
¿Por qué mis correos son rechazados con 'relay denied'?
El servidor no confía en que envíes a través de él. O bien no estás autenticado, estás intentando enviar a un dominio que el servidor no maneja, o tu IP no está en la lista permitida. Revisa tu configuración de autenticación.
¿Puedo enviar correo directamente sin usar un servicio de correo?
Técnicamente sí, pero es poco práctico. Tendrías que gestionar la reputación de IP, manejar rebotes, implementar autenticación, lidiar con la limitación de tasa y mantener la entregabilidad—todas cosas que los servicios de correo hacen por ti.
¿Qué pasa si el servidor del destinatario está caído?
Tu servidor pone el mensaje en cola y reintenta periódicamente. La mayoría de los servidores reintentan durante 4–5 días antes de desistir y enviar un mensaje de rebote. El calendario de reintentos varía, pero normalmente empieza con intentos frecuentes y se espacian con el tiempo.