Cómo detectar un correo de phishing leyendo sus cabeceras

Lee las cabeceras de un correo sospechoso línea a línea: From, Reply-To y Return-Path, la cadena Received y lo que de verdad prueban SPF, DKIM y DMARC.

Equipo de PureTempMail

Los ingenieros que crean y mantienen PureTempMail

Publicado en 30 de octubre de 2026

Respuesta corta

Abre el código fuente del mensaje y comprueba tres cosas: si DMARC se superó para el dominio de la línea From, si Reply-To apunta a otro sitio y si la primera línea Received procede de los servidores de la propia empresa. Un fallo en cualquiera de ellas es una señal de alarma seria. Que las tres se superen solo prueba quién envió el correo, no que el remitente sea honrado.

Todo correo lleva un bloque de cabeceras encima del texto que lees. Tu aplicación de correo lo oculta, pero ahí queda registrado de qué servidor vino el mensaje, qué dominio respondió por él y adónde iría de verdad tu respuesta. El phishing suele delatarse ahí, aunque el mensaje en sí parezca perfecto.

Gestionamos un servidor de correo entrante, así que leemos cabeceras sin procesar cada vez que un mensaje se comporta de forma extraña. Esta guía recorre línea a línea un bloque de cabeceras de phishing realista y después muestra el caso más difícil, en el que todas las comprobaciones se superan. Mientras lees, puedes pegar las cabeceras de cualquier mensaje en nuestro analizador de cabeceras de correo. Funciona en tu navegador y las cabeceras nunca se envían a nuestros servidores.

Primer paso: saca las cabeceras de tu aplicación de correo

Todos los clientes de correo ocultan las cabeceras por defecto. En Gmail, abre el mensaje, haz clic en el menú de tres puntos junto a Responder y elige Mostrar original. En Outlook en la web, abre el menú de tres puntos y luego Ver y Ver origen del mensaje. En Apple Mail en un Mac, elige View, Message, All Headers. La página del analizador de cabeceras recoge las rutas de menú de Outlook para Windows, Yahoo y otros.

Copia todo lo que hay antes de la primera línea en blanco. Ese es el bloque de cabeceras. El cuerpo del mensaje va después y no hace falta. En iPhone y iPad, la app Mail integrada no muestra las cabeceras, así que reenvía el mensaje a un ordenador o revísalo en el correo web.

Las cabeceras de un correo de phishing, línea a línea

Este es el bloque de cabeceras de un phishing típico de alerta de cuenta, recortado a las líneas que importan. Los dominios y direcciones son ficticios, pero el patrón es el que vemos una y otra vez. Las cabeceras se apilan de la más reciente a la más antigua, así que el servidor que te entregó el mensaje está cerca de arriba y el punto de partida queda más abajo.

Return-Path: <[email protected]>
Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=mail.example.net;
    dkim=none;
    dmarc=fail (p=none) header.from=examplebank.com
Received: from mail.example.net (unknown [203.0.113.45])
    by mx.example.com with ESMTPS; Thu, 29 Oct 2026 09:14:07 +0000
Received: from desktop-4kq2 (unknown [198.51.100.23])
    by mail.example.net with ESMTPA; Thu, 29 Oct 2026 09:14:05 +0000
From: "Example Bank Security" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Unusual sign-in: confirm your account within 24 hours
Date: Thu, 29 Oct 2026 09:14:02 +0000
Message-ID: <20261029091402.4471@desktop-4kq2>

Un bloque de cabeceras abreviado. Example Bank es ficticio; en este caso, examplebank.com es el dominio del banco real y example.net el del atacante.

Qué te dice cada línea

Return-Path: La dirección a la que van los rebotes, también llamada remitente del sobre. Aquí está en mail.example.net, no en el dominio del banco. Por sí sola prueba poco, porque los boletines enviados a través de un proveedor de envíos tienen el mismo aspecto. Tenlo en cuenta para las líneas siguientes.
Authentication-Results: El veredicto que registró tu proveedor cuando llegó el mensaje. SPF se superó, pero para mail.example.net, el servidor del atacante. No hay firma DKIM. DMARC, la única comprobación que mira el dominio From que realmente ves, ha fallado para examplebank.com. Es la línea más útil de todo el bloque.
Received (arriba): La añadió el servidor de tu propio proveedor, mx.example.com, al aceptar el mensaje de 203.0.113.45. Las líneas que escribe tu proveedor son fiables. Todo lo que hay por debajo lo escribieron máquinas de las que no sabes nada.
Received (abajo): El paso más antiguo, así que la cadena se lee de abajo arriba. El mensaje salió de una máquina que se hace llamar desktop-4kq2 y se entregó a mail.example.net con un envío autenticado (ESMTPA). El sistema de alertas de un banco no funciona en el ordenador de alguien. Un buzón robado o alquilado, sí.
From: El nombre visible dice Example Bank Security y la dirección dice ser de examplebank.com. Cualquiera puede escribir lo que quiera en este campo. El fallo de DMARC de arriba es la prueba de que esta línea From está falsificada.
Reply-To: Si pulsas Responder, tu respuesta va a example.org, un tercer dominio. Un banco que quiere que llames o inicies sesión no tiene motivo para recoger respuestas en el dominio de otro. El phishing que te pide responder con tus datos casi siempre rellena este campo.
Subject y Date: Urgencia más un plazo. Date es solo lo que afirma la máquina que envía, pero compárala con las marcas de hora de Received: una diferencia de horas o días entre Date y el primer paso puede significar que el mensaje estuvo en una cola de spam antes de llegarte.
Message-ID: Un identificador único que se inventa el software que envía. Los sistemas de las grandes empresas lo marcan con su propio dominio. Este termina en desktop-4kq2, la misma máquina doméstica de la última línea Received. Una discrepancia aquí es un indicio, no una prueba, porque mucho software legítimo usa identificadores genéricos.

Juntándolo todo, la historia está clara: un mensaje que dice venir del banco salió de un ordenador de sobremesa a través del servidor de correo de un desconocido, no superó la autenticación del propio banco y quiere tu respuesta en un tercer dominio. Cuando sabes dónde mirar, llegas a esa conclusión en menos de un minuto, y el analizador de cabeceras te señala el fallo de DMARC y la discrepancia de Reply-To.

SPF, DKIM y DMARC explicados con claridad

Estas tres comprobaciones son la parte de las cabeceras que escribe el servidor receptor después de examinar el mensaje, no texto que haya tecleado el remitente. Cada una responde a una pregunta distinta.

SPF: ¿Puede este servidor enviar correo en nombre del dominio del remitente del sobre? El propietario del dominio publica en el DNS una lista de servidores autorizados y el receptor la compara con la dirección IP que se conecta. SPF comprueba el dominio de Return-Path, no la dirección From que ves, y por eso un phishing puede superar SPF para su propio dominio. Consulta SPF en nuestro glosario.
DKIM: ¿Firmó un dominio el mensaje y se ha modificado desde entonces? El servidor emisor añade una firma criptográfica y el receptor la verifica con una clave pública publicada en el DNS del firmante. El valor header.d= indica el dominio que firmó. Una firma válida de un dominio sin relación no dice nada de la marca que aparece en la línea From.
DMARC: ¿Coincide el dominio de la línea From con un dominio que superó SPF o DKIM? Este paso de alineación es lo que vincula las comprobaciones con el nombre que realmente lees. DMARC también permite al propietario del dominio indicar a los receptores qué hacer con los fallos: nada (p=none), cuarentena o rechazo. Por eso un mensaje falsificado puede llegar a tu bandeja de entrada cuando la empresa real no ha activado la aplicación de su política.

Qué significa cada resultado

Resultado	Qué significa	Cuánto preocuparse
`pass (Superado)`	La comprobación se superó para el dominio que aparece al lado.	Poco, pero mira qué dominio la superó. Un pass para un dominio parecido sigue siendo phishing.
`fail (Fallido)`	Las propias reglas del dominio dicen que este mensaje no debería haber salido de donde salió.	Mucho si es DMARC para una marca que conoces.
`softfail (Fallo leve)`	Solo SPF. El dominio dice que probablemente el servidor no está autorizado, pero pide a los receptores que no lo rechacen directamente.	Moderado. Es habitual con reenvíos y registros SPF mal mantenidos; sospechoso si se suma a otras señales.
`neutral (Neutral)`	El dominio no se pronuncia en ningún sentido sobre este servidor.	Trátalo como ausencia de pruebas.
`none (Ninguno)`	No había ningún registro ni firma que comprobar.	Moderado en una gran empresa, que normalmente publicaría los tres.
`temperror / permerror`	La comprobación no pudo ejecutarse: un tiempo de espera agotado en el DNS o un registro roto en el lado del remitente.	Poco por sí solo. Fíjate en los demás resultados.

El caso difícil: todas las comprobaciones se superan

Los atacantes cuidadosos no falsifican el dominio de un banco. Registran uno parecido, configuran bien SPF, DKIM y DMARC y envían desde él. Así, las cabeceras parecen impecables:

Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=examplebank-secure.com;
    dkim=pass header.d=examplebank-secure.com;
    dmarc=pass header.from=examplebank-secure.com
From: "Example Bank" <[email protected]>

Las tres comprobaciones se superan, porque el atacante es dueño de examplebank-secure.com y lo configuró correctamente.

La autenticación prueba que examplebank-secure.com envió este correo. No puede decirte si ese dominio pertenece a tu banco. Esa parte te toca a ti, y se reduce a leer el dominio muy despacio. Estos son los trucos que más vemos:

Palabras añadidas. El nombre real más -secure, -login, -support o -verify.
Caracteres cambiados. rn en lugar de m, un cero en vez de la letra o, una letra duplicada o que falta.
Otra terminación. El nombre correcto en .co, .net o un dominio de nivel superior nuevo, en vez del que usa la empresa.
El nombre real como subdominio. En examplebank.com.account-check.net el dominio es account-check.net. Lee los dominios desde la derecha.
Alfabetos parecidos. Una а cirílica se ve idéntica a una a latina. En las cabeceras sin procesar, estos dominios suelen aparecer empezando por xn--, que es como se codifican los nombres de dominio no latinos.
Un nombre visible que hace todo el trabajo. "Example Bank" delante de una dirección de un dominio de correo web gratuito. Muchos móviles muestran solo el nombre, así que tócalo para ver la dirección.

Si no tienes claro si un dominio pertenece a la empresa, no uses nada del correo para averiguarlo. Escribe tú mismo la dirección de la empresa en el navegador y compara.

Señales de alarma en las cabeceras, por orden de importancia

Algunas señales son casi una prueba; otras solo cuentan cuando se acumulan. Así es, más o menos, como las valoramos.

Señal	Dónde mirar	Peso
DMARC falla para una marca conocida	Authentication-Results, `dmarc=fail header.from=`	Alto. Es muy probable que la línea From esté falsificada.
El dominio From se parece al real, pero no es exactamente el mismo	From y el valor `header.from=`	Alto, aunque todo se supere.
Reply-To en otro dominio	Reply-To	Alto cuando el mensaje te pide responder.
El primer paso es una máquina doméstica o un proveedor sin relación	Última línea Received (abajo)	Moderado. El correo legítimo suele salir de dentro de la empresa o de su proveedor de envíos.
Ningún resultado de autenticación	Falta Authentication-Results	Moderado en las grandes marcas, que publican SPF, DKIM y DMARC.
Dominio de Message-ID sin relación con el remitente	Message-ID	Bajo. Solo sirve como prueba complementaria.
Return-Path en otro dominio	Return-Path	Bajo. Es normal en boletines enviados a través de un servicio de envíos.

Una rutina de cinco minutos para cualquier correo sospechoso

Copia las cabeceras completas
Usa Mostrar original o Ver origen, como se explica arriba, y copia el bloque entero, incluidas todas las líneas Received.
Pégalas en un analizador de cabeceras
Nuestro analizador de cabeceras de correo muestra From, Reply-To y Return-Path uno al lado del otro, enseña los resultados de SPF, DKIM y DMARC y lista la ruta de entrega de la más antigua a la más reciente. El análisis se hace en tu navegador.
Comprueba DMARC frente al dominio From
Busca dmarc= y el dominio que aparece al lado. Un fallo para una marca que conoces basta para detenerte aquí y borrar el mensaje.
Lee cada dominio despacio, desde la derecha
From, Reply-To y el dominio que superó DKIM deberían pertenecer todos a la empresa. Atento a los trucos de dominios parecidos que hemos visto arriba.
Lee la cadena Received desde abajo
La línea más baja es donde empezó el mensaje. Fíate solo de las líneas que añadió tu propio proveedor, arriba del todo. Un remitente puede insertar líneas Received falsas e incluso una línea Authentication-Results falsa por debajo de ellas.
Revisa los enlaces sin hacer clic
Las cabeceras no muestran los enlaces del cuerpo. En un ordenador, pasa el ratón por encima de cada botón y lee la dirección que aparece en la esquina de la ventana. Cualquier cosa que no lleve al dominio real de la empresa es motivo para salir.

Si crees que es phishing

No hagas clic, no respondas y no abras adjuntos. Responder confirma que tu dirección se lee, y los adjuntos son la vía habitual por la que llega el malware.
Contacta con la empresa por otra vía. Escribe su dirección en el navegador o usa el número de tu tarjeta o contrato, nunca el del correo.
Denúncialo en tu aplicación de correo. En Gmail, usa el menú de tres puntos y Notificar phishing. En Outlook, usa Informar y luego Notificar phishing. Así se entrena el filtro para todos los usuarios de ese servicio.
Reenvíalo al Anti-Phishing Working Group en [email protected], que comparte los avisos con empresas de seguridad y navegadores.
En EE. UU., denúncialo ante la FTC en ReportFraud.ftc.gov, sobre todo si hay dinero o datos personales de por medio.
Si ya introdujiste una contraseña, cámbiala ahora en la web real, activa el inicio de sesión en dos pasos y cámbiala en cualquier otro sitio donde la hayas reutilizado. Nuestra guía para comprobar si tu correo aparece en una filtración de datos explica qué hacer en la primera hora tras una exposición.

En resumen

Para detectar un correo de phishing por sus cabeceras, fíate solo de lo que escribió tu propio proveedor, comprueba que DMARC se superó para el dominio exacto de la línea From y lee ese dominio con la atención suficiente para descubrir una imitación. Esos tres hábitos detectan la mayor parte del correo falsificado. Para el resto, lo más seguro es lo de siempre: ve directamente a la empresa en lugar de pasar por el correo. Pega el próximo mensaje sospechoso en el analizador de cabeceras y mira qué muestra.

Fuentes

IETF, RFC 7208: Sender Policy Framework (SPF), incluido el significado de pass, fail, softfail y neutral.
IETF, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.
IETF, RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC), publicada en 2026 y que sustituye a la RFC 7489.
IETF, RFC 8601: Message Header Field for Indicating Message Authentication Status, que define la cabecera Authentication-Results.
Comisión Federal de Comercio de EE. UU. (FTC), How to Recognize and Avoid Phishing Scams, para las direcciones de denuncia de la FTC y el APWG.
Anti-Phishing Working Group, Report Phishing.