Cómo leer los encabezados de un correo para depurar la entrega

El encabezado de un correo es un registro escrito por cada servidor por el que pasó el mensaje, con la entrada más reciente arriba. Para depurar problemas de entrega, lee tres cosas: la línea Authentication-Results que agregó tu propio proveedor de correo, la cadena Received de abajo hacia arriba para ver la ruta y los retrasos, y los dominios de DKIM-Signature y Return-Path para revisar la alineación con From.

Este artículo recorre línea por línea encabezados reales y publicados. Si intentas averiguar por qué un mensaje concreto cayó en la carpeta de spam de Gmail, empieza por el diagnóstico de spam en Gmail, que es más corto, y vuelve aquí cuando necesites entender qué significa una línea.

Cómo obtener el encabezado completo

Todos los clientes de correo importantes pueden mostrar el encabezado sin procesar, normalmente en una opción llamada "Show original" (Mostrar original), "View source" (Ver código fuente) o "View message details" (Ver detalles del mensaje).

• Gmail (web): abre el mensaje, haz clic en Más junto a Responder y luego en Show original (Mostrar original). La página de ayuda de Google dice que el encabezado completo se abre en una ventana nueva con un botón Copy to clipboard (Copiar al portapapeles).
• Outlook y Apple Mail: ambos muestran el código fuente desde la vista del mensaje; el nombre del menú cambia según la versión, así que busca "view message headers" en la ayuda de tu cliente.

Copia siempre el encabezado del lado del destinatario. La copia de tu carpeta de Enviados no pasó por los servidores receptores, así que no tiene sus líneas Received ni el Authentication-Results del receptor, que son las líneas que importan.

La regla que hace legibles los encabezados

Cada servidor agrega sus líneas arriba, así que el encabezado se lee como una pila: lo más reciente arriba y el origen abajo.

No es una convención, es el protocolo. El RFC 5321, sección 4.4 dice: "SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location." (Los servidores SMTP DEBEN anteponer las líneas Received a los mensajes; NO DEBEN cambiar el orden de las líneas existentes ni insertar líneas Received en ningún otro lugar.)

Dos consecuencias prácticas:

1. Para seguir la ruta, lee las líneas Received de abajo hacia arriba.
2. Las líneas de arriba las escribió tu propio proveedor. Las de abajo las escribieron servidores que nunca has visto, y algunas pudo haberlas escrito el remitente. La confianza disminuye a medida que bajas.

Un encabezado real, comentado

El ejemplo real más limpio de un encabezado con varios saltos y resultados de autenticación está en la propia especificación. Este es el Ejemplo 5 del RFC 8601, Apéndice B.5, citado tal cual (la firma DKIM aparece recortada con ... en el original):

Authentication-Results: example.com;
          dkim=pass (good signature) header.d=example.com
Received: from mail-router.example.com
              (mail-router.example.com [192.0.2.1])
          by auth-checker.example.com (8.11.6/8.11.6)
              with ESMTP id i7PK0sH7021929;
          Fri, Feb 15 2002 17:19:22 -0800
DKIM-Signature:  v=1; a=rsa-sha256; s=gatsby; d=example.com;
          t=1188964191; c=simple/simple; h=From:Date:To:Subject:
          Message-Id:Authentication-Results;
          bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
          b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
Authentication-Results: example.com;
          auth=pass (cram-md5) smtp.auth=sender@example.com;
          spf=fail smtp.mailfrom=example.com
Received: from dialup-1-2-3-4.example.net
              (dialup-1-2-3-4.example.net [192.0.2.200])
          by mail-router.example.com (8.11.6/8.11.6)
              with ESMTPA id g1G0r1kA003489;
          Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com
Message-Id: <12345.abc@example.com>
Subject: here's a sample

Léelo desde abajo.

Orden	Línea	Qué te dice
1	From, Date, Subject, Message-Id	Los escribió el programa de correo del remitente. Todos son afirmaciones, no hechos.
2	Received de abajo	mail-router.example.com aceptó el mensaje de un equipo de acceso telefónico en 192.0.2.200. ESMTPA significa que el remitente inició sesión con SMTP AUTH.
3	Authentication-Results de abajo	El router registró que SMTP AUTH pasó y que SPF falló: la red de acceso telefónico no estaba incluida en el SPF de example.com.
4	DKIM-Signature	El router firmó el mensaje como d=example.com, selector gatsby, e incluyó el Authentication-Results de abajo entre los encabezados firmados (h=).
5	Received de arriba	auth-checker.example.com lo recibió del router en 192.0.2.1.
6	Authentication-Results de arriba	El verificador comprobó la firma DKIM: pass.

La explicación del propio RFC coincide: el usuario era legítimo (se autenticó con contraseña), SPF falló porque la red de acceso telefónico no estaba autorizada, y DKIM pasó porque el router firmó con una clave que publica example.com.

Esa es la lección principal del ejemplo, y se aplica directamente a la entregabilidad actual: un fallo de SPF por sí solo no significa que el correo sea ilegítimo, y DKIM es lo que sobrevive al trayecto.

Medir retrasos con la cadena Received

Cada línea Received termina con una marca de tiempo, así que la diferencia entre líneas consecutivas es lo que tardó cada salto.

El RFC 5321 pide a los servidores usar desfases explícitos como -0800, que es lo que permite comparar entre husos horarios. Escribimos un script corto para hacerlo y lo ejecutamos sobre el ejemplo del RFC de arriba. El script completo está abajo.

import sys, re
from email import message_from_string
from email.utils import parsedate_to_datetime
msg = message_from_string(open(sys.argv[1]).read())
hops = msg.get_all("Received") or []
prev = None
for i, h in enumerate(reversed(hops), 1):
    h = " ".join(h.split())
    stamp = h.rsplit(";", 1)[-1].strip()
    try:
        when = parsedate_to_datetime(stamp)
    except Exception:
        when = None
    m = re.search(r"from (\S+).*?by (\S+)", h)
    gap = f"+{(when - prev).total_seconds():.0f}s" if when and prev else "-"
    print(f"hop {i}: {m.group(1) if m else '?'} -> {m.group(2) if m else '?'}  {stamp}  {gap}")
    prev = when or prev

Resultado, ejecutado el 1 de octubre de 2026 (python3 hops.py header.txt):

hop 1: dialup-1-2-3-4.example.net -> mail-router.example.com  Fri, Feb 15 2002 17:19:07 -0800  -
hop 2: mail-router.example.com -> auth-checker.example.com  Fri, Feb 15 2002 17:19:22 -0800  +15s

El salto entre los dos servidores tardó 15 segundos. La brecha más grande está entre el encabezado Date, 16:54:30, y la primera línea Received, 17:19:07: unos 25 minutos antes de que cualquier servidor viera el mensaje. Date lo fija el software del remitente, así que una brecha ahí apunta al lado del remitente (una bandeja de salida en cola, un envío programado o un reloj mal configurado), no a ningún relay.

Si prefieres no ejecutar código, la herramienta Messageheader de Google hace la misma cuenta: pegas un encabezado y te señala los retrasos de entrega y el origen aproximado.

Cómo leer bien Authentication-Results

Authentication-Results registra cada verificación como método=resultado, seguido de la identidad que se revisó. Es la línea más útil del encabezado y la que más se malinterpreta.

El formato, según el RFC 8601, es:

Authentication-Results: <authserv-id>; <method>=<result> [reason] <ptype>.<property>=<value>

• authserv-id es quién hizo la verificación, por ejemplo mx.google.com.
• method=result es la verificación y su resultado: spf=pass, dkim=fail, dmarc=pass.
• ptype.property indica qué identidad se revisó: smtp.mailfrom (el remitente del sobre), header.d o header.i (el dominio que firma con DKIM), header.from (el dominio visible en From).
• Todo lo que va entre paréntesis es un comentario de texto libre, y cada receptor lo redacta distinto.

Los resultados posibles que define el RFC para SPF son none, pass, fail, softfail, neutral, temperror, permerror y policy; DKIM usa none, pass, fail, policy, neutral, temperror y permerror.

Confía solo en el que escribió tu proveedor

El RFC 8601 deja claro que este encabezado solo debe creerse cuando viene de un servidor dentro de tu propio límite administrativo, y que un servidor conforme debe borrar las copias que dicen venir de él pero llegan desde fuera. En la práctica: usa el Authentication-Results más alto cuyo authserv-id sea tu propio proveedor. Cualquier copia más abajo la escribió otro, posiblemente el remitente.

Un ejemplo real de Gmail, contrastado con el DNS

Valimail publicó este encabezado de un mensaje recibido en Gmail (fuente):

Authentication-Results: mx.google.com;
       dkim=pass header.i=@valimail.com header.s=google2048 header.b=Z8L6tjHb;
       spf=pass (google.com: domain of [redacted]@valimail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=[redacted]@valimail.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=valimail.com

Cada afirmación que contiene se puede comprobar desde tu propia terminal. Lo hicimos el 1 de octubre de 2026:

El encabezado dice	Comando	Lo que devolvió el DNS
Selector DKIM google2048 en valimail.com	dig +short TXT google2048._domainkey.valimail.com	Un registro de clave que empieza por "v=DKIM1; k=rsa; p=MIIBIjAN..."
Política DMARC p=REJECT	dig +short TXT _dmarc.valimail.com	"v=DMARC1; p=reject; rua=..."
Enviado desde 209.85.220.41	dig +short -x 209.85.220.41	mail-sor-f41.google.com.

Así que el selector indicado en s= existe, la política que informó Gmail coincide con el registro publicado, y la IP de envío es infraestructura de salida de Google. Vale la pena crear el hábito de este contraste: el encabezado te dice qué concluyó el receptor, y el DNS te dice si esa conclusión sigue siendo válida hoy. Nuestro verificador de DKIM y nuestro verificador de DMARC hacen las mismas consultas sin terminal.

Alineación: la verificación que haces a ojo

DMARC compara el dominio de header.from con los dominios que pasaron SPF y DKIM. Al menos uno debe coincidir con la organización del dominio de From.

En el ejemplo de Gmail los tres son valimail.com, así que DMARC pasa con cualquiera de las dos verificaciones. El fallo habitual, en cambio, se ve así:

Identidad	Dominio	Resultado
smtp.mailfrom (Return-Path)	bounces.sendingplatform.example	spf=pass
header.d (DKIM)	sendingplatform.example	dkim=pass
header.from	yourcompany.example	dmarc=fail

Dos pass y un fail, porque nada de lo que pasó pertenece al dominio de From. La especificación actual de DMARC (RFC 9989, mayo de 2026, que reemplaza al RFC 7489) solo necesita un pass alineado, y la solución habitual es activar DKIM personalizado para tu propio dominio en la plataforma de envío.

Return-Path: adónde van los rebotes

Return-Path es el remitente del sobre, se agrega en la entrega final y es la dirección a la que se envían los rebotes. También es la identidad que revisa SPF.

El RFC 5321 dice que el servidor que entrega el mensaje lo inserta en la entrega final, conservando la dirección del comando MAIL FROM, y que su propósito principal es indicar adónde van los avisos de no entrega. Suele ser distinto de From, sobre todo con una plataforma de envío que gestiona tus rebotes. Es normal. Pero si apunta a un lugar que no controlas, los rebotes que necesitas ver están yendo a otra parte, y eso importa para mantener limpia una lista.

Lo que los encabezados no pueden decirte

Los encabezados muestran la autenticación y la ruta, no por qué un filtro eligió Spam. Gmail no escribe su puntuación de reputación en el encabezado.

Si todo en el encabezado pasa y el mensaje igual cae en Spam, la respuesta está en los datos de reputación, no en el encabezado. En Gmail eso significa Postmaster Tools. Para el orden en que conviene revisar esas causas, consulta el diagnóstico de Gmail.

Una lista de revisión para cualquier encabezado

1. Copia el encabezado de la copia del destinatario, nunca de Enviados.
2. Busca el Authentication-Results más alto escrito por tu proveedor. Ignora los demás.
3. Revisa los resultados de spf, dkim y dmarc. Anota el dominio junto a cada uno.
4. Compara esos dominios con header.from. Al menos un pass debe estar alineado.
5. Busca en el DNS el selector DKIM (s=) y el registro DMARC para confirmar que siguen existiendo.
6. Lee las líneas Received de abajo hacia arriba. Anota la primera IP que registró tu proveedor y cualquier salto con una brecha larga.
7. Compara Date con la hora del primer Received para separar el retraso del lado del remitente del retraso en los relays.

Para hacer en un solo paso la parte de DNS de esta lista con tu propio dominio, usa la auditoría de entregabilidad gratuita.