Inicio / Guías / Analizar cabeceras de email: Received, Authentication-Results y forensics

#headers#received#authentication-results#diagnostico#forensics#transactional#spf#dkim#dmarc#arc

Análisis de cabeceras de email: Received, Authentication-Results y diagnóstico forense

4,5 · 66 valoraciones
· Actualizado el 3 de junio de 2025

Cómo leer las cabeceras de un email para diagnosticar problemas de entrega, autenticación, ruta SMTP, IPs y filtros aplicados por el receptor.

Analizar cabeceras de email: Received, Authentication-Results y forensics
Forma parte de SPF DKIM DMARC Deliverability

Cuando algo va mal con un email (no llega, llega a spam, autenticación falla, llega tarde) la respuesta casi siempre está en las cabeceras. Las cabeceras cuentan la ruta SMTP completa, qué servidores tocaron el mensaje, qué autenticación se evaluó y qué decisiones se tomaron en cada salto. Saber leerlas es la habilidad de diagnóstico más rentable en deliverability.

Cómo obtener las cabeceras crudas

Cada cliente tiene su atajo:

  • Gmail: abre mensaje, menú ”…” → “Show original”.
  • Outlook web: ”…” → “View → View message source”.
  • Apple Mail: View → Message → All Headers (Cmd+Shift+H).
  • Thunderbird: View → Headers → All, o Ctrl+U para crudo.

Lo que verás es texto plano: cabeceras seguidas de cuerpo. Solo nos interesan las cabeceras (todo hasta la primera línea en blanco).

Estructura básica

Un mensaje real puede tener 30-80 cabeceras. Las relevantes para diagnóstico:

  • Received: (varias). Ruta SMTP, en orden inverso (la última recibida está arriba).
  • Authentication-Results: (una o varias). Resultado de SPF, DKIM, DMARC.
  • DKIM-Signature: (una o varias). Firmas DKIM aplicadas.
  • Return-Path:. Dirección de bounce.
  • From:. Dirección visible.
  • Message-ID:. Identificador único.
  • ARC-* (opcional). Cadena ARC si pasó por intermediarios.

Leer la cadena Received

Cada salto SMTP añade una Received: arriba. Para reconstruir la ruta, la lees de abajo a arriba.

Ejemplo:

Received: from mx.gmail.com ([74.125.24.27])
    by mailbox.user.com with ESMTPS id abc123
    for <[email protected]>;
    Wed, 10 May 2026 12:34:56 +0000

Received: from mail.example.com (mail.example.com [203.0.113.45])
    by mx.gmail.com with ESMTPS id def456
    for <[email protected]>;
    Wed, 10 May 2026 12:34:54 +0000

Received: from sender.local ([10.0.0.5])
    by mail.example.com with SMTP id ghi789
    for <[email protected]>;
    Wed, 10 May 2026 12:34:50 +0000

Lectura (de abajo arriba):

  1. sender.local (10.0.0.5, IP interna) entregó a mail.example.com.
  2. mail.example.com (203.0.113.45) entregó a mx.gmail.com.
  3. mx.gmail.com entregó al buzón final.

Información útil:

  • IPs: si la primera IP pública es de un proveedor sospechoso, puede ser señal de mensaje fraudulento.
  • Tiempos: latencia entre saltos; si un salto tarda 15 minutos, hubo cola o greylisting.
  • Hostnames: si mail.example.com pretende ser tu MX pero la IP no es la tuya, suplantación.
  • with ESMTPS: indica TLS. with ESMTP o with SMTP significan sin cifrar.

Authentication-Results

Es la cabecera donde el receptor declara qué autenticación pasó:

Authentication-Results: mx.gmail.com;
    spf=pass (google.com: domain of [email protected] designates 203.0.113.45 as permitted sender) [email protected];
    dkim=pass [email protected] header.s=mail202605 header.b=AbCd1234;
    dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Lo importante:

  • spf=pass/fail/softfail/neutral/none: resultado SPF y por qué.
  • dkim=pass/fail/none: con detalle de selector (s=) y dominio (d=).
  • dmarc=pass/fail: alineación de From con SPF o DKIM, política aplicada.
  • arc=pass/fail (opcional): si vino vía intermediario que firmó ARC.

Si DMARC falla pero SPF y DKIM pasan, el problema es alineación: el dominio de From: no coincide con el dominio de SPF (smtp.mailfrom) ni con el d= de DKIM. Causa típica: enviar desde subdominios distintos sin alinear.

DKIM-Signature

Cada DKIM-Signature es una firma. Estructura:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=mail202605;
    h=from:to:subject:date:message-id:mime-version;
    bh=8aBxK+RvNqZ...;
    b=AbCdEfGh1234...

Campos clave:

  • d=: dominio que firma.
  • s=: selector. Combinado con d=, se busca la clave pública en s._domainkey.d en DNS.
  • h=: cabeceras firmadas. Si falta subject, el asunto puede modificarse sin invalidar la firma.
  • bh=: hash del cuerpo.
  • b=: firma criptográfica.

Para verificar manualmente:

dig +short TXT mail202605._domainkey.example.com

Devuelve la clave pública. Si está, DKIM tiene base; si no resuelve, la firma falla.

Más detalles en la guía de DKIM.

Return-Path vs From

Return-Path: <[email protected]>
From: "Marketing" <[email protected]>

Importante:

  • Return-Path: es la dirección donde van los bounces (MAIL FROM en SMTP). SPF se valida contra el dominio de Return-Path.
  • From: es lo que ve el usuario. DMARC alinea contra el dominio de From.

Si los dominios son distintos sin alineación relajada, DMARC falla por falta de alineación SPF, aunque SPF en sí pase.

Headers menos conocidas pero útiles

Message-ID

Message-ID: <[email protected]>

Identificador único. Si lo guardas en logs, puedes correlacionar entre tus envíos y reportes que lleguen después.

X-Originating-IP

Algunos proveedores añaden la IP del cliente que envió el mensaje (cliente de correo, no servidor). Útil para detectar abusos: si tu cuenta envía desde IPs raras, hay compromiso.

List-Unsubscribe y List-Unsubscribe-Post

List-Unsubscribe: <https://example.com/unsub?id=abc>, <mailto:[email protected]>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Indica al receptor que se puede dar de baja con un POST sin más confirmación. Necesario para Gmail/Yahoo en listas masivas (ver list-unsubscribe).

Feedback-ID

Feedback-ID: campaign-2026-05-10:newsletter:cliente:userid

Gmail respeta este header para agrupar señales por campaña en Postmaster Tools. Si envías masivo y no lo populas, agrupas todo bajo un solo nombre y pierdes granularidad.

X-Spam-Status / X-Spam-Score

Algunos receptores añaden el resultado de su filtro:

X-Spam-Status: No, score=0.5 required=5.0
X-Spam-Score: 0.5

Útil para diagnóstico: si tu mensaje arriba a inbox con score 4.8, está al límite y un cambio menor puede tirarlo a spam.

Casos prácticos

Caso 1: DMARC falla por alineación

Cabeceras:

From: [email protected]
Return-Path: [email protected]
Authentication-Results: spf=pass [email protected];
    dkim=pass header.d=mailservice.com;
    dmarc=fail header.from=marketing.example.com

From es marketing.example.com. Ni SPF ni DKIM están alineados con ese dominio. DMARC falla.

Solución: configurar el ESP para que firme con DKIM d=marketing.example.com (vía CNAME delegado) y/o usar Return-Path bajo marketing.example.com. Más en subdominios y aislamiento.

Caso 2: mensaje viajando 30 minutos

Cabeceras Received muestran:

  • Salto 1 → 2: 5 segundos.
  • Salto 2 → 3: 28 minutos.
  • Salto 3 → 4: 5 segundos.

El cuello de botella está entre el salto 2 y 3. Probablemente greylisting (ver guía) o cola en el receptor. Si afecta a muchos destinatarios, problema sistémico de ese receptor o de tu MTA.

Caso 3: DKIM falla solo desde un subdominio

DKIM-Signature aparece, pero dkim=fail. Razones típicas:

  • Selector no resuelve (clave pública no publicada). Verifica con dig.
  • Cuerpo modificado tras firmar (footer añadido por gateway intermedio). Solo recuperable con ARC.
  • Reloj fuera (firmas con fecha futura). Sincroniza NTP.

Herramientas para análisis

Pegar en analizadores online

Hay parsers que toman las cabeceras y las muestran ordenadas: ruta, autenticación, tiempos. Útil para casos puntuales.

Scripts propios

Para volumen, un parser sencillo en Python con email.message_from_string extrae cualquier campo. Ejemplo:

import email
msg = email.message_from_file(open("mensaje.eml"))
print("From:", msg["From"])
print("Auth:", msg["Authentication-Results"])
for r in msg.get_all("Received", []):
    print("---", r[:80])

Logs MTA correlacionados

Si gestionas tu MTA, los logs registran cada conexión saliente con Message-ID. Cruzar Message-ID de cabeceras con logs te da la otra mitad de la historia: lo que tu MTA hizo, no solo lo que el receptor declara haber visto.

Errores frecuentes

Confiar en una sola cabecera

Authentication-Results solo dice qué autenticación pasó. No dice qué reputación aplicó el receptor. Hay que leer también Received, X-Spam-* y combinar.

Asumir que la cabecera de origen es real

Cabeceras Received se pueden forjar antes de llegar a un MTA confiable. Solo confías en las que añaden servidores que conoces (los más cercanos al receptor final, los de “arriba”). Las de abajo pueden ser inventadas.

Ignorar zonas horarias

Tiempos en Received vienen con offset (+0000, +0200). Compararlos sin normalizar lleva a conclusiones erróneas sobre latencia.

No guardar EML para análisis posterior

Cuando reportas un problema a tu ESP o a soporte de un receptor, te van a pedir el .eml completo. Sin él, el análisis es imposible.

Confundir cabeceras añadidas por receptor con cabeceras del remitente

Cabeceras X-Spam-*, X-Originating-IP (a veces), Authentication-Results las añade el receptor (o intermediarios). No vienen del remitente. Distinguirlo es básico: si ves un X-Spam-Score: 8.0, ese score lo calculó el receptor, no el remitente.

Recursos relacionados

Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.

¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de retención y email marketing de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.

Preguntas frecuentes

¿Las cabeceras de un email se pueden falsificar?
Las cabeceras añadidas antes de llegar al MTA receptor sí pueden ser forjadas. Las que añaden servidores confiables (Gmail, Microsoft, tu MX) se pueden tratar como fiables porque firman cada salto.
¿Cómo veo las cabeceras crudas en Gmail?
Abre el mensaje, pulsa el menú de tres puntos y elige 'Mostrar original' o 'Show original'. Verás el sobre completo con Received, Authentication-Results y DKIM-Signature.
¿Qué cabeceras debo guardar en logs para diagnóstico futuro?
Como mínimo: Message-ID, From, Date y Authentication-Results. Con eso puedes correlacionar bounces, FBL y reportes DMARC posteriores con el envío original.
¿Por qué DMARC falla si SPF y DKIM pasan?
Suele ser por falta de alineación: el dominio del From no coincide con el de smtp.mailfrom (SPF) ni con el d= de DKIM. La solución habitual es firmar DKIM con el dominio del From o usar un Return-Path bajo ese mismo dominio.
¿Cuál es la diferencia entre Return-Path y From?
Return-Path es la dirección donde van los bounces (MAIL FROM en SMTP) y se usa para validar SPF. From es lo que ve el usuario y es la base de la alineación DMARC.
¿Qué hacer si Authentication-Results falta?
Significa que el receptor no evaluó autenticación o no la añade a las cabeceras. Algunos receptores antiguos lo hacen así. Cruza con reportes DMARC para ver realmente qué pasó.
¿Las cabeceras revelan si fui bloqueado?
No directamente. Si fuiste bloqueado, no llegó mensaje (no hay cabeceras que mirar). El bloqueo se ve en logs de tu MTA con código SMTP `5xx` y mensaje del receptor.