Cómo Realmente Funciona SMTP
Un recorrido completo de una transacción SMTP — desde búsqueda DNS hasta entrega final. Si envías correo electrónico mediante programación, este es el modelo mental que necesitas.
La imagen general
SMTP — el Protocolo Simple de Transferencia de Correo — es el protocolo que mueve correo electrónico a través de internet. Definido en RFC 5321, ha sido la columna vertebral del correo electrónico desde 1982 (el RFC 821 original). A pesar de décadas de extensiones, la transacción central sigue siendo una breve conversación de texto síncrona entre dos servidores sobre el puerto TCP 25.
Cada entrega de correo sigue la misma secuencia:
- Búsqueda DNS — encuentra el servidor de correo del destinatario
- Conexión TCP — conéctate al puerto 25 (o 465/587 para envío)
- Banner y EHLO — intercambia identidades y capacidades
- STARTTLS — actualiza a conexión cifrada (normalmente)
- AUTH — auténticate si envías (puerto 587)
- Sobre — MAIL FROM y RCPT TO
- DATA — transmite los encabezados y cuerpo del mensaje
- QUIT — cierra la conexión
Paso 1: DNS — Encontrar el servidor de correo
Antes de que comience cualquier conversación SMTP, el servidor remitente debe descubrir dónde entregar el mensaje. Consulta DNS para registros MX en el dominio del destinatario.
10 mx1.example.com.
20 mx2.example.com.
El número es la prioridad (menor = preferido). El remitente intenta mx1.example.com primero. Si no es accesible o devuelve un error temporal, el remitente recurre a mx2.example.com.
Si no existen registros MX, el remitente recurre al registro A o AAAA del dominio — pero esta es una última opción. Si existe un registro MX nulo explícito (0 .), el dominio no acepta correo en absoluto. Consulta DNS y Enrutamiento de Correo para el algoritmo completo.
Paso 2: Conexión TCP y el banner
El remitente abre una conexión TCP al puerto 25 del host MX. El servidor receptor habla primero con un banner 220:
220 mx1.example.com ESMTP ready
El código de estado 220 significa "servicio listo". Si el servidor está sobrecargado, puede responder con 421 (servicio no disponible) y cerrar la conexión. El remitente debe reintentar más tarde.
Para envío de mensajes (un cliente de correo de un usuario enviando a través de su proveedor), la conexión va al puerto 587 (RFC 6409) o puerto 465 (TLS implícito, RFC 8314) en lugar del puerto 25.
Paso 3: EHLO — Anunciando capacidades
El remitente se presenta a sí mismo con EHLO (HELO extendido), proporcionando su propio nombre de host. El servidor responde con sus extensiones compatibles:
250-mx1.example.com Hello sender.mailertogo.com
250-SIZE 52428800
250-8BITMIME
250-STARTTLS
250-AUTH PLAIN LOGIN
250-PIPELINING
250-ENHANCEDSTATUSCODES
250 SMTPUTF8
Cada línea 250- anuncia una extensión. La última línea usa 250 (espacio, no guión) para señalar el final. Extensiones clave:
- SIZE — tamaño máximo de mensaje en bytes
- STARTTLS — el servidor admite la actualización a TLS (RFC 3207)
- AUTH — mecanismos de autenticación admitidos (RFC 4954)
- PIPELINING — el remitente puede agrupar comandos sin esperar (RFC 2920)
- ENHANCEDSTATUSCODES — códigos de estado extendidos como 5.1.1 (RFC 3463)
- 8BITMIME — la transferencia de contenido de 8 bits es compatible
- SMTPUTF8 — direcciones de correo electrónico internacionalizadas (RFC 6531)
El comando heredado HELO (sin la "E") omite completamente las extensiones. Prácticamente nunca se usa hoy en día.
Paso 4: STARTTLS — Actualización a cifrado
Si el servidor anunció STARTTLS, el remitente emite el comando para actualizar la conexión:
220 2.0.0 Ready to start TLS
# El protocolo de enlace TLS ocurre aquí
# La conexión ahora está cifrada
# El remitente debe hacer EHLO nuevamente sobre el canal cifrado
EHLO sender.mailertogo.com
250-mx1.example.com Hello sender.mailertogo.com
250-SIZE 52428800
250 ENHANCEDSTATUSCODES
Después de STARTTLS, el remitente debe enviar EHLO nuevamente. El servidor puede anunciar diferentes extensiones sobre la conexión cifrada (por ejemplo, AUTH típicamente solo se anuncia después de que TLS se establece).
En el puerto 465, TLS es implícito — la conexión está cifrada desde el primer byte, y no se necesita ningún paso STARTTLS.
Sin TLS, toda la conversación SMTP — incluyendo contraseñas y contenido del mensaje — se envía en texto plano. La mejor práctica moderna es siempre usar TLS. Consulta MTA-STS y DANE para mecanismos que lo refuercen.
Paso 5: AUTH — Autenticación (solo envío)
Cuando un cliente de correo envía un mensaje a través del puerto 587, se autentica usando SMTP AUTH (RFC 4954):
235 2.7.0 Authentication successful
La cadena Base64 codifica \0username\0password. Por eso TLS es crítico — sin él, las credenciales viajan en claro.
La entrega de servidor a servidor en el puerto 25 no usa AUTH. En su lugar, el servidor receptor confía en la dirección IP del remitente, registros SPF, firmas DKIM y otros mecanismos de autenticación para verificar el mensaje. Consulta Autenticación de correo electrónico explicada.
Paso 6: El sobre — MAIL FROM y RCPT TO
El sobre es separado de los encabezados del mensaje. Le dice al servidor receptor quién está enviando el mensaje y quién debe recibirlo:
250 2.1.0 OK
RCPT TO:<bob@example.net>
250 2.1.5 OK
RCPT TO:<carol@example.net>
250 2.1.5 OK
Detalles clave:
-
MAIL FROM especifica la ruta de devolución (también llamada remitente de sobre o dirección de rebote). Aquí es donde van las DSN (mensajes de rebote). Puede diferir del encabezado
From:. - RCPT TO especifica cada destinatario. Puedes tener múltiples comandos RCPT TO para un mensaje.
- El parámetro opcional
SIZE=permite al servidor rechazar mensajes de tamaño excesivo temprano. - Un
MAIL FROM:<>(ruta inversa vacía) se usa para los propios mensajes de rebote, para prevenir bucles de rebote infinitos.
Cada comando obtiene una respuesta individual. Un 250 significa aceptado. Un 550 en RCPT TO significa que el buzón no existe. Un 452 significa que el servidor es temporalmente incapaz de aceptar ese destinatario. El remitente debe manejar cada respuesta individualmente — algunos destinatarios pueden aceptarse mientras que otros se rechazan.
Paso 7: DATA — Envío del mensaje
El comando DATA comienza la transmisión del mensaje:
354 Start mail input; end with <CRLF>.<CRLF>
From: Alice <alice@example.com>
To: Bob <bob@example.net>
Subject: Meeting tomorrow
Date: Tue, 11 Mar 2026 10:30:00 -0400
Message-ID: <abc123@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Hi Bob,
Are we still on for 2pm?
- Alice
.
250 2.0.0 OK: queued as 4F3A21C8
El mensaje incluye tanto encabezados como cuerpo, separados por una línea en blanco. El mensaje se termina con una línea que contiene solo un punto (.) — la convención de "dot-stuffing". Cualquier línea en el cuerpo del mensaje que comience con un punto tiene un punto extra antepuesto durante la transmisión y se elimina en la recepción.
La respuesta 250 después de DATA significa que el mensaje ha sido aceptado para entrega. No significa que el mensaje haya sido entregado al buzón del destinatario. El servidor receptor aún puede rechazarlo durante el filtrado de contenido, o generar un rebote más tarde.
El ID de cola (por ejemplo, 4F3A21C8) es invaluable para depuración. Regístralo.
Paso 8: QUIT
221 2.0.0 Bye
El remitente cierra la sesión. La conexión TCP se rompe. Si el remitente tiene más mensajes para el mismo servidor, puede emitir otro MAIL FROM en lugar de QUIT para reutilizar la conexión.
Códigos de respuesta SMTP
Cada respuesta SMTP comienza con un código de tres dígitos. El primer dígito te dice la categoría:
| Código | Significado | Acción |
|---|---|---|
| 2xx | Éxito | Comando completado; procede |
| 3xx | Intermedio | El servidor está esperando más datos (por ejemplo, después de DATA) |
| 4xx | Fallo temporal | Reintentar más tarde. El servidor puede aceptar el mensaje en un intento posterior |
| 5xx | Fallo permanente | No reintentar. El mensaje nunca será aceptado tal como está |
Códigos comunes que encontrarás:
-
220— Servicio listo (banner) -
250— Acción solicitada completada -
354— Comenzar entrada de mensaje -
421— Servicio no disponible, cerrando conexión (reintentar más tarde) -
450— Buzón temporalmente no disponible (lista gris, limitación de velocidad) -
451— Acción solicitada abortada debido a error local -
452— Almacenamiento insuficiente -
550— Buzón no encontrado / acción no realizada -
551— Usuario no local; por favor intenta una dirección de reenvío -
552— Tamaño de mensaje excede el límite -
553— Nombre de buzón no permitido -
554— Transacción fallida (a menudo usado para rechazo de política)
Con ENHANCEDSTATUSCODES, el servidor añade un código más específico como 5.1.1 (buzón de destino incorrecto). Consulta Entendimiento de rebotes de correo electrónico para un desglose completo.
Una transacción completa
Aquí hay una sesión SMTP completa de conexión a cierre, anotada:
220 mx1.example.net ESMTP Postfix
# 2. El cliente se presenta a sí mismo
EHLO sender.mailertogo.com
250-mx1.example.net
250-STARTTLS
250-SIZE 26214400
250-PIPELINING
250-ENHANCEDSTATUSCODES
250 8BITMIME
# 3. Actualizar a TLS
STARTTLS
220 2.0.0 Ready to start TLS
# (El protocolo de enlace TLS se completa)
# 4. Reintroducir sobre canal cifrado
EHLO sender.mailertogo.com
250-mx1.example.net
250-SIZE 26214400
250-PIPELINING
250-ENHANCEDSTATUSCODES
250 8BITMIME
# 5. Sobre
MAIL FROM:<notifications@app.example.com>
250 2.1.0 OK
RCPT TO:<bob@example.net>
250 2.1.5 OK
# 6. Contenido del mensaje
DATA
354 End data with <CR><LF>.<CR><LF>
From: App Notifications <notifications@app.example.com>
To: bob@example.net
Subject: Your invoice is ready
Date: Tue, 11 Mar 2026 14:00:00 +0000
Message-ID: <inv-7842@app.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Your March invoice is ready. Log in to view it.
.
250 2.0.0 OK: queued as B9C4E1A3F
# 7. Hecho
QUIT
221 2.0.0 Bye
Envío vs. Retransmisión
SMTP sirve dos funciones distintas:
- Envío (puerto 587 o 465): Un cliente de correo envía un nuevo mensaje a su servidor de correo. Se requiere autenticación. El servidor asume la responsabilidad de entregarlo.
- Retransmisión (puerto 25): Un servidor de correo entrega un mensaje a otro. Sin autenticación — la autorización viene de DNS (registros MX) y verificación del remitente (SPF, DKIM).
Una retransmisión abierta — un servidor que acepta correo de cualquiera para cualquiera — es el pecado cardinal de la configuración de correo electrónico. Los spammers explotan retransmisiones abiertas inmediatamente. Cada servidor de correo moderno debe restringir la retransmisión a usuarios autenticados o remitentes conocidos.
¿Qué puede salir mal?
Conexión rechazada o tiempo agotado
El host MX está caído o cortado por firewall. La cola del remitente reintentos con retroceso exponencial, circulando a través de registros MX de menor prioridad. Después del período de reintento (típicamente 4-5 días), el mensaje rebota.
Lista gris
El servidor receptor devuelve 450 para el primer intento de un remitente desconocido. Los servidores legítimos reintentan; los spammers típicamente no. Tu mensaje se retrasará por minutos pero eventualmente se entregará.
Rechazado en RCPT TO
Una respuesta 550 5.1.1 User unknown significa que el buzón no existe. Este es un rebote duro. Elimina la dirección de tu lista inmediatamente.
Rechazado en DATA
El servidor puede aceptar el sobre pero rechazar el contenido. Razones comunes: mensaje demasiado grande, contenido marcado como spam, o verificaciones de autenticación fallidas (SPF/DKIM/DMARC). La respuesta viene después del punto de terminación.
Aceptado luego rebotado
El servidor devuelve 250 para DATA pero luego genera una DSN (mensaje de rebote) porque el buzón estaba sobre cuota, el filtrado de contenido lo rechazó, o ocurrió un error interno. Este es el caso más difícil de manejar — solo te enteras a través del mensaje de rebote enviado a la dirección MAIL FROM.
Fallos de TLS
Si la negociación de STARTTLS falla, la mayoría de los servidores recurren a texto plano. Este es un riesgo de seguridad — un atacante activo puede eliminar TLS. MTA-STS y DANE previenen esta degradación.
Puntos clave
- SMTP es un protocolo síncrono basado en texto. Cada comando obtiene un código de respuesta.
- El sobre (MAIL FROM / RCPT TO) es separado de los encabezados del mensaje (From: / To:). Pueden diferir.
- Un
250después de DATA significa "aceptado para entrega," no "entregado a la bandeja de entrada." - Los errores 4xx son temporales — reintentar. Los errores 5xx son permanentes — no reintentar.
- Siempre usa TLS. Refuérzalo con MTA-STS o DANE.
- Registra ID de cola de respuestas del servidor para depuración.