RFC 6409 – Envío de Mensajes para Correo

Internet Standard Core SMTP & Message Format Obsoletes RFC 4409 Published March 2026

ELI5: Imagina la diferencia entre depositar una carta en un buzón público en la calle y entregársela al empleado en el mostrador de la oficina de correos. El buzón de la calle (puerto 25) es para que los carteros traspasen correo entre oficinas de correos. El mostrador (puerto 587) es donde tú, como cliente, entregas tu carta — primero muestras tu identificación, y el empleado verifica que todo esté en orden. RFC 6409 define ese mostrador de oficina de correos para correo electrónico.

Por qué existe este RFC

En los primeros días del correo electrónico, no había distinción entre un usuario que enviaba un mensaje nuevo y un servidor que retransmitía correo de otro servidor. Ambos usaban el puerto 25, y cualquiera podía conectarse y enviar. Esto llevó al problema de retransmisión abierta — los spammers explotaban cualquier servidor que aceptara y reenviara correo sin autenticación.

RFC 6409 (originalmente RFC 2476 en 1998, actualizado como RFC 4409 en 2006, y finalizado como 6409 en 2011) separa formalmente envío de mensajes de retransmisión de mensajes:

Envío (puerto 587): Un usuario autenticado o una aplicación envía un mensaje nuevo a su servicio de correo para su entrega. El servidor actúa como MSA (RFC 5598).
Retransmisión (puerto 25): Un servidor de correo transfiere un mensaje a otro servidor de correo en ruta hacia el destino. El servidor actúa como MTA.

Esta separación es fundamental para la seguridad del correo electrónico moderno. Permite la autenticación de remitentes, la aplicación de políticas y la capacidad de bloquear la retransmisión no autenticada mientras se aceptan envíos legítimos.

Cómo funciona

El envío de mensajes utiliza el mismo protocolo SMTP definido en RFC 5321, pero con diferencias importantes en comportamiento, política y número de puerto.

El proceso de envío

El cliente (MUA o aplicación) se conecta al MSA en el puerto 587.
El cliente emite EHLO y descubre las extensiones disponibles.
El cliente se actualiza a TLS usando STARTTLS (o se conecta mediante TLS implícito en el puerto 465 según RFC 8314).
El cliente se autentica usando AUTH (RFC 4954) — típicamente PLAIN o LOGIN sobre TLS.
El cliente envía el mensaje con MAIL FROM, RCPT TO y DATA.
El MSA valida el mensaje, potencialmente agrega encabezados faltantes (Date, Message-ID) y lo pone en cola para entrega a través de la infraestructura MTA.

Envío vs. Retransmisión: lado a lado

Aspecto	Envío (MSA, puerto 587)	Retransmisión (MTA, puerto 25)
Propósito	Aceptar mensajes nuevos de usuarios/aplicaciones	Transferir mensajes entre servidores
Autenticación	Requerida (SMTP AUTH)	No requerida (confianza servidor a servidor)
Cifrado	Requerido (STARTTLS o TLS implícito)	Oportunista (STARTTLS cuando está disponible)
Validación del remitente	MSA verifica que el usuario autenticado está autorizado a usar la dirección De	MTA verifica SPF, DKIM, DMARC
Corrección de encabezados	MSA puede agregar encabezados faltantes Date, Message-ID y MIME	MTA agrega solo encabezado Received
Quién se conecta	Usuarios finales, aplicaciones, servicios de correo	Otros servidores de correo

Ejemplo SMTP

Una sesión de envío típica en el puerto 587:

# El cliente se conecta al puerto 587 S: 220 smtp.mailertogo.com ESMTP Submission C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-STARTTLS S: 250-AUTH PLAIN LOGIN S: 250-SIZE 26214400 S: 250-8BITMIME S: 250 ENHANCEDSTATUSCODES # Actualizar a TLS primero C: STARTTLS S: 220 2.0.0 Ready to start TLS # El protocolo de enlace TLS ocurre aquí, luego re-EHLO C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-AUTH PLAIN LOGIN S: 250-SIZE 26214400 S: 250-8BITMIME S: 250 ENHANCEDSTATUSCODES # Autenticarse (credenciales codificadas en Base64) C: AUTH PLAIN AGFsaWNlQGV4YW1wbGUuY29tAHNlY3JldA== S: 235 2.7.0 Authentication successful # Ahora enviar el mensaje C: MAIL FROM:<notifications@example.com> S: 250 2.1.0 OK C: RCPT TO:<user@recipient.com> S: 250 2.1.5 OK C: DATA S: 354 Start mail input C: From: Example App <notifications@example.com> C: To: user@recipient.com C: Subject: Your order has shipped C: Date: Wed, 11 Mar 2026 14:00:00 +0000 C: Message-ID: <order-12345@example.com> C: C: Your order #12345 has been shipped and is on its way. C: . S: 250 2.0.0 OK, queued as abc123 C: QUIT S: 221 2.0.0 Bye

Detalles técnicos clave

La autenticación es obligatoria

RFC 6409 establece que un MSA DEBERÍA requerir autenticación y NO DEBE aceptar mensajes para retransmisión de clientes no autenticados a menos que exista una política organizacional específica que lo permita. En la práctica, todo servidor de envío moderno requiere autenticación. El mecanismo estándar es SMTP AUTH (RFC 4954) usando mecanismos PLAIN o LOGIN, siempre sobre TLS.

Corrección de encabezados por el MSA

A diferencia de un MTA (que no debe alterar el contenido del mensaje), se espera que un MSA examine y corrija el mensaje enviado:

Agregar encabezado Date faltante si el cliente no incluyó uno.
Agregar Message-ID faltante para asegurar que cada mensaje tenga un identificador único.
Verificar que la dirección De coincida con la identidad autenticada, o agregar un encabezado Sender: para indicar la entidad transmisora real.
Agregar encabezados de seguimiento — el MSA agrega su propio encabezado Received: como primera entrada.

Puerto 465: TLS implícito

Históricamente, el puerto 465 fue brevemente asignado para "SMTPS" (SMTP sobre TLS implícito), luego reasignado, y luego re-estandarizado por RFC 8314 en 2018. Hoy, el puerto 465 con TLS implícito es el enfoque recomendado para envío — el protocolo de enlace TLS ocurre inmediatamente después de la conexión, antes de cualquier comando SMTP. El puerto 587 con STARTTLS sigue siendo ampliamente compatible y válido.

Límites de tamaño y velocidad

Los MSA típicamente aplican límites más estrictos que los MTA:

Límites de tamaño de mensaje (comúnmente 10-25 MB)
Límites de velocidad por usuario autenticado (para evitar que cuentas comprometidas envíen spam)
Límites de conteo de destinatarios por mensaje y por período de tiempo
Restricciones de dirección de remitente (solo puedes enviar desde direcciones que estés autorizado a usar)

Errores comunes

Enviar en el puerto 25 desde una aplicación. Las aplicaciones siempre deben enviar a través del puerto 587 (o 465) con autenticación. Enviar directamente a un MX de destinatario en el puerto 25 evita la autenticación de tu servicio de correo, firma DKIM y gestión de reputación. La mayoría de plataformas en la nube (AWS, GCP, Azure) bloquean el puerto 25 saliente por defecto.
No usar TLS antes de AUTH. Enviar credenciales sobre una conexión sin cifrar expone tu nombre de usuario y contraseña SMTP. Siempre usa STARTTLS antes de AUTH, o usa TLS implícito en el puerto 465.
Confundir credenciales de envío con credenciales de buzón. Algunos servicios usan credenciales separadas para envío SMTP versus acceso IMAP/POP. Consulta la documentación de tu proveedor.
Ignorar respuestas de rechazo del MSA. Si el MSA rechaza tu mensaje (p. ej., dirección de remitente no autorizada, mensaje demasiado grande), tu aplicación necesita manejar esto con elegancia, no dejar caer silenciosamente el error.
Codificar el puerto 25 en el código de aplicación. Las aplicaciones antiguas que se conectan al puerto 25 para envío causan problemas de entregabilidad y pueden dejar de funcionar completamente a medida que los ISP y proveedores en la nube bloquean cada vez más este puerto para uso que no sea de servidor.
No volver a emitir EHLO después de STARTTLS. Después de que se completa el protocolo de enlace TLS, debes enviar un EHLO nuevo. La lista de capacidades del servidor puede cambiar (AUTH típicamente solo se anuncia después de que se establece el cifrado).

Impacto en la entregabilidad

La autenticación habilita la firma DKIM. Cuando envías a través de un MSA, el servicio puede aplicar firmas DKIM a tus mensajes. Enviar directamente a MTA remotos evita esto, lo que significa que tus mensajes llegan sin firma y es más probable que se marquen como spam.
Verificación de identidad del remitente. El MSA verifica que estés autorizado a enviar desde la dirección que reclamas. Esto impide que tu cuenta se use para suplantar otros dominios y mantiene tu reputación de envío.
Gestión de reputación. Tu servicio de correo (MSA) mantiene reputación de IP compartida. Al enrutar a través del envío, tus mensajes se benefician de la reputación establecida del servicio con proveedores importantes de buzones.
Procesamiento de bucle de retroalimentación. Un MSA que procesa tus mensajes puede rastrear rebotes, quejas y estado de entrega, proporcionando los datos que necesitas para mantener la higiene de lista y proteger tu reputación de envío.
TLS en todas partes. Enviar sobre TLS (obligatorio para envío) asegura que tu mensaje esté cifrado desde tu aplicación al servicio de correo. El servicio luego maneja el cifrado para el siguiente salto, dándote protección de extremo a extremo en tránsito.