RFC 5321 – Protocolo simple de transferencia de correo

Current Standard Core SMTP & Message Format Obsoletes RFC 2821 Published March 2026

ELI5: SMTP es el servicio postal de internet. Cuando envías un correo electrónico, tu servidor de correo abre una conversación con el servidor de correo del destinatario, se presenta, dice quién envía la carta y a quién va dirigida, luego entrega la carta. El servidor receptor la acepta, dice "intenta más tarde" o la rechaza rotundamente. Cada correo electrónico que has enviado ha viajado por SMTP.

Por qué existe este RFC

SMTP es el protocolo más antiguo y fundamental que impulsa el correo electrónico. Su linaje se remonta a RFC 821, publicado en 1982 por Jon Postel. RFC 5321, publicado en 2008, es la especificación definitiva actual. Consolidó décadas de extensiones, aclaraciones y experiencia operativa en un único documento autorizado.

La evolución clave de RFC 821 a 5321 incluye: formalización de ESMTP (SMTP Extendido), aclaración del comportamiento de retransmisión versus envío, requisitos más estrictos para búsquedas de DNS MX, reglas actualizadas para literales de dirección e IPv6, y requisitos para manejo de rebotes. Este RFC es la base sobre la que se construyen todos los demás RFC de correo electrónico.

Cómo funciona

Una transacción SMTP es una conversación estructurada entre dos servidores a través de una conexión TCP (tradicionalmente puerto 25). El protocolo es basado en texto y orientado a líneas — cada comando y respuesta es ASCII legible por humanos.

El modelo SMTP

SMTP define tres funciones:

Cliente SMTP (Sender-SMTP): El sistema que inicia la conexión para transferir un mensaje.
Servidor SMTP (Receiver-SMTP): El sistema que acepta la conexión y recibe el mensaje.
Retransmisión SMTP: Un servidor que recibe un mensaje y lo reenvía hacia su destino final, actuando como cliente y servidor.

El cliente se conecta, se identifica con EHLO, especifica el remitente del sobre (MAIL FROM), uno o más destinatarios (RCPT TO), luego transmite los datos del mensaje (DATA). El servidor responde a cada comando con un código de estado de tres dígitos.

Los comandos SMTP

Comando	Propósito
`EHLO`	Identificar cliente y solicitar características extendidas. Reemplazó el anterior `HELO`.
`MAIL FROM:<addr>`	Especificar el remitente del sobre (ruta de retorno para rebotes).
`RCPT TO:<addr>`	Especificar un destinatario. Se emite una vez por destinatario.
`DATA`	Comenzar la transmisión del contenido del mensaje. Termina con un `.` solo en una línea.
`RSET`	Abortar la transacción actual y reiniciar el estado.
`VRFY`	Verificar que existe un usuario (raramente compatible debido al abuso).
`EXPN`	Expandir una lista de correo (raramente compatible).
`NOOP`	Sin operación; mantener la conexión activa.
`QUIT`	Cerrar la conexión.

Códigos de respuesta

Cada respuesta del servidor comienza con un código de tres dígitos. El primer dígito le dice al cliente qué sucedió:

2xx — Éxito. La acción solicitada se completó.
3xx — Intermedio. El servidor necesita más entrada (se usa después de DATA).
4xx — Fallo temporal. El cliente debe reintentar más tarde. Ejemplos: buzón lleno (452), servidor ocupado (421).
5xx — Fallo permanente. No reintentar. Ejemplos: usuario desconocido (550), error de sintaxis (500), retransmisión denegada (553).

El segundo dígito restringe la categoría: x0x = sintaxis, x1x = información, x2x = conexión, x5x = sistema de correo. RFC 3463 extiende esto aún más con códigos de estado mejorados como 5.1.1 (buzón de destino incorrecto).

Detalles técnicos clave

Sobre versus encabezados

Una distinción crítica en SMTP es entre el sobre y los encabezados del mensaje. El sobre (MAIL FROM y RCPT TO) controla el enrutamiento — le dice a los servidores dónde entregar el mensaje. Los encabezados del mensaje (From:, To:, Subject:) son parte del cuerpo del mensaje transmitido durante DATA y es lo que ve el destinatario. Estos pueden diferir, y legítimamente lo hacen en casos como listas de correo, copia oculta y reenvío.

Proceso de búsqueda de MX

Cuando un cliente necesita entregar a user@example.com, consulta DNS para registros MX de example.com. El proceso definido por RFC 5321:

Buscar registros MX para el dominio. Ordenar por preferencia (número menor = mayor prioridad).
Si no existen registros MX, recurrir a un registro A o AAAA para el dominio mismo.
Si un registro MX apunta a . (un "MX nulo" según RFC 7505), el dominio no acepta correo.
Intentar cada host MX en orden de prioridad. Si un servidor devuelve un error 4xx, intentar el siguiente host.

Longitud de línea y transparencia de datos

SMTP requiere que las líneas en el mensaje no sean más largas que 998 caracteres (excluyendo CRLF), con un límite recomendado de 78 caracteres. El marcador de fin de datos es una línea que contiene solo un punto (.). Si una línea en el cuerpo del mensaje comienza con un punto, el cliente debe "rellenarla de puntos" anteponiendo un punto adicional, y el servidor debe eliminarlo.

Tiempos de espera

RFC 5321 especifica tiempos de espera mínimos que los clientes DEBEN observar:

Saludo inicial: 5 minutos
Comando MAIL: 5 minutos
Comando RCPT: 5 minutos
Inicio de DATA: 2 minutos
Bloque de datos: 3 minutos
Terminación de DATA (punto final): 10 minutos

Estos generosos tiempos de espera existen porque los servidores receptores pueden realizar controles costosos (filtrado de spam, escaneo de virus) antes de responder al punto final.

Ejemplo de SMTP

Una transacción SMTP completa entregando un mensaje:

# El cliente se conecta al puerto 25 del servidor MX del destinatario S: 220 mx.example.com ESMTP listo C: EHLO sender.example.net S: 250-mx.example.com Hola sender.example.net S: 250-SIZE 52428800 S: 250-8BITMIME S: 250-STARTTLS S: 250-ENHANCEDSTATUSCODES S: 250 PIPELINING # Remitente del sobre (ruta de retorno para rebotes) C: MAIL FROM:<alice@sender.example.net> S: 250 2.1.0 OK # Destinatario del sobre C: RCPT TO:<bob@example.com> S: 250 2.1.5 OK # Comenzar datos del mensaje C: DATA S: 354 Comenzar entrada de correo; terminar con <CRLF>.<CRLF> C: From: Alice <alice@sender.example.net> C: To: Bob <bob@example.com> C: Subject: Reunión mañana C: Date: Wed, 11 Mar 2026 10:00:00 -0500 C: Message-ID: <abc123@sender.example.net> C: C: Hola Bob, ¿seguimos en pie para mañana? C: . S: 250 2.0.0 OK, mensaje aceptado para entrega C: QUIT S: 221 2.0.0 mx.example.com cerrando conexión

Errores comunes

Confundir direcciones de sobre y encabezado. La dirección del sobre MAIL FROM no es lo mismo que el encabezado From:. SPF verifica el remitente del sobre; DKIM firma el encabezado. Cometer esto causa fallos de autenticación.
Ignorar la distinción 4xx versus 5xx. Un 450 significa "intentar más tarde" — debe poner en cola y reintentar con retroceso exponencial. Un 550 significa "nunca funcionará" — continuar reintentando genera tráfico innecesario y puede dañar su reputación de remitente.
No manejar respuestas multilínea. Una respuesta como 250- (con un guión) significa que siguen más líneas. Solo 250 (con un espacio) señala la línea final.
Enviar sin EHLO. Usar el comando anterior HELO en lugar de EHLO significa que no descubrirá extensiones de servidor como STARTTLS, SIZE o PIPELINING. Siempre use EHLO.
Exceder límites de longitud de línea. Las líneas superiores a 998 caracteres violan la especificación y pueden causar corrupción de mensajes. Use codificación MIME para contenido largo.
Ignorar el remitente nulo. Los mensajes de rebote (DSN) usan un MAIL FROM:<> vacío. Rechazar el remitente nulo rompe el mecanismo de prevención de bucles de rebote.
No implementar relleno de puntos. Si el cuerpo del mensaje tiene una línea que comienza con ., el servidor la interpretará como fin de datos a menos que duplique el punto.

Impacto en la entregabilidad

El cumplimiento de RFC 5321 afecta directamente si su correo electrónico llega a la bandeja de entrada:

Nombre de host EHLO adecuado. Su nombre de host EHLO debe resolverse en DNS (directo e inverso). Muchos servidores receptores verifican que el nombre EHLO tenga un registro A/AAAA válido y que el DNS inverso de su IP coincida. Las discrepancias son una señal de spam.
Manejo de rebotes. RFC 5321 requiere que los remitentes procesen rebotes. Si ignora los DSN, seguirá enviando a direcciones inválidas, lo que destruye su reputación de remitente. Los proveedores de buzones rastrean su tasa de rebote de cerca.
Comportamiento de reintentos. La lógica adecuada de reintentos con retroceso exponencial para errores 4xx muestra que es un remitente bien comportado. El comportamiento agresivo de reintentos puede activar limitaciones de velocidad o inclusion en listas negras.
Comportamiento de conexión. Abrir demasiadas conexiones simultáneas a un solo MX, o reconectarse demasiado rápidamente después de ser rechazado, son patrones asociados con spam. Respete los límites de conexión y acelere adecuadamente.
Alineación de sobre. SPF y DMARC se basan en el dominio MAIL FROM. Asegurar que su dominio remitente del sobre se alinee con su dominio de encabezado From: es esencial para pasar verificaciones de autenticación.