Campos de cabecera de correo explicados: Received, From, Return-Path y más

La versión corta

1. Dónde encontrar las cabeceras. Toda aplicación de correo tiene una forma de mostrar las cabeceras completas, a menudo llamada Mostrar original, Ver código fuente o Detalles del mensaje.
2. Los campos que ve la gente: From, To, Subject, Date. From, To, Subject y Date son los campos que muestra una aplicación de correo.
3. Received: la ruta. Cada servidor que gestiona un mensaje añade una línea Received en la parte superior.
4. Return-Path, Reply-To y Message-ID. Return-Path contiene el remitente del sobre, la dirección a la que se envían los rebotes y contra la que se comprueba SPF.
5. Authentication-Results. El servidor receptor registra sus veredictos de SPF, DKIM y DMARC en una línea Authentication-Results, junto con los identificadores que comprobó, como smtp.mailfrom y header.d.
6. DKIM-Signature. Un campo DKIM-Signature lleva el dominio firmante en d=, el selector en s=, el algoritmo de firma en a= y la lista de campos firmados en h=.

Dónde encontrar las cabeceras

Toda aplicación de correo tiene una forma de mostrar las cabeceras completas, a menudo llamada Mostrar original, Ver código fuente o Detalles del mensaje. Copie todo desde la primera línea hasta la primera línea en blanco, porque esa línea en blanco es donde terminan las cabeceras y empieza el cuerpo del mensaje.

Puede pegarlas en nuestro analizador de cabeceras de correo, que ordena la ruta, los retrasos y los resultados de autenticación.

Los campos que ve la gente: From, To, Subject, Date

From, To, Subject y Date son los campos que muestra una aplicación de correo. Los establece el remitente y pueden decir cualquier cosa, por lo que por sí solos no prueban de dónde procede un mensaje. Un nombre para mostrar puede incluir una dirección distinta de la real, un truco habitual de suplantación.

El campo Date registra cuándo redactó el remitente el mensaje. Compárelo con las horas de las líneas Received para detectar retrasos largos.

Received: la ruta

Cada servidor que gestiona un mensaje añade una línea Received en la parte superior. Cada una registra de qué servidor recibió el mensaje, qué servidor es, el protocolo y una marca de tiempo. Léalas de abajo hacia arriba para seguir la ruta en orden.

Received: from mail.example.net (mail.example.net [203.0.113.5])
        by mx.example.org with ESMTPS id abc123
        for <you@example.org>; Tue, 13 Oct 2026 16:14:12 +0000

El intervalo entre dos marcas de tiempo es el tiempo que el mensaje pasó en un salto. Los intervalos grandes suelen indicar una cola, greylisting o un reintento. Las líneas situadas por debajo del primer servidor de confianza pueden haber sido escritas por el remitente, así que trátelas con cautela.

Return-Path, Reply-To y Message-ID

Return-Path contiene el remitente del sobre, la dirección a la que se envían los rebotes y contra la que se comprueba SPF. Lo añade el servidor receptor. Reply-To indica adónde deben ir las respuestas y, cuando difiere de From, merece una segunda mirada. Message-ID es un identificador único del mensaje, que normalmente termina con el dominio del sistema de envío.

Un Message-ID cuyo dominio difiere del dominio de From es habitual cuando un servicio envía en su nombre y no es un fallo por sí mismo.

Authentication-Results

El servidor receptor registra sus veredictos de SPF, DKIM y DMARC en una línea Authentication-Results, junto con los identificadores que comprobó, como smtp.mailfrom y header.d. Esta es la línea que debe leer primero cuando el correo falla, y solo es fiable cuando la escribió su propio servidor receptor.

Authentication-Results: mx.example.org;
 spf=pass smtp.mailfrom=bounce.example.net;
 dkim=pass header.d=example.net header.s=s1;
 dmarc=fail header.from=example.com

Pass, fail, softfail, neutral, none, temperror y permerror son los valores habituales. Un fallo de DMARC con SPF y DKIM aprobados casi siempre significa que los dominios aprobados no están alineados con From.

DKIM-Signature

Un campo DKIM-Signature lleva el dominio firmante en d=, el selector en s=, el algoritmo de firma en a= y la lista de campos firmados en h=. El receptor usa d= y s= para encontrar la clave pública en DNS y verificar la firma.

Compruebe que d= sea su propio dominio y que h= incluya From. Una firma creada con a=rsa-sha1 es antigua y débil, y la etiqueta l=, que limita qué parte del cuerpo se firma, permite añadir texto después de la firma.

List-Unsubscribe y otros campos útiles

El correo de marketing debe llevar List-Unsubscribe y, para la baja con un clic, List-Unsubscribe-Post, que Gmail y Yahoo piden a los remitentes masivos que admitan. Algunos receptores añaden campos de filtro de spam, como X-Spam-Status, que muestran cómo se puntuó el mensaje.

Los campos ARC muestran que un reenviador o una lista de correo registró el resultado de autenticación que vio, lo que explica por qué SPF puede fallar al final de un mensaje reenviado.

Lecturas adicionales y fuentes

• RFC 5322: Internet Message Format
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 5321: Simple Mail Transfer Protocol

Hágalo en MigoSMTP: artículos del centro de ayuda

• Lea las cabeceras de correo para depurar la autenticación
• Códigos de rebote SMTP explicados
• Dominios personalizados de return-path y de seguimiento

Guías y herramientas relacionadas

• Analizador de cabeceras de correo: Pegue las cabeceras y obtenga la ruta y los resultados.
• Verificador de SPF, DKIM y DMARC: Compruebe los registros en vivo.
• Solucione fallos de SPF, DKIM y DMARC: Interprete un error y corríjalo.
• Política DMARC explicada: Qué significa la alineación.