Entender los encabezados de correo: la guía completa para leer y analizar cada campo

⚡TL;DR

• Los encabezados de correo son un registro de vuelo invisible que registra cada servidor atravesado, cada verificación de autenticación y cada decisión antispam
• Los encabezados Received se leen de abajo hacia arriba: el hop más antiguo está abajo, el más reciente arriba
• Authentication-Results resume los veredictos SPF, DKIM y DMARC en una sola línea; es el campo más importante para diagnosticar un problema
• Los campos From, Return-Path y Reply-To pueden apuntar a tres direcciones diferentes, señal potencial de spoofing
• Una herramienta de análisis automatizado convierte decenas de líneas técnicas en un diagnóstico legible en segundos

Recibes un correo sospechoso. El remitente muestra el nombre de tu banco, pero algo no cuadra. O bien tus propios correos llegan a spam en las bandejas de tus clientes y no entiendes por qué. En ambos casos, la respuesta está en el mismo sitio: los encabezados del correo. Cuando se sabe que el 60 % de las brechas confirmadas implican una acción humana (Verizon DBIR 2025) y que se tarda una media de 207 días en detectar un compromiso por phishing (IBM 2025), saber leer un encabezado ya no es un lujo técnico.

Cada correo transporta un bloque de metadatos invisibles. Ese bloque contiene el itinerario completo del mensaje (qué servidores ha atravesado, en qué orden), los resultados de las verificaciones de autenticación (SPF, DKIM, DMARC) e indicios de cómo los filtros antispam han tratado el mensaje. Es un registro de vuelo completo, pero hay que saber leerlo.

Esta guía te enseña a extraer esos encabezados, entender cada campo, interpretar la cadena de enrutamiento y diagnosticar los problemas más frecuentes. Tanto si eres administrador de sistemas, responsable de marketing o simplemente quieres saber si un correo es legítimo, no se requieren conocimientos previos: partimos de cero.

¿Qué es un encabezado de correo y por qué debería importarte?

La analogía del sobre postal

Cuando envías una carta, el sobre lleva la dirección del remitente, la del destinatario y los sellos de correos. El contenido de la carta está separado de esa información de enrutamiento.

Un correo electrónico funciona de la misma manera. El cuerpo del mensaje (el texto, las imágenes, los adjuntos) está separado de los encabezados que transportan los metadatos. La diferencia: los encabezados de un correo contienen mucha más información que un sobre postal. Cada servidor que lo procesa añade sus propias anotaciones, como un sello postal con fecha y hora.

Encabezados visibles vs encabezados técnicos

Tu cliente de correo muestra algunos encabezados de forma legible:

• De (From): la dirección del remitente
• Para (To): la dirección del destinatario
• Asunto (Subject): el asunto del mensaje
• Fecha (Date): la marca de tiempo de envío

Pero bajo esa superficie, decenas de encabezados técnicos permanecen ocultos. Los más importantes:

Encabezado	Función
Received	Traza el camino del mensaje de servidor en servidor
Return-Path	Dirección de rebote (sobre SMTP)
Authentication-Results	Veredictos SPF, DKIM y DMARC
DKIM-Signature	Firma criptográfica del mensaje
Message-ID	Identificador único del mensaje
X-Spam-Score	Puntuación asignada por el filtro antispam

Cuatro razones para leer los encabezados

1. Diagnosticar un problema de entregabilidad. ¿Tus correos llegan a spam? Los encabezados del mensaje recibido te dicen exactamente por qué: fallo SPF, firma DKIM inválida, política DMARC no respetada o puntuación antispam demasiado alta.

2. Verificar la identidad de un remitente. ¿Un correo dice venir de tu director financiero? Compara el campo From con el Return-Path y comprueba que DKIM esté firmado por el dominio correcto. Una discrepancia entre estos campos es una señal de alerta fuerte.

3. Detectar spoofing y phishing. Los atacantes falsifican el campo From para suplantar la identidad de un dominio legítimo. Los encabezados de autenticación revelan si el mensaje fue realmente emitido por el servidor autorizado. Un dmarc=fail combinado con un spf=fail en un correo que dice venir de tu banco es un indicador fiable de fraude. Y el problema es masivo: el 84,2 % de los ataques de phishing superan los controles DMARC (Egress 2024), ya sea porque el dominio no tiene política DMARC o porque la política es demasiado permisiva (p=none).

4. Rastrear un problema de latencia. Cada encabezado Received contiene una marca de tiempo. Comparando los timestamps de cada hop, identificas el servidor que introduce un retraso anormal en la cadena de enrutamiento.

Cómo extraer los encabezados

Cada cliente de correo oculta los encabezados técnicos por defecto. Aquí tienes cómo mostrarlos.

Gmail (web)

1. Abre el correo en cuestión
2. Haz clic en el menú de tres puntos verticales (⋮) en la esquina superior derecha del mensaje
3. Selecciona "Mostrar original"
4. Se abre una nueva ventana con los encabezados completos y un resumen SPF/DKIM/DMARC en la parte superior

Gmail ofrece un botón "Copiar al portapapeles" para recuperar la totalidad de los encabezados. Es el método más rápido para pegarlos en una herramienta de análisis.

Outlook escritorio (Windows/Mac)

1. Abre el correo en una ventana separada (doble clic)
2. Ve a Archivo > Propiedades
3. Los encabezados aparecen en el campo "Encabezados de Internet" en la parte inferior de la ventana

El campo es pequeño: selecciona todo (Ctrl+A) y luego copia (Ctrl+C) para trabajar más cómodamente en un editor de texto.

Outlook web (OWA)

1. Abre el correo en cuestión
2. Haz clic en el menú de tres puntos (⋮) en la esquina superior derecha
3. Selecciona "Ver" y luego "Ver origen del mensaje"
4. Los encabezados se muestran en una nueva ventana

Apple Mail (macOS)

1. Selecciona el correo en la lista
2. En la barra de menú, ve a Visualización > Mensaje > Todas las cabeceras
3. Los encabezados técnicos aparecen encima del cuerpo del mensaje

Para volver a la vista normal: Visualización > Mensaje > Cabeceras por defecto.

Thunderbird

1. Selecciona el correo
2. Menú Ver > Código fuente del mensaje (o atajo Ctrl+U, Cmd+U en Mac)
3. El código fuente completo se abre en una nueva ventana, encabezados incluidos

Thunderbird también muestra un resumen de los encabezados directamente en el panel de lectura si activas Ver > Cabeceras > Todas.

Yahoo Mail

1. Abre el correo en cuestión
2. Haz clic en el menú de tres puntos (⋮) junto al botón Responder
3. Selecciona "Ver mensaje sin formato"
4. Los encabezados completos y el cuerpo del mensaje se muestran en una nueva pestaña

ProtonMail

1. Abre el correo en cuestión
2. Haz clic en el menú de tres puntos (⋮) en la esquina superior derecha del mensaje
3. Selecciona "Ver encabezados"
4. ProtonMail muestra los encabezados en una ventana modal. Usa el botón copiar para recuperar la totalidad

Nota: como ProtonMail es un servicio cifrado del lado del cliente, los encabezados visibles son los añadidos durante el tránsito SMTP. Los encabezados internos de la infraestructura de ProtonMail permanecen limitados.

Consejo práctico

Sea cual sea el método, copia la totalidad de los encabezados y pégalos en una herramienta de análisis de encabezados. La herramienta descompone automáticamente cada campo, calcula los retrasos entre hops y resalta los problemas de autenticación.

Copia TODO el contenido. Los encabezados de un correo profesional suelen tener entre 50 y 200 líneas. Si solo copias las primeras líneas, pierdes los hops Received más antiguos (que están abajo) y a menudo la información más reveladora.

Error frecuente: no confundas "Ver código fuente" (que muestra el mensaje completo, encabezados + cuerpo codificado) con "Ver encabezados" (solo los metadatos). Para un diagnóstico completo, la fuente entera es preferible: contiene las firmas DKIM verificables.

Formato y estructura de los encabezados (RFC 5322)

El formato clave: valor

Cada encabezado sigue un formato simple definido por la RFC 5322:

Nombre-Del-Campo: valor del campo

El nombre del campo no distingue mayúsculas de minúsculas (From y from son idénticos), seguido de dos puntos y luego el valor. Ejemplos:

From: contact@captaindns.com
To: support@captaindns.com
Subject: Informe de monitoring DNS - Marzo 2026
Date: Sat, 29 Mar 2026 10:15:00 +0100
Message-ID: <20260329101500.abc123@mail.captaindns.com>

El folding (continuación en varias líneas)

Cuando un valor es demasiado largo para caber en una sola línea, se continúa en la siguiente con una indentación (espacio o tabulación). Es lo que se llama folding. Ejemplo con un encabezado Received:

Received: from mx-out.captaindns.com (mx-out.captaindns.com [203.0.113.10])
    by mx-in.captaindns.com (Postfix) with ESMTPS id ABC123DEF
    for <support@captaindns.com>; Sat, 29 Mar 2026 10:15:02 +0100

Estas tres líneas forman un solo encabezado Received. La regla: toda línea que empieza con un espacio en blanco es la continuación del encabezado anterior.

El orden de lectura: de abajo hacia arriba para los Received

Esta es la particularidad más importante de los encabezados de correo: los encabezados Received se leen de abajo hacia arriba.

Cada servidor SMTP que procesa el mensaje añade su encabezado Received encima de los encabezados existentes. El resultado: el primer hop (el servidor de origen) está abajo, el último hop (el servidor de recepción) está arriba.

Los demás encabezados (From, To, Subject, Date, Message-ID) se añaden una sola vez por el servidor de origen. Su posición en el bloque es fija.

Los campos clave explicados uno por uno

From

From: Marie Dupont <contact@captaindns.com>

Descripción: identifica al remitente mostrado en el cliente de correo. Es el campo que ve el destinatario.

Lo que revela: el From es el encabezado más visible, pero también el más fácil de falsificar. Cualquier servidor SMTP puede enviar un correo con un From arbitrario. Es precisamente por eso que existen SPF, DKIM y DMARC: verificar que el From corresponde realmente al servidor que envió el mensaje.

Cuidado con el display name. El campo From contiene dos elementos distintos: el nombre mostrado (display name) y la dirección real entre ángulos. En From: Marie Dupont <contact@captaindns.com>, tu cliente de correo muestra "Marie Dupont" en negrita y la dirección contact@captaindns.com en tamaño más pequeño. El problema: el display name es un texto libre, sin ninguna verificación. Un atacante puede escribir From: Director Financiero <atacante@dominio-malicioso.com> y muchos clientes móviles solo muestran el nombre, no la dirección. Verifica siempre la dirección entre ángulos, no el nombre mostrado.

To y Cc

To: support@captaindns.com
Cc: tech@captaindns.com

Descripción: To lista los destinatarios principales. Cc (copia de carbón) lista los destinatarios en copia visible.

Lo que revela: si tu dirección no aparece ni en To ni en Cc, el mensaje te fue enviado en copia oculta (Bcc) o mediante una lista de distribución. Las campañas de phishing masivas suelen usar un To genérico o vacío.

Subject

Subject: =?utf-8?B?UmFwcG9ydCBkZSBtb25pdG9yaW5n?=

Descripción: el asunto del mensaje. Puede estar codificado en Base64 o Quoted-Printable cuando contiene caracteres no ASCII (acentos, caracteres especiales).

Lo que revela: en su forma decodificada, es el texto que ves en tu bandeja de entrada. La codificación en bruto en los encabezados es normal y no indica ningún problema.

Date

Date: Sat, 29 Mar 2026 10:15:00 +0100

Descripción: marca de tiempo definida por el cliente del remitente en el momento del envío. El formato sigue la RFC 5322: día, fecha, hora y desplazamiento UTC.

Lo que revela: compara esta fecha con los timestamps de los encabezados Received. Una diferencia de varias horas entre el Date y el primer Received puede indicar un correo enviado por un script mal configurado o un intento de manipulación temporal.

Return-Path

Return-Path: <bounces@mail.captaindns.com>

Descripción: la dirección a la que se envían los mensajes de rebote (bounces). Es la dirección del sobre SMTP (MAIL FROM), añadida por el servidor de recepción final.

Lo que revela: el Return-Path puede diferir del From. Es normal cuando un servicio de terceros envía correos en tu nombre. Por ejemplo, un correo enviado a través de SendGrid mostrará Return-Path: <bounces+12345@em.sendgrid.net> aunque el From sea contact@captaindns.com. Lo mismo ocurre con Mailgun (bounces@mailgun.org) o Amazon SES (0123abcd@amazonses.com). Estos servicios gestionan los rebotes a través de su propia infraestructura.

Es anormal cuando un correo dice venir de contact@captaindns.com pero tiene un Return-Path hacia un dominio desconocido que no tiene ninguna relación con un proveedor de envío legítimo. DMARC verifica la alineación entre el dominio del From y el dominio del Return-Path (o del DKIM). Un desalineamiento sin DKIM válido provoca un fallo DMARC.

Reply-To

Reply-To: respuestas@captaindns.com

Descripción: la dirección a la que el cliente de correo enviará la respuesta cuando el destinatario haga clic en "Responder". Opcional.

Lo que revela: un Reply-To diferente del From es habitual en newsletters (envío desde un servicio de marketing, respuesta al soporte). Es sospechoso cuando el Reply-To apunta a un dominio completamente diferente del From, típico de los fraudes al CEO (Business Email Compromise).

Message-ID

Message-ID: <20260329101500.abc123@mail.captaindns.com>

Descripción: identificador único del mensaje, generado por el servidor de envío. El formato habitual es una marca de tiempo o un identificador aleatorio seguido del nombre de host del servidor, todo entre ángulos.

Lo que revela: el dominio en el Message-ID indica qué servidor realmente creó el mensaje. Si un correo dice venir de captaindns.com pero tiene un Message-ID que contiene un dominio diferente, es un indicio de suplantación. También es un indicador valioso del servicio de envío real: un Message-ID en @amazonses.com delata un envío a través de Amazon SES, @smtpservice.net indica SendGrid, @mail.gmail.com indica Google Workspace. El Message-ID es uno de los encabezados más difíciles de falsificar de forma convincente, ya que lo genera automáticamente el servidor SMTP.

MIME-Version y Content-Type

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="boundary123abc"

Descripción: MIME-Version indica que el mensaje usa el formato MIME (casi siempre 1.0). Content-Type describe el formato del cuerpo: text/plain (texto plano), text/html (HTML), multipart/alternative (ambas versiones), multipart/mixed (con adjuntos).

Lo que revela: un correo que dice ser texto plano pero contiene un Content-Type: multipart/mixed con un adjunto ejecutable es sospechoso. El Content-Type ayuda a entender la estructura real del mensaje.

Received

Received: from mx-out.captaindns.com (mx-out.captaindns.com [203.0.113.10])
    by mx-in.captaindns.com (Postfix) with ESMTPS id ABC123DEF
    for <support@captaindns.com>; Sat, 29 Mar 2026 10:15:02 +0100

Descripción: cada servidor SMTP que procesa el mensaje añade un encabezado Received. Es la traza de enrutamiento del mensaje.

Lo que revela: el itinerario completo del mensaje, servidor por servidor. Los detalles de cada hop (identidad del servidor, protocolo utilizado, marca de tiempo) permiten verificar la legitimidad del enrutamiento. Sección dedicada más abajo.

El protocolo indicado tras with es una señal de seguridad importante. with ESMTPS significa que la conexión entre los dos servidores estaba cifrada con TLS: es el estándar esperado en 2026. with ESMTP (sin la S) significa que el mensaje transitó en texto claro, sin cifrado. Si ves with ESMTP en un hop externo (entre dos organizaciones diferentes), es un problema: el contenido del mensaje, adjuntos incluidos, circuló legible por cualquiera que intercepte el tráfico de red. with ESMTPSA indica una conexión autenticada y cifrada (típicamente un cliente de correo que se conecta al servidor SMTP con usuario/contraseña + TLS).

DKIM-Signature

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=captaindns.com; s=s202603; t=1743238500;
    h=from:to:subject:date:message-id;
    bh=LjIq2t4u3qH0OwZ1E4fDn5t3nVz2Ay+KqR0kbD1XXXA=;
    b=dGVzdCBzaWduYXR1cmUgZXhhbXBsZQ==...

Descripción: firma criptográfica añadida por el servidor de envío. El servidor de recepción verifica esta firma a través de la clave pública publicada en el DNS.

Lo que revela: las etiquetas clave son d= (dominio firmante), s= (selector de la clave), a= (algoritmo, rsa-sha256 es el estándar), h= (encabezados cubiertos por la firma), bh= (hash del cuerpo del mensaje) y b= (la firma en sí). Si d=captaindns.com y Authentication-Results muestra dkim=pass, el mensaje está autenticado por el dominio.

La etiqueta bh= (body hash) es un resumen criptográfico del cuerpo del mensaje. El servidor de recepción recalcula este hash y lo compara con el valor del encabezado. Si el cuerpo fue modificado en tránsito (por una lista de correo que añade un pie de página, por ejemplo), el hash ya no coincide y DKIM falla. La etiqueta c= (canonicalization) define la tolerancia a modificaciones menores: relaxed/relaxed es la más permisiva (ignora espacios sobrantes), simple/simple es estricta.

Authentication-Results

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=mail.captaindns.com;
    dkim=pass header.d=captaindns.com header.s=s202603;
    dmarc=pass (p=reject) header.from=captaindns.com

Descripción: resumen de las verificaciones de autenticación realizadas por el servidor de recepción. Un solo encabezado que agrupa los veredictos SPF, DKIM y DMARC.

Lo que revela: es el campo más importante para diagnosticar un problema de autenticación de correo. Sección dedicada más abajo.

X-Mailer y User-Agent

X-Mailer: CaptainDNS Mailer 2.1

Descripción: identifica el software cliente utilizado para enviar el mensaje. Campo opcional y no estandarizado.

Lo que revela: un correo profesional enviado por un X-Mailer inusual (un script Python básico, una herramienta de envío masivo) puede ser sospechoso. Es un indicio complementario, nunca un criterio decisivo.

X-MS-Exchange-Organization-SCL

X-MS-Exchange-Organization-SCL: 1

Descripción: Spam Confidence Level asignado por Microsoft Exchange. Escala de -1 (mensaje de confianza) a 9 (spam seguro). El umbral predeterminado de cuarentena es 5.

Lo que revela: si usas Exchange o Microsoft 365, esta puntuación te dice directamente cómo el filtro antispam de Microsoft ha evaluado el mensaje. Un SCL de 5 o más explica por qué un correo fue clasificado como correo no deseado.

Los encabezados ARC

ARC-Seal: i=1; a=rsa-sha256; d=captaindns.com; s=arc202603; cv=none; ...
ARC-Message-Signature: i=1; a=rsa-sha256; d=captaindns.com; ...
ARC-Authentication-Results: i=1; mx.captaindns.com;
    spf=pass; dkim=pass; dmarc=pass

Descripción: ARC (Authenticated Received Chain) preserva los resultados de autenticación cuando un mensaje atraviesa intermediarios (listas de correo, reenvíos automáticos). Tres encabezados trabajan juntos: ARC-Authentication-Results (resultados en el punto de paso), ARC-Message-Signature (firma del mensaje en ese punto) y ARC-Seal (sello de la cadena).

Lo que revela: cuando un correo se reenvía y SPF/DKIM fallan por la modificación en tránsito, ARC permite al servidor final verificar que la autenticación era válida en el origen. El campo cv= (chain validation) indica si la cadena está intacta: none (primer hop), pass (cadena válida) o fail (cadena rota). Para saber más sobre el funcionamiento de ARC, consulta nuestra guía sobre Authenticated Received Chain.

Los encabezados que delatan un servicio de terceros

Cuando una empresa envía un correo a través de un servicio de terceros (plataforma de marketing, CRM, herramienta transaccional), los encabezados conservan la huella de la infraestructura real de envío. Es una herramienta poderosa para identificar quién envía realmente un correo, aunque el From muestre un dominio corporativo.

Tabla de firmas por proveedor

Proveedor	Encabezados reveladores	Return-Path típico	Message-ID / DKIM
SendGrid	X-SG-EID, X-SG-ID	@sendgrid.net o @em.sendgrid.net	DKIM d=sendgrid.net (si no hay DKIM personalizado)
Amazon SES	X-SES-Outgoing	@amazonses.com	Message-ID: @amazonses.com, DKIM d=amazonses.com
Mailgun	X-Mailgun-Sid, X-Mailgun-Variables	@mailgun.org	DKIM d=mailgun.org
Google Workspace	Received: from mail-*.google.com	@*.google.com	Message-ID: @mail.gmail.com
Microsoft 365	X-MS-Exchange-Organization-*, X-MS-Has-Attach	@*.outlook.com	DKIM d=*.onmicrosoft.com
Brevo (ex-Sendinblue)	X-Mailin-EID, X-Mailin-*	@mail-sib.com	DKIM d=sendinblue.com o personalizado
Postmark	X-PM-Message-Id	@pm.mtasv.net	DKIM d=pm.mtasv.net
Mailchimp	X-MC-User, X-Mailer: MailChimp Mailer	@mcsv.net o @mail*.suw*.mcdlv.net	DKIM d=*.mcsv.net

Cómo usar esta tabla

Cuando analices un correo sospechoso, busca los encabezados X-* no estándar y el dominio del Return-Path. Si un correo dice venir de contact@captaindns.com y los encabezados contienen X-SG-EID con un Return-Path en @sendgrid.net, sabes que el correo pasó por SendGrid. No es necesariamente sospechoso: basta con verificar que captaindns.com usa efectivamente SendGrid como proveedor de envío.

En cambio, si un correo dice venir de tu banco pero los encabezados revelan un envío desde un pequeño proveedor SMTP desconocido, con un DKIM firmado por un dominio de terceros sin relación, es una señal de alerta.

Leer la cadena Received (de abajo hacia arriba)

La cadena de encabezados Received es la columna vertebral del enrutamiento de correo. Cada servidor que toca el mensaje deja su huella.

El principio: cada servidor añade arriba

Imagina una pila de sellos postales. La oficina de correos de origen estampa el primer sello. Cada oficina intermedia añade el suyo encima. La oficina de destino queda arriba de la pila.

Es exactamente lo que ocurre con los encabezados Received: el servidor de recepción final añade su encabezado en la parte superior. El servidor de origen está en la parte inferior. Para reconstruir el trayecto cronológico del mensaje, lee los encabezados Received de abajo hacia arriba.

Anatomía de un hop

Cada encabezado Received contiene cuatro informaciones clave:

Elemento	Significado	Ejemplo
from	Servidor que transmitió el mensaje	mx-out.captaindns.com
by	Servidor que recibió el mensaje	mx-in.captaindns.com
with	Protocolo utilizado	ESMTPS (SMTP cifrado TLS)
Timestamp	Fecha y hora de recepción	Sat, 29 Mar 2026 10:15:02 +0100

El protocolo with es revelador:

• ESMTPS: SMTP con TLS (cifrado, es el estándar esperado)
• ESMTP: SMTP sin TLS (sin cifrado, problema potencial)
• LMTP: protocolo de entrega local (último hop, normal)

Ejemplo concreto con 4 hops

Aquí tienes una cadena Received realista para un correo recibido por captaindns.com, enviado por un colaborador externo a través de Gmail y filtrado por Mimecast. Los encabezados se presentan en el orden en que aparecen en el mensaje en bruto (del más reciente al más antiguo):

(1) Received: from mx2.captaindns.com (10.0.0.5)
        by exchange.captaindns.com (10.0.0.10) with ESMTP;
        Fri, 29 Mar 2026 10:42:15 +0100

(2) Received: from gateway.mimecast.com (91.220.42.50)
        by mx2.captaindns.com with ESMTPS id A1B2C3D4;
        Fri, 29 Mar 2026 10:42:13 +0100

(3) Received: from mail-sor-f41.google.com (209.85.220.41)
        by gateway.mimecast.com with ESMTPS id E5F6G7H8;
        Fri, 29 Mar 2026 10:42:11 +0100

(4) Received: from [192.168.1.100] by smtp.gmail.com with ESMTPSA
        id I9J0K1L2; Fri, 29 Mar 2026 10:42:09 +0100

Lectura de abajo hacia arriba (orden cronológico):

1. Hop 4 (10:42:09, el más antiguo, abajo): el remitente envía desde su PC (IP privada 192.168.1.100) a través del servidor SMTP de Gmail. El protocolo ESMTPSA confirma una conexión autenticada y cifrada
2. Hop 3 (10:42:11): Gmail transmite el mensaje al gateway de Mimecast. ESMTPS indica una conexión TLS entre Google y Mimecast (filtro antispam/seguridad del destinatario)
3. Hop 2 (10:42:13): Mimecast, tras analizar el mensaje, lo transmite al servidor MX de captaindns.com. Conexión ESMTPS, cifrado mantenido
4. Hop 1 (10:42:15, el más reciente, arriba): el MX interno transmite al servidor Exchange final para entrega en el buzón del destinatario. ESMTP sin TLS entre servidores internos, aceptable en una red privada

Tiempo total de tránsito: 6 segundos. Es normal. Por encima de 30 segundos entre dos hops consecutivos, probablemente hay un problema de rendimiento en el servidor responsable del retraso.

Detectar anomalías en la cadena

Timestamps incoherentes. ¿Un hop 3 con fecha anterior al hop 2? Es un reloj desincronizado (frecuente en servidores mal configurados) o un encabezado Received inyectado manualmente por un atacante. Verifica si el servidor en cuestión es legítimo.

Hops faltantes. ¿El mensaje pasa de tu servidor directamente a un servidor desconocido, sin pasar por tu gateway? Un intermediario no autorizado pudo haber retransmitido el mensaje, o un servidor de la cadena no genera encabezados Received (raro pero posible).

Servidores desconocidos. ¿Un nombre de host o una IP que no reconoces en la cadena? Verifica el DNS inverso de la IP. Un servidor legítimo tiene un PTR coherente con su nombre de host. Un servidor comprometido o un relay abierto suele tener un PTR genérico o inexistente.

IPs privadas en medio de la cadena. Direcciones en 10.x.x.x o 192.168.x.x son normales en el primer hop (red interna del remitente). Son sospechosas si aparecen más adelante en la cadena, ya que sugieren un enrutamiento anormal.

Authentication-Results: SPF, DKIM, DMARC

El encabezado Authentication-Results es el panel de control de la seguridad del correo. Resume en una línea los resultados de los tres protocolos de autenticación. Es el primer encabezado que debes verificar cuando diagnosticas un problema.

Estructura del campo

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=mail.captaindns.com;
    dkim=pass (2048-bit key) header.d=captaindns.com header.s=s202603;
    dmarc=pass (p=reject dis=none) header.from=captaindns.com

El primer elemento (mx.captaindns.com) identifica el servidor que realizó las verificaciones. Cada veredicto está separado por un punto y coma.

Campo	Resultado	Significado
spf=pass	✓	El servidor remitente está autorizado por el registro SPF
dkim=pass	✓	La firma criptográfica es válida (selector: s202603)
dmarc=pass	✓	SPF y DKIM están alineados con el dominio From (política: reject)

SPF: ¿el servidor está autorizado?

SPF (Sender Policy Framework) verifica si la dirección IP del servidor de envío está autorizada por el registro DNS SPF del dominio.

Veredicto	Significado	Acción típica
pass	La IP está explícitamente autorizada	Aceptado
fail	La IP está explícitamente prohibida (-all)	Rechazado o spam
softfail	La IP no está autorizada pero no está explícitamente prohibida (~all)	Aceptado con desconfianza
neutral	El dominio no se pronuncia (?all)	Sin impacto
none	No hay registro SPF publicado	Ninguna verificación posible
temperror	Error DNS temporal	Reintento posterior
permerror	Error de sintaxis en el registro SPF	Varía según el servidor

El detalle entre paréntesis (sender IP is 203.0.113.10) te da la IP que fue verificada. El campo smtp.mailfrom indica el dominio del sobre SMTP.

DKIM: ¿el mensaje es íntegro?

DKIM verifica la firma criptográfica del mensaje. Si la firma es válida, el contenido no fue modificado en tránsito y el dominio firmante está autenticado.

Veredicto	Significado	Acción típica
pass	Firma válida	Autenticado
fail	Firma inválida (mensaje modificado o clave incorrecta)	Sospechoso
none	Ninguna firma DKIM presente	Ninguna verificación posible
neutral	Firma presente pero no verificable	Sin impacto
temperror	Error DNS temporal al recuperar la clave	Reintento
permerror	Error en el registro DKIM	Varía

Los detalles importantes: header.d= indica el dominio firmante, header.s= indica el selector utilizado. Esta información te permite verificar qué dominio realmente firmó el mensaje y con qué clave.

DMARC: ¿la alineación es correcta?

DMARC verifica que el dominio del From (visible para el destinatario) está alineado con los dominios autenticados por SPF y/o DKIM. Es la capa que impide el spoofing del campo From.

Veredicto	Significado	Acción típica
pass	Alineación SPF o DKIM verificada	Aceptado
fail	Ninguna alineación válida	Aplica la política p=
bestguesspass	No hay política DMARC publicada, pero el servidor estima que el mensaje es legítimo	Aceptado
none	No hay política DMARC publicada	Ninguna acción

Los detalles DMARC incluyen:

• p=: la política publicada por el dominio (none, quarantine, reject)
• dis=: la disposición realmente aplicada por el servidor
• header.from=: el dominio del From verificado

Ejemplo combinado: lectura completa

Aquí tienes un Authentication-Results problemático:

Authentication-Results: mx.captaindns.com;
    spf=softfail (sender IP is 198.51.100.42) smtp.mailfrom=notifications.captaindns.com;
    dkim=fail (signature verification failed) header.d=captaindns.com header.s=s202603;
    dmarc=fail (p=quarantine dis=quarantine) header.from=captaindns.com

Diagnóstico:

• SPF softfail: la IP 198.51.100.42 no está en el registro SPF de notifications.captaindns.com. Quizá un nuevo servidor de envío aún no declarado
• DKIM fail: la firma es inválida. Causas posibles: clave DNS obsoleta, mensaje modificado en tránsito o rotación de clave mal sincronizada
• DMARC fail: ni SPF ni DKIM pasan con alineación. La política quarantine se aplica: el mensaje se coloca en spam

Este tipo de resultado señala un problema de configuración del remitente, no un ataque. La corrección pasa por actualizar el registro SPF y verificar la clave DKIM.

Los encabezados antispam

Más allá de SPF/DKIM/DMARC, los filtros antispam añaden sus propios encabezados para justificar sus decisiones.

X-Spam-Score y X-Spam-Status

X-Spam-Status: No, score=-2.1 required=5.0
    tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_PASS
X-Spam-Score: -2.1

SpamAssassin utiliza un sistema de puntuación acumulativa. Cada test suma o resta puntos. Una puntuación por encima del umbral (generalmente 5.0) clasifica el mensaje como spam.

Los tests habituales:

Test	Puntuación típica	Significado
BAYES_00	-1.9	El contenido se parece a ham (no spam) según el filtro bayesiano
DKIM_VALID_AU	-0.1	DKIM válido y alineado con el dominio autor
SPF_PASS	-0.0	SPF superado
HTML_MESSAGE	+0.0	El mensaje contiene HTML (neutro)
URIBL_BLOCKED	+0.0	Las listas de URL no pudieron ser consultadas
BAYES_99	+3.5	El contenido se parece mucho a spam
MISSING_MID	+0.5	Sin Message-ID (sospechoso)

La puntuación SCL de Exchange

El encabezado X-MS-Exchange-Organization-SCL asigna una puntuación de 0 a 9:

SCL	Clasificación	Acción predeterminada
-1	Remitente de confianza (lista blanca)	Entrega directa
0-1	No spam	Bandeja de entrada
2-4	Probablemente no spam	Bandeja de entrada
5-6	Spam probable	Carpeta correo no deseado
7-9	Spam seguro	Rechazo o cuarentena

Los encabezados de Google

Gmail no expone una puntuación antispam en los encabezados en bruto. Sin embargo, encontrarás:

• X-Google-DKIM-Signature: firma DKIM añadida por Google además de la del remitente
• X-Gm-Message-State: estado interno del mensaje en la infraestructura de Google (codificado, no interpretable)
• X-Google-Smtp-Source: identificador del servidor de Google que procesó el mensaje

La vista "Mostrar original" de Gmail muestra un resumen SPF/DKIM/DMARC en la parte superior de la página, más legible que los encabezados en bruto.

Cómo interpretar los veredictos

Cuando un filtro antispam clasifica un mensaje como spam, busca primero el encabezado Authentication-Results. Si SPF, DKIM y DMARC están todos en pass, el problema probablemente viene del contenido (palabras clave sospechosas, relación texto/imagen, enlaces acortados). Si alguno de los tres falla, corrige primero la autenticación antes de tocar el contenido.

Para entender cómo los atacantes explotan las fallas en los encabezados para eludir los filtros, consulta nuestro artículo sobre las señales de alerta en los encabezados de correo.

6 escenarios prácticos de diagnóstico

Escenario 1: mi correo llega a spam

Encabezados a verificar: Authentication-Results, X-Spam-Score (o SCL)

Método:

1. Pide al destinatario que extraiga los encabezados del mensaje recibido en spam
2. Verifica Authentication-Results: si spf=fail o dkim=fail, es la causa probable
3. Si SPF/DKIM/DMARC están todos en pass, mira la puntuación antispam. Un X-Spam-Score superior a 5.0 o un SCL de 5+ indica un filtrado basado en el contenido
4. Verifica la reputación de tu IP de envío con una herramienta de verificación de listas negras

Ejemplo concreto: aquí tienes el encabezado que explica por qué un correo legítimo termina en spam.

Authentication-Results: mx.destinatario.com;
    spf=pass smtp.mailfrom=mail.captaindns.com;
    dkim=pass header.d=captaindns.com;
    dmarc=fail (p=quarantine dis=quarantine) header.from=captaindns.com

Aquí, SPF y DKIM pasan, pero DMARC falla. La causa probable: el dominio SPF (mail.captaindns.com) no está alineado con el dominio From (captaindns.com) y DMARC exige alineación estricta (aspf=s). La disposición dis=quarantine confirma que el mensaje fue enviado a spam.

Corrección rápida: publica o corrige tu registro SPF, verifica tu firma DKIM y despliega una política DMARC como mínimo en p=none para empezar a recibir informes.

Escenario 2: ¿este correo viene realmente de mi director?

Encabezados a verificar: From, Return-Path, DKIM-Signature, Authentication-Results

Ejemplo concreto: un correo que parece venir de tu CEO pero que es un fraude al presidente.

From: Jean-Marc Duval - CEO <jm.duval@captaindns.com>
Return-Path: <jmduval.ceo@gmail.com>
Reply-To: jmduval.urgent@protonmail.com
Authentication-Results: mx.captaindns.com;
    spf=pass smtp.mailfrom=gmail.com;
    dkim=pass header.d=gmail.com;
    dmarc=fail header.from=captaindns.com

El display name muestra "Jean-Marc Duval - CEO" y la dirección From muestra captaindns.com. Pero el Return-Path apunta a una cuenta Gmail, el Reply-To a ProtonMail, y DMARC falla porque DKIM está firmado por gmail.com, no por captaindns.com. Es un fraude al presidente clásico.

Método:

1. Compara el From con el Return-Path. Si apuntan a dominios diferentes sin razón legítima (ningún servicio de envío de terceros conocido), es una señal de alerta
2. Verifica Authentication-Results: un dmarc=fail en un correo que dice venir del dominio de tu empresa confirma una suplantación
3. Examina DKIM-Signature: el d= debería corresponder al dominio de tu empresa
4. Mira el Reply-To: si apunta a un dominio externo (gmail.com, protonmail.com), es un fraude al presidente clásico

Regla de oro: si From dice una cosa y Authentication-Results dice otra, confía en los resultados de autenticación. Solo el 4 % de los dominios aplican una política DMARC p=reject (Valimail 2025), lo que deja la puerta abierta a este tipo de suplantación en la gran mayoría de los dominios.

Escenario 3: ¿cuánto tiempo lleva mi correo en tránsito?

Encabezados a verificar: los timestamps de cada encabezado Received

Método:

1. Lista todos los encabezados Received de abajo hacia arriba
2. Anota la marca de tiempo de cada hop
3. Calcula el retraso entre cada par de hops consecutivos
4. El hop con el mayor retraso es el cuello de botella

Umbrales indicativos:

• Menos de 5 segundos entre dos hops: normal
• 5 a 30 segundos: aceptable para un servidor con carga
• Más de 30 segundos: problema de greylisting, cola saturada o DNS lento
• Más de 5 minutos: el servidor probablemente puso el mensaje en cola y lo reintentó

Escenario 4: ¿mi DKIM está bien firmado?

Encabezados a verificar: DKIM-Signature, Authentication-Results

Método:

1. Localiza el encabezado DKIM-Signature en el mensaje en bruto
2. Verifica que d= corresponde a tu dominio de envío
3. Anota el selector s= y comprueba que el registro DNS correspondiente está publicado
4. Mira el veredicto DKIM en Authentication-Results: dkim=pass confirma que todo funciona

Causas frecuentes de fallo DKIM:

• Clave DNS eliminada o mal publicada
• Rotación de clave sin actualización del servidor de envío
• Modificación del mensaje en tránsito (por una lista de correo o una herramienta de reescritura de URL)
• Encabezado h= que no cubre todos los encabezados modificados

Escenario 5: ¿este enlace es phishing?

Encabezados a verificar: From, Reply-To, Return-Path, Authentication-Results, ARC-*

Método:

1. Verifica el From: ¿el dominio es exactamente el esperado? Cuidado con los homoglifos (captaindns.com vs captaindnss.com vs captaindns.co)
2. Compara con el Return-Path: un dominio completamente diferente es sospechoso
3. Verifica Authentication-Results: spf=fail + dkim=fail + dmarc=fail en un correo supuestamente legítimo es una señal fuerte de phishing
4. Si el mensaje fue reenviado, verifica los encabezados ARC-Authentication-Results para ver si la autenticación era válida en el punto de origen
5. Un Reply-To hacia un dominio gratuito (gmail.com, yahoo.com) en un correo corporativo es un clásico del phishing

Para profundizar en las técnicas de spoofing durante el enrutamiento de correo, lee nuestro análisis sobre el spoofing a través del enrutamiento de correo y la alerta de Microsoft.

Escenario 6: un proveedor dice haber enviado un correo que nunca recibí

Encabezados a verificar: los timestamps Received, Authentication-Results

Contexto: tu proveedor afirma haber enviado una factura el 15 de marzo. Nunca la recibiste. ¿Quién tiene razón?

Método:

1. Pide al proveedor que te envíe los encabezados completos del mensaje original (no un reenvío, sino los encabezados del mensaje enviado)
2. Verifica el primer Received (abajo): contiene la marca de tiempo del envío inicial. Si el timestamp corresponde al 15 de marzo, el mensaje fue efectivamente enviado al servidor SMTP
3. Sigue la cadena Received hop por hop. Si el último hop muestra una entrega a tu servidor MX, el mensaje fue recibido por tu infraestructura y el problema está en el filtrado
4. Si la cadena se detiene antes de tu MX, verifica Authentication-Results: un spf=fail o dmarc=fail pudo haber provocado un rechazo silencioso por parte de tu servidor

Consejo: los timestamps de los encabezados Received constituyen una prueba técnica con marca de tiempo del tránsito del mensaje. En caso de disputa, documentan objetivamente si el correo fue enviado, cuándo y hasta dónde llegó en la cadena de enrutamiento.

Plan de acción: 5 pasos para dominar los encabezados

Ya tienes los conocimientos teóricos. Aquí te mostramos cómo ponerlos en práctica.

Paso 1: extraer y analizar un primer correo

Elige un correo que hayas enviado tú mismo (o un correo de prueba). Extrae los encabezados con el método adecuado para tu cliente de correo. Pégalos en la herramienta de análisis de encabezados y compara el resultado automático con tu lectura manual.

Paso 2: verificar tu autenticación

Envía un correo desde tu dominio a una dirección Gmail. Abre los encabezados y verifica que SPF, DKIM y DMARC muestren todos pass. Si alguno de los tres falla, identifica y corrige la causa antes de pasar al siguiente paso.

Paso 3: aprender a detectar anomalías

Entrénate con correos legítimos para calibrar tu sentido de la normalidad. Cuando sabes cómo luce un correo "sano", las anomalías en un correo sospechoso se vuelven evidentes: servidores desconocidos en la cadena Received, dominios que no coinciden entre From y Return-Path, firmas DKIM inválidas.

Paso 4: automatizar la vigilancia

No verifiques los encabezados manualmente en cada correo. Configura DMARC con rua= para recibir informes agregados diarios. Estos informes te alertan automáticamente cuando los correos fallan la autenticación para tu dominio.

Paso 5: documentar tus flujos de envío

Lista todos los servicios que envían correos en tu nombre (CRM, herramienta de marketing, ticketing, facturación). Para cada uno, verifica que SPF y DKIM estén correctamente configurados. Un flujo de envío olvidado es la causa más frecuente de fallos DMARC inesperados.

Conserva un documento compartido con tu equipo que liste cada servicio, la IP o el dominio de envío, el selector DKIM utilizado y la fecha de la última verificación. Este referencial te evitará buscar la causa de un fallo DMARC durante horas cuando un compañero añada una nueva herramienta de envío sin avisar al equipo técnico.

FAQ

¿Qué es un encabezado de correo?

Un encabezado de correo es una línea de metadatos en formato "Nombre: Valor" que acompaña a cada mensaje. Los encabezados contienen la información de enrutamiento (servidores atravesados), los resultados de autenticación (SPF, DKIM, DMARC), la identidad del remitente y del destinatario, y anotaciones añadidas por los filtros antispam. El cuerpo del mensaje (texto, imágenes, adjuntos) está separado de los encabezados por una línea en blanco.

¿Cómo ver los encabezados en Gmail?

Abre el correo en cuestión, haz clic en el menú de tres puntos verticales en la esquina superior derecha del mensaje y selecciona "Mostrar original". Gmail abre una nueva página con los encabezados completos y un resumen de los resultados SPF, DKIM y DMARC en la parte superior. Puedes copiar la totalidad de los encabezados con el botón "Copiar al portapapeles".

¿Por qué los encabezados Received se leen de abajo hacia arriba?

Cada servidor SMTP que procesa un correo añade su encabezado Received encima de los encabezados existentes. El primer servidor (origen) queda abajo y el último servidor (recepción) queda arriba. Para reconstruir el trayecto cronológico del mensaje, hay que leer los encabezados Received de abajo hacia arriba. Es un mecanismo definido por la RFC 5321.

¿Qué significa spf=softfail en Authentication-Results?

Un veredicto spf=softfail significa que la dirección IP del servidor de envío no está explícitamente autorizada por el registro SPF del dominio, pero tampoco está explícitamente prohibida. Corresponde al mecanismo ~all (tilde) en el registro SPF. El servidor de recepción generalmente acepta el mensaje pero lo trata con desconfianza. Suele ser señal de un servidor de envío olvidado en la configuración SPF.

¿Cómo detectar un correo spoofed a través de los encabezados?

Compara tres elementos: el campo From (dirección mostrada), el Return-Path (dirección de rebote) y el dominio en DKIM-Signature (d=). Si el From muestra un dominio legítimo pero el Return-Path apunta a un dominio diferente y Authentication-Results muestra dmarc=fail, el mensaje probablemente fue suplantado. Un SPF fail combinado con un DKIM fail confirma que el servidor de envío no está autorizado por el dominio mostrado.

¿Los encabezados pueden ser falsificados?

Algunos encabezados pueden ser falsificados por el remitente: From, Reply-To, Subject e incluso ciertos encabezados Received. En cambio, los encabezados añadidos por el servidor de recepción (Authentication-Results, Received del servidor final, X-Spam-Score) son fiables porque los genera tu propia infraestructura. Por eso hay que basarse siempre en los resultados de autenticación del servidor de recepción, no en los encabezados definidos por el remitente.

¿Cuál es la diferencia entre From y Return-Path?

El From es la dirección mostrada en el cliente de correo, definida por el remitente en el cuerpo de los encabezados del mensaje. El Return-Path es la dirección del sobre SMTP (MAIL FROM), utilizada para las notificaciones de rebote. Pueden diferir legítimamente cuando un servicio de terceros envía correos en tu nombre. DMARC verifica la alineación entre estas dos direcciones: si los dominios son demasiado diferentes sin razón válida, el mensaje puede fallar la verificación DMARC.

¿Cómo automatizar el análisis de encabezados?

Pega tus encabezados en bruto en una herramienta de análisis como la de CaptainDNS. La herramienta descompone cada campo, calcula los retrasos entre los hops Received, verifica los resultados de autenticación y resalta las anomalías. Para una vigilancia continua, configura DMARC con una dirección rua= para recibir informes agregados diarios sobre la autenticación de todos los correos enviados desde tu dominio.

Glosario

• Encabezado de correo (header): línea de metadatos en formato "Nombre: Valor" que acompaña a cada mensaje, conteniendo la información de enrutamiento, autenticación y procesamiento.
• Received: encabezado añadido por cada servidor SMTP atravesado, formando la traza de enrutamiento del mensaje. Se lee de abajo hacia arriba para reconstruir el orden cronológico.
• Return-Path: dirección del sobre SMTP (MAIL FROM) a la que se envían los mensajes de rebote. Añadido por el servidor de recepción final.
• Authentication-Results: encabezado añadido por el servidor de recepción que resume los veredictos de las verificaciones SPF, DKIM y DMARC.
• SPF (Sender Policy Framework): protocolo que verifica si la dirección IP del servidor de envío está autorizada por el DNS del dominio remitente (RFC 7208).
• DKIM (DomainKeys Identified Mail): protocolo de autenticación por firma criptográfica que verifica la integridad y el origen de un mensaje (RFC 6376).
• DMARC (Domain-based Message Authentication, Reporting and Conformance): protocolo que verifica la alineación del dominio From con los dominios autenticados por SPF y DKIM (RFC 7489).
• ARC (Authenticated Received Chain): mecanismo que preserva los resultados de autenticación cuando un mensaje atraviesa intermediarios como las listas de correo.
• Folding: técnica de continuación de un encabezado en varias líneas, identificada por una indentación (espacio o tabulación) al inicio de la línea siguiente.
• SCL (Spam Confidence Level): puntuación de spam asignada por Microsoft Exchange, de -1 (confianza) a 9 (spam seguro).
• Hop: paso de un mensaje de un servidor SMTP a otro en la cadena de enrutamiento. Cada hop se documenta mediante un encabezado Received.
• ESMTPS: Extended SMTP con TLS, que indica una transmisión cifrada entre dos servidores.

Fuentes

• RFC 5322 - Internet Message Format
• RFC 7601 - Message Header Field for Indicating Message Authentication Status
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 7208 - Sender Policy Framework (SPF)
• Google Support - Ver los encabezados completos del mensaje
• Verizon 2025 Data Breach Investigations Report (DBIR)
• IBM Cost of a Data Breach Report 2025
• Egress Email Security Risk Report 2024
• Valimail Email Authentication Report 2025