SMTP: la conversación entre servidores de correo
Módulo 1: Cómo funciona el correo electrónico · Tiempo de lectura: 10 minutos
Objetivo de aprendizaje: Después de esta lección podrá leer una conversación SMTP, explicar qué hacen EHLO, MAIL FROM, RCPT TO y DATA, y reconocer por el código de respuesta si un error es temporal o definitivo.
Conceptos clave: SMTP (RFC 5321), sesión, EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT, código de respuesta (2xx, 3xx, 4xx, 5xx), código de estado ampliado, extensiones (STARTTLS, AUTH, SIZE), null MX
Una conversación en texto plano
SMTP es un protocolo muy antiguo (la primera versión es de 1982) y por eso muy legible. Dos servidores se envían líneas de texto entre sí. El remitente (el cliente) envía un comando, el destinatario (el servidor) responde con un número de tres cifras y una breve explicación. Esta conversación se puede leer literalmente en un mensaje de error o en un registro, y por eso merece la pena entenderla.
A continuación, una conversación completa. S: es el servidor receptor, C: el servidor emisor. El correo va de anna@example.com a jan@example.net.
S: 220 mx1.mailprovider.example ESMTP ready
C: EHLO out.hosting.example
S: 250-mx1.mailprovider.example Hello out.hosting.example [192.0.2.25]
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
(a partir de aquí la conexión está cifrada; el cliente envía EHLO de nuevo)
C: EHLO out.hosting.example
S: 250 ...
C: MAIL FROM:<anna@example.com> SIZE=24310
S: 250 2.1.0 Ok
C: RCPT TO:<jan@example.net>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Anna <anna@example.com>
C: To: Jan <jan@example.net>
C: Subject: Offerte
C: Date: Sun, 8 Nov 2026 10:15:00 +0100
C: Message-ID: <a1b2c3@example.com>
C:
C: Hoi Jan, hierbij de offerte.
C: .
S: 250 2.0.0 Ok: queued as 4F2A1B
C: QUIT
S: 221 2.0.0 ByeLos comandos uno por uno
| Comando | Significado | Tenga en cuenta |
|---|---|---|
| (conexión) | El servidor saluda con 220 y su nombre. | Esto se llama el banner. Si el servidor responde directamente 554, no quiere hablar en absoluto con su IP (a menudo por una lista de bloqueo). |
EHLO nombre | "Hola, soy out.hosting.example." El servidor responde con las extensiones que conoce. | El nombre debe ser el nombre real del servidor emisor, preferiblemente igual a su registro PTR (lección 5.1). HELO es la variante antigua sin extensiones. |
STARTTLS | "A partir de ahora, cifremos." | Solo si el servidor lo ofrece. Entre servidores esto suele ser voluntario (lección 5.4). |
MAIL FROM:<dirección> | El remitente del sobre: aquí llegan los mensajes de error. | Más adelante se convierte en la cabecera Return-Path. SPF comprueba esta dirección. Los servidores usan un remitente vacío <> para sus propios mensajes de error, de modo que un rebote nunca genere otro rebote. |
RCPT TO:<dirección> | El destinatario. Puede repetirse varias veces, uno por destinatario. | Aquí es donde el servidor debería indicar si la dirección existe. Un 550 5.1.1 en este momento es un error claro y conocido de inmediato. |
DATA | "Ahora viene el correo en sí." El servidor responde 354. | A continuación vienen las cabeceras, una línea en blanco y el texto. Una línea con solo un punto cierra el mensaje. |
QUIT | Fin de la conversación. |
La idea más importante: todo antes de DATA es el sobre, todo después de DATA es el contenido. Lo que figura en MAIL FROM y lo que figura en la cabecera From: se proporcionan por separado y no tienen por qué coincidir. El servidor entrega según RCPT TO; la línea To: del contenido no influye en la entrega.
Los códigos de respuesta
La primera cifra del código es la más importante:
| Empieza por | Significado | ¿Qué hace el emisor? |
|---|---|---|
| 2 | Correcto. | Se continúa con el siguiente paso. 250 después de DATA significa: el servidor ha aceptado el correo y a partir de ahora es responsable de él. |
| 3 | Continúe, espero más. | Solo con 354 después de DATA (y al iniciar sesión). |
| 4 | Error temporal: ahora no, inténtelo más tarde. | El correo permanece en la cola y se vuelve a intentar más tarde. |
| 5 | Error definitivo: esto no va a funcionar. | El emisor desiste y envía un mensaje de error (rebote) al remitente del sobre. |
Después de las tres cifras, los servidores modernos añaden un código de estado ampliado con el formato class.subject.detail (RFC 3463), por ejemplo 5.1.1. La primera cifra vuelve a ser 2, 4 o 5. La segunda cifra indica de qué trata: 1 = dirección, 2 = buzón, 3 = sistema de correo, 4 = red y encaminamiento, 5 = protocolo, 6 = contenido, 7 = seguridad y política. Algunos que verá con frecuencia:
550 5.1.1 The email account that you tried to reach does not exist
452 4.2.2 Mailbox full (temporal)
552 5.3.4 Message size exceeds fixed limit
451 4.7.1 Greylisted, please try again later
550 5.7.1 Message rejected (política: spam, lista de bloqueo, DMARC)En el módulo 6 aprenderá a leer un rebote completo y encontrará una tabla con los códigos más frecuentes.
Por qué es tan importante distinguir entre temporal y definitivo
Un servidor que duda suele responder con un 4xx. Un ejemplo conocido es el greylisting: un servidor que aún no conoce a un remitente le dice la primera vez "inténtelo más tarde". Un servidor de correo real vuelve a intentarlo a los pocos minutos, pero muchos programas de spam no lo hacen. Los grandes proveedores también usan el 4xx para frenar el ritmo cuando todavía no confían en una dirección IP. Para usted, como emisor, esto significa: retraso, pero no pérdida. El sistema suele resolverlo por sí solo.
Un 5xx es diferente. En ese caso el emisor no volverá a intentarlo. Si recibe un 5xx, alguien debe cambiar algo: la dirección, el contenido o la configuración del dominio emisor.
Una trampa habitual: algunos servidores dan un 5xx aunque el problema sea temporal (por ejemplo, con un buzón lleno, 552 5.2.2), y otros dan un 4xx para algo que nunca va a funcionar. Lea siempre el texto que acompaña al código, no solo el número.
¿Quién es responsable?
Después del 250 en el punto final de DATA, la responsabilidad recae en el servidor receptor. Si posteriormente no consigue colocar el correo en el buzón, debe enviar él mismo un mensaje de error. Ahí está el origen de un fenómeno molesto: el backscatter. Un servidor que primero acepta todo y solo más tarde descubre que la dirección no existe, envía un rebote al remitente del sobre. Si ese remitente había sido falsificado por un spammer, el rebote llega a un tercero inocente. Por eso los servidores deben rechazar ya en RCPT TO lo que no sea válido (véase también catch-all en la lección 3.3).
En la práctica: ver SMTP en su propio entorno
Un usuario normal rara vez ve la conversación SMTP completa, pero sí la ve en fragmentos:
- en un rebote aparece la última línea de la conversación, por ejemplo
Remote-MTA: mx1.mailprovider.exampleyDiagnostic-Code: smtp; 550 5.1.1 ...; - en las cabeceras de un correo recibido aparece, por cada servidor, una línea
Received:con el nombre EHLO y la dirección IP (lección 1.5); - en un panel con registro de correo, como Seguimiento de E-Mail en DirectAdmin en WebOké, puede ver, por cada mensaje, la respuesta del servidor receptor. En otros proveedores esto puede llamarse, por ejemplo, seguimiento de mensajes o mail log, y el contenido es similar.
Por tanto, no necesita conectarse usted mismo a un servidor de correo para poder leer esto. Quien quiera probarlo: con openssl s_client -starttls smtp -connect server:25 puede mantener la conversación manualmente, pero muchos proveedores de acceso doméstico bloquean el tráfico saliente por el puerto 25 (lección 1.4).
Resumen
- SMTP es una conversación legible: EHLO, (STARTTLS), MAIL FROM, RCPT TO, DATA, QUIT.
- Todo antes de DATA es el sobre (entrega y mensajes de error), todo lo posterior es el contenido con las cabeceras que usted ve.
- 2xx = correcto, 4xx = temporal (se reintenta más tarde), 5xx = definitivo (rebote).
- El código ampliado
X.Y.Zindica de qué trata: X.1 dirección, X.2 buzón, X.7 política y seguridad. - Lea siempre el texto que acompaña al código; los servidores no siempre son coherentes.
Cuestionario
Ejercicio
Ejercicio Z1.2: Un dominio que no recibe correo. Busque los registros MX de example.com. Indique lo que encuentre y elija qué hace un servidor emisor con un correo dirigido a info@example.com: (a) entregarlo al servidor con prioridad 0, (b) probar con el registro A, (c) desistir de inmediato, o (d) volver a intentarlo más tarde. El programa consulta el registro MX en tiempo real y lo comprueba.
Para saber más
Los pasos de estos artículos corresponden a los paneles de WebOké; en otros proveedores el funcionamiento es similar.
- Cómo funciona el envío de correos (SMTP)
- Fallo en la entrega del correo: cómo interpretar el mensaje de error y qué significan los códigos
- Manual de DirectAdmin 9.3: Seguimiento de E-Mail: ¿dónde ha ido a parar mi correo?
- RFC 5321 (SMTP), apartados 3 y 4.2 (códigos de respuesta); RFC 3463 (códigos de estado ampliados); RFC 7505 (null MX)