Cómo leer las cabeceras de un correo (y detectar un remitente falso)

Alguien te reenvía un mensaje y hace la pregunta que no tiene respuesta corta: «¿esto es real?».

El cuerpo no ayuda. Los logotipos se copian en segundos, el tono se imita y el texto visible de un enlace nunca ha tenido que coincidir con su destino. Pero cada mensaje lleva un segundo documento que el remitente no controla del todo: las cabeceras. Ese bloque registra qué servidores manejaron el mensaje, cuándo, y qué concluyó el lado receptor sobre quién lo envió. Es lo más parecido a una cadena de custodia que tiene el correo.

Esta es una guía para leerlo. Si prefieres el modelo detrás de las siglas primero —qué comprueba cada uno y por qué importa la alineación—, eso está en SPF, DKIM y DMARC: qué hace realmente cada uno. Aquí lo damos por sabido y leemos un mensaje real.

Conseguir las cabeceras en crudo

Lo que necesitas es el código fuente, no lo que muestra el cliente:

• Gmail — abre el mensaje, menú de tres puntos, Mostrar original.
• Outlook (escritorio) — Archivo → Propiedades, y lee el cuadro Encabezados de Internet.
• Apple Mail — Visualización → Mensaje → Todos los encabezados, o ⌥⌘U para el fuente en crudo.
• Thunderbird — Ctrl+U.

Copia todo desde arriba hasta la primera línea en blanco. Esa línea es donde acaban las cabeceras y empieza el cuerpo.

Conviene adoptar una costumbre antes de pegar eso en ningún sitio: las cabeceras contienen la dirección del destinatario, nombres de host internos y a menudo rangos de IP privadas. Es un motivo para elegir con cuidado a qué herramienta se las das. El analizador de cabeceras de correo las procesa por completo en tu navegador —no se sube nada— y puede enmascarar los nombres de buzón en lo que copias de vuelta, de modo que un bloque de cabeceras siga siendo compartible con un compañero.

Empieza por el veredicto: Authentication-Results

No empieces por arriba del archivo. Empieza por la única cabecera donde un servidor anotó sus conclusiones:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.provider.com;
  dkim=pass header.d=tuempresa.com;
  dmarc=pass header.from=tuempresa.com

Léela como tres hallazgos separados más la identidad a la que se aplica cada uno:

• spf=pass smtp.mailfrom=... — la IP que se conectó estaba autorizada a enviar por ese dominio. Fíjate en el dominio: con frecuencia es el dominio de rebotes de un proveedor, no el de la línea From.
• dkim=pass header.d=... — una firma verificó, y la hizo la clave de ese dominio.
• dmarc=pass header.from=... — un pass de SPF o DKIM pertenecía a un dominio alineado con el From visible. Este es el que habla del remitente que ve quien lee.

Dos advertencias sobre esta cabecera, y ambas importan.

Empieza por la entrada normal superior, pero no confíes en ella solo por estar arriba. Suele ser el resultado más reciente, aunque cualquiera aguas arriba puede insertar una cabecera que diga dmarc=pass. El authserv-id del principio (mx.example.net arriba) nombra al sistema que hace la afirmación; solo tiene sentido cuando pertenece a un sistema de correo en el que realmente confías, normalmente el de tu proveedor. Un dmarc=pass de un authserv-id desconocido sigue siendo la afirmación de un extraño.

Es un registro, no una nueva comprobación. El receptor las evaluó en el momento de la entrega y anotó el resultado. Nada de lo que hagas ahora las vuelve a ejecutar, y el DNS puede haber cambiado desde entonces.

Si la cabecera falta por completo, eso tampoco prueba nada: muchos sistemas no la añaden. Solo significa que este atajo no está disponible y que leerás el resto con más cuidado.

Cuando spf=pass aparece junto a dmarc=fail

Esta pareja hace que la gente busque un fallo del sistema, y es lo más útil que se puede aprender a reconocer de un vistazo:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.mailer.example;
  dkim=none;
  dmarc=fail header.from=tuempresa.com

No hay nada roto. SPF pasó, sí: para bounces.mailer.example, un dominio que no tiene nada que ver con tuempresa.com. Y no había firma DKIM que aportara la otra mitad. Así que ninguna identidad autenticada se alineó con la cabecera From, y DMARC falló.

Esa forma tiene dos explicaciones muy distintas, y separarlas es el trabajo de verdad:

• Un remitente legítimo que nunca se configuró para alinear — una plataforma de marketing o un sistema de tickets que envía como tú sin firmar con DKIM bajo tu dominio. Muy común, y se arregla en el proveedor.
• Una falsificación pura y dura — el dominio de otro pasando SPF mientras tu nombre está en la línea From.

El resto de las cabeceras es lo que separa ambas.

Recorre la cadena Received hacia atrás

Las cabeceras Received: son el historial de rutado. El mecanismo clave: cada servidor antepone su propia línea arriba. Así que la cadena se lee de más nueva a más antigua: el Received superior es el último salto y el de abajo dice ser el origen.

Received: from mx.example.net by inbox.example.net; Tue, 4 Aug 2026 10:00:12 +0000
Received: from mail.sender.example (mail.sender.example [198.51.100.7])
        by mx.example.net; Tue, 4 Aug 2026 10:00:09 +0000

Lee de abajo arriba para seguir el mensaje hacia delante en el tiempo. Hay tres cosas que merece la pena extraer:

Por dónde entró en tu infraestructura. Busca el salto más bajo escrito por un servidor en el que confíes. Ese es el límite, y es el importante, porque todo lo que hay por debajo lo escribió otra persona. Un mensaje falsificado puede llevar bajo esa línea un historial completamente inventado, con nombres de host y marcas de tiempo plausibles. Por debajo del límite, trata cada salto como una afirmación, no como un hecho.

La IP entre corchetes. Toma el literal entre corchetes ([198.51.100.7]) en lugar del nombre de host que lo precede: el nombre es lo que el servidor que conecta dijo ser, mientras que la dirección entre corchetes es lo que tu servidor observó. Si la IP de origen no encaja con la historia del remitente —correo de un banco llegando desde un rango residencial de un país sin relación—, es una señal que merece seguirse. Pásala por la búsqueda de direcciones IP para ver de quién es realmente.

El tiempo entre saltos. Cada salto lleva su marca de tiempo. Unos minutos de retraso suelen ser simple encolado. Más interesante es un hueco que no encaja: un mensaje que estuvo horas parado, o marcas de tiempo que van hacia atrás, lo que normalmente significa un reloj mal puesto pero de vez en cuando que la cadena se montó a mano.

Los campos de identidad, y dónde se contradicen

Un mensaje declara de quién viene en varios sitios, y una falsificación suele aparecer como una contradicción entre ellos.

From: — lo que ve quien lee. Ojo: el nombre visible es texto libre y no guarda ninguna relación con la dirección:

From: "Soporte <soporte@tubanco.example>" <ceo@dominio-cualquiera.example>

La mayoría de clientes muestran solo Soporte <soporte@tubanco.example>. La dirección real es la segunda. Una dirección incrustada dentro del nombre visible puede ser una trampa deliberada. Comprueba la dirección From real antes de actuar. En su contexto es una alerta fuerte, pero por sí sola no demuestra nada.

Return-Path: — adónde van los rebotes. Es el remitente del sobre registrado en la entrega. Difiere del dominio From constantemente y de forma legítima: suele ser un proveedor gestionando tus rebotes. Da contexto, pero no prueba qué identidad evaluó SPF: SPF puede usar el MAIL FROM de SMTP o, si la ruta inversa está vacía, HELO. Cuando aparezca, lee smtp.mailfrom o smtp.helo en Authentication-Results; esa es la identidad que dejó registrada el receptor.

Reply-To: — adónde va tu respuesta. También legítimo en muchísimas configuraciones (un buzón compartido, un servicio de soporte). Pero en un mensaje que ya falla DMARC, un Reply-To que apunta a un dominio sin relación es el mecanismo por el que una conversación acaba redirigida al atacante.

Message-ID: — el identificador asignado. Su parte de dominio suele ser el sistema que lo generó. Que difiera del dominio From es normal cuando un proveedor envía en tu nombre. Que esté malformado o ausente merece anotarse.

Ninguno de estos es concluyente por sí solo. Esa es la clave: la señal es el patrón, no un campo aislado. Un dominio From que falla DMARC, más un nombre visible que contiene otra dirección, más un Reply-To en otro sitio, componen una historia coherente que una simple mala configuración no cuenta.

Leer una firma DKIM

Si hay una cabecera DKIM-Signature:, unas pocas etiquetas deciden cuánto vale:

DKIM-Signature: v=1; a=rsa-sha256; d=tuempresa.com; s=selector1;
  h=from:to:subject:date; bh=...; b=...

• d= — el dominio firmante. Compáralo con el dominio From. Una firma perfectamente válida de un dominio sin relación no aporta nada a DMARC.
• s= — el selector, que junto con d= localiza la clave pública en selector1._domainkey.tuempresa.com. Puedes consultar ese registro TXT tú mismo con la herramienta de consulta DNS para confirmar que hay una clave publicada.
• h= — la lista de cabeceras cubiertas. Una firma que no incluye from no vale casi nada: el remitente visible se puede cambiar sin tocarla. Merece comprobarse explícitamente, porque es un fallo sutil que aun así se informa como dkim=pass.
• l= — un límite de longitud del cuerpo, firmando solo los primeros N bytes. Lo que se añada más allá queda sin firmar. Es poco frecuente, y motivo de sospecha cuando aparece.

Un límite que hay que reconocer: leer una firma no es verificarla. Verificarla exige el cuerpo sin modificar y la clave pública desde DNS, y cualquier cambio en tránsito invalida una firma que era correcta al escribirse. El analizador lee los campos y comprueba las propiedades estructurales de arriba; el dkim=pass de Authentication-Results es la verificación del receptor, hecha en la entrega.

Las cabeceras ARC, y cuánto valen

El reenvío y las listas de correo rompen la autenticación por diseño: SPF falla porque la IP que retransmite no es tuya, y DKIM falla si la lista tocó el mensaje. ARC (Authenticated Received Chain, RFC 8617) existe para llevar el veredicto anterior al otro lado de esa ruptura. Lee correo real que haya pasado por Google o Microsoft y lo verás constantemente:

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example.org; s=arc;
  h=from:to:subject; b=...
ARC-Authentication-Results: i=1; lists.example.org;
  spf=pass smtp.mailfrom=tu@tuempresa.com;
  dkim=pass header.d=tuempresa.com; dmarc=pass

Tres cabeceras por intermediario, numeradas con i=:

• ARC-Authentication-Results — los resultados de autenticación que vio ese salto, antes de cambiar nada. Este es el contenido de verdad.
• ARC-Message-Signature — la firma de ese salto sobre el mensaje, para que su instantánea no se pueda editar después.
• ARC-Seal — una firma sobre la cadena misma, que es lo que la convierte en una cadena y no en un montón de afirmaciones sueltas.

Lee i= como la posición: i=1 es el primer intermediario, i=2 volvió a sellar después. En el ARC-Seal de número más alto, cv= informa de la validación de la cadena: none en el primer salto, pass si lo verificado hasta ahí cuadra, fail si no. Un cv=fail significa que la cadena se rompió en algún punto, y los resultados que transporta no prueban nada.

Y ahora lo que importa para juzgar un mensaje: ARC no es un atajo, y una cadena válida no es un DMARC que pasa. Cualquiera puede adjuntar un conjunto ARC afirmando que el mensaje pasó todo, atacantes incluidos. Solo cuenta como prueba si el receptor final confía en el dominio que selló, que es la misma comprobación que aplicaste antes al authserv-id. Los receptores deciden por su cuenta a qué intermediarios hacen caso; ARC les da material para esa decisión, no una obligación.

Así que lee una cadena ARC como explicación, no como veredicto: te dice por qué un mensaje reenviado falló SPF y DKIM y aun así se entregó. El analizador informa de cuántos conjuntos ARC encontró y del estado de validación de la cadena, así que ves de un vistazo si el mensaje pasó por intermediarios.

Cómo se ven, lado a lado, lo falsificado y lo legítimo pero roto

Ambos fallan DMARC. Las cabeceras los distinguen:

El resumen honesto: una anomalía aislada suele ser una mala configuración; varias apuntando en la misma dirección significan que debes tratar el mensaje como hostil.

Una lista de comprobación

1. Consigue el código fuente y copia hasta la primera línea en blanco.
2. Lee Authentication-Results primero, y comprueba que el authserv-id pertenece a un sistema en el que confías.
3. Anota a qué dominio se aplica cada resultado, no solo si pasó o falló. Un spf=pass sobre el dominio de un desconocido no prueba nada sobre la línea From.
4. Encuentra tu límite de confianza en la cadena Received. Todo lo que hay debajo es una afirmación.
5. Toma la IP entre corchetes del salto de entrada y mira de quién es.
6. Compara los campos de identidad: dirección From frente a nombre visible, Return-Path, Reply-To, Message-ID.
7. Comprueba d= y h= en cualquier firma DKIM; confirma que from está cubierto.
8. Si hay conjuntos ARC, mira el cv= del de número más alto, y pregúntate si confías en el dominio que lo selló.
9. Valora el patrón, no un campo suelto.

En vez de hacer eso a ojo cada vez, pega el bloque en el analizador de cabeceras de correo: despliega la ruta salto a salto con el tiempo que costó cada uno, interpreta los resultados de autenticación en lugar de limitarse a repetirlos, señala la suplantación por nombre visible y los desajustes de identidad, y descompone las firmas DKIM campo a campo. Funciona localmente, así que el mensaje se queda en tu equipo.

Y cuando la conclusión sea que es tu propio dominio el que están falsificando —o que un remitente legítimo tuyo no consigue alinearse—, eso es un problema de configuración y no forense. Revisa qué publica tu dominio con el comprobador de SPF y DMARC, y si la respuesta es que la política aún no está activa, pasar de p=none a p=reject es la forma escalonada de arreglarlo sin perder correo por el camino.