← RFC Reference

Anatomía de los Encabezados de Correo Electrónico

Cada campo de encabezado importante en un mensaje de correo explicado — qué significa, quién lo establece y por qué importa. Incluye un ejemplo real completamente anotado.

Un Ejemplo Completo

Aquí están los encabezados de un correo real, de arriba a abajo, tal como aparecen en el buzón de un destinatario. Analizaremos cada uno.

Ahora revisemos cada encabezado.

Encabezados de Identidad

From

El autor del mensaje, según lo define RFC 5322. Esto es lo que el destinatario ve en su cliente de correo. Consiste en un nombre para mostrar opcional (Alice) y una dirección de buzón (alice@example.com). Las verificaciones de alineación DMARC se realizan contra el dominio en este encabezado.

From no es lo mismo que el remitente del sobre. El remitente del sobre (MAIL FROM en SMTP) puede ser completamente diferente. El encabezado From: lo establece el autor del mensaje; el remitente del sobre lo establece el sistema de envío.

To, Cc, Bcc

To: y Cc: son encabezados de visualización — indican la audiencia prevista pero no controlan la entrega. Los destinatarios reales se determinan por los comandos SMTP RCPT TO, que pueden incluir destinatarios Bcc no enumerados en ningún encabezado. Un mensaje puede tener un encabezado To: listando direcciones que no están en RCPT TO, y viceversa (así es como funciona Bcc).

Reply-To

No aparece en nuestro ejemplo, pero es común. Especifica dónde deben dirigirse las respuestas si es diferente de From:. A menudo se usa cuando un mensaje se envía desde una dirección de no-respuesta pero las respuestas deben ir a soporte:

Sender

Se usa cuando la entidad responsable del envío difiere del autor. Si la asistente de Alice envía un mensaje en su nombre, los encabezados podrían leer From: Alice y Sender: Assistant. La mayoría de los mensajes omiten este encabezado.

Identificación de Mensajes

Message-ID

Un identificador único global para este mensaje, generado por el remitente. El formato es <parte-única@dominio>. Esto es crítico para enhebrado, deduplicación y correlación de rechazos. Cada mensaje debe tener uno. Si su sistema de envío no lo establece, el primer MTA generará uno — pero entonces perderá la capacidad de correlacionar rechazos con mensajes enviados específicos.

In-Reply-To y References

Se usa para enhebrado. In-Reply-To contiene el Message-ID del mensaje al que se responde. References contiene la cadena completa de valores Message-ID en el hilo. Los clientes de correo utilizan estos para agrupar conversaciones:

Fecha y Asunto

Date

La fecha y hora en que se redactó el mensaje, establecido por el remitente. El formato se especifica en RFC 5322. No es la hora de entrega. Un mensaje puede permanecer en una cola durante horas o días antes de la entrega. Siempre incluya un desplazamiento de zona horaria.

Subject

Texto de forma libre que resume el mensaje. Sin límite de longitud en la especificación, pero los clientes de correo truncan en longitudes variables. Manténgalo por debajo de 60 caracteres para una visualización consistente. Los caracteres que no son ASCII deben codificarse utilizando la codificación RFC 2047 (p. ej., =?UTF-8?Q?...?=), aunque la mayoría de los sistemas de correo modernos manejan esto de manera transparente.

La Cadena Received

Cada servidor que maneja el mensaje antepone un encabezado Received:. Se leen de abajo a arriba — el salto más antiguo está en la parte inferior, el más reciente en la parte superior. Cada encabezado registra:

• from — El servidor que envió el mensaje (nombre de host e IP)
• by — El servidor que lo recibió
• with — El protocolo utilizado (ESMTP, ESMTPS para TLS, LMTP para entrega local)
• id — El ID de cola del servidor receptor
• for — El destinatario (puede omitirse por privacidad con múltiples destinatarios)
• marca de tiempo — Cuándo este salto recibió el mensaje

La cadena Received es invaluable para depurar retrasos en la entrega. Compare marcas de tiempo entre saltos para encontrar dónde se perdió tiempo. Nota: los encabezados Received: del lado del remitente pueden ser falsificados. Solo confíe en encabezados añadidos por su propia infraestructura.

Return-Path

Establecido por el MTA que entrega finalmente, esto registra el remitente del sobre SMTP (MAIL FROM). Aquí es donde se envían los rechazos. En este ejemplo, se usa codificación VERP — el destinatario original (alice@example.com) se codifica en la parte local de la dirección de rechazo.

El Return-Path no lo establece el autor del mensaje; se extrae de la sesión SMTP y se añade por el servidor que entrega. Debe haber exactamente un encabezado Return-Path en un mensaje entregado.

Encabezados de Autenticación

DKIM-Signature

Añadido por el servidor de envío. El campo d= identifica el dominio de firma (utilizado para alineación DMARC). El campo s= es el selector usado para buscar la clave pública en DNS. El campo h= enumera qué encabezados están firmados. Ver Explicación de Autenticación de Correo para el proceso de verificación completo.

Authentication-Results

Añadido por el servidor receptor (RFC 8601). Este es el registro autoritativo de verificaciones de autenticación para este mensaje en este salto. El authserv-id (mx1.example.net) identifica qué servidor realizó la verificación. Registra resultados SPF, DKIM y DMARC, incluyendo los identificadores verificados.

Nota de seguridad: Los encabezados Authentication-Results falsificados de fuentes externas deben ser eliminados por el MTA de frontera. Solo confíe en este encabezado cuando sea añadido por su propia infraestructura.

Encabezados MIME

MIME-Version

Indica que el mensaje usa MIME (RFC 2045). Siempre es 1.0 y debe estar presente en cada mensaje. Sin él, el mensaje se interpreta como texto sin formato US-ASCII.

Content-Type

Describe el tipo de medio del cuerpo del mensaje. Valores comunes:

• text/plain — Texto sin formato
• text/html — Contenido HTML
• multipart/alternative — Múltiples versiones del mismo contenido (típicamente texto e HTML). El cliente de correo elige la mejor.
• multipart/mixed — Mensaje con archivos adjuntos
• multipart/related — HTML con imágenes incrustadas

El parámetro boundary define el delimitador entre partes MIME. Ver RFC 2046 para detalles.

Content-Transfer-Encoding

Cómo se codifica el cuerpo para transporte seguro. Valores comunes: 7bit, quoted-printable, base64. Los archivos adjuntos usan base64. Los cuerpos de correo HTML típicamente usan quoted-printable para manejar caracteres que no son ASCII mientras permanecen mayormente legibles.

Encabezados de Gestión de Listas

RFC 2369 define List-Unsubscribe, que proporciona una URL y/o dirección mailto para desuscripción. RFC 8058 añade List-Unsubscribe-Post, habilitando desuscripción de un clic directamente desde la UI del cliente de correo sin abrir un navegador. Gmail y otros proveedores principales requieren ambos encabezados para correo en masa y de marketing.

Encabezados que No Debería Ver (Pero A Veces Sí)

X-Mailer / User-Agent

Identifica el cliente de correo o software de envío. A veces usado por filtros de spam como una señal. Los sistemas de envío modernos a menudo omiten esto para reducir la superficie de huella digital.

X-Priority / Importance

Encabezados no estándar que intentan establecer la prioridad del mensaje. La mayoría de los clientes de correo los ignoran. Algunos filtros de spam tratan los marcados de alta prioridad como una señal negativa.

X-Spam-Status / X-Spam-Score

Añadidos por sistemas de filtrado de spam (como SpamAssassin). No estandarizado, pero ampliamente usado internamente. Estos no deben estar presentes en el correo saliente — se añaden por la infraestructura receptora.

Qué Puede Salir Mal

Message-ID Faltante

Si no establece un Message-ID, el primer MTA añade uno. Pero pierde la capacidad de correlacionar mensajes enviados con rechazos y notificaciones de entrega. Siempre genere su propio Message-ID antes de enviar.

Confusión entre From y remitente del sobre

Una fuente común de problemas de entregabilidad. El encabezado From: muestra alice@example.com, pero el remitente del sobre es bounce@esp.com. SPF valida el dominio ESP, no su dominio. Si su firma DKIM también usa d=esp.com, la alineación DMARC falla para ambos mecanismos. La solución: firme con d=example.com para que DKIM se alinee.

Encabezados duplicados o conflictivos

RFC 5322 especifica que algunos encabezados (como From:, Date:, Message-ID:) deben aparecer exactamente una vez. Los duplicados pueden causar comportamiento impredecible — diferentes clientes de correo pueden elegir valores diferentes. Algunos filtros de spam tratan los encabezados From: duplicados como sospechosos.

Encabezado Date Faltante

Sin un encabezado Date:, el MTA receptor o cliente de correo sustituirá su propia marca de tiempo, que puede diferir significativamente. Algunos filtros de spam penalizan mensajes sin encabezado Date.

Falsificación de cadena Received

Cualquiera puede anteponer encabezados Received: falsos a un mensaje antes de enviarlo. El MTA receptor solo puede confiar en encabezados que añadió él mismo. Al depurar, comience desde la parte superior (más reciente) y trabaje hacia abajo, y deje de confiar una vez que llegue a la frontera entre su infraestructura y el mundo externo.

Puntos Clave

• Los encabezados son metadatos sobre el mensaje. El **sobre** (MAIL FROM / RCPT TO) controla la entrega; los encabezados son para visualización y procesamiento.
• From: es lo que el destinatario ve. Return-Path: es dónde van los rechazos. A menudo son diferentes.
• Los encabezados Received: forman una cadena de abajo a arriba mostrando la ruta del mensaje. Solo confíe en encabezados de su propia infraestructura.
• Authentication-Results: es el veredicto del servidor receptor en SPF, DKIM y DMARC.
• Siempre establezca Message-ID, Date, From, MIME-Version y Content-Type.
• Para correo en masa/marketing, incluya List-Unsubscribe y List-Unsubscribe-Post.

Lecturas Adicionales

Related RFCs