Leer las cabeceras del correo para detectar suplantaciones

Todo correo lleva en sus cabeceras un rastro completo: los servidores por los que pasó, los resultados de autenticación y el verdadero remitente del sobre. Leerlas con soltura es la forma más rápida de confirmar o desmentir una sospecha de suplantación, y es una destreza esencial para triar phishing reportado.

Dónde encontrar las cabeceras en bruto

El mensaje renderizado esconde todo lo útil. Consiga el origen sin procesar:

• Gmail: Mostrar original.
• Outlook: Archivo → Propiedades → Encabezados de Internet (o Ver origen del mensaje).
• Apple Mail: Visualización → Mensaje → Origen sin procesar.
• Línea de órdenes: inspeccione el .eml directamente.

Para la ruta de entrega, las cabeceras se leen de abajo arriba: el salto más antiguo está abajo y el Received: del servidor receptor, arriba del todo.

Las identidades que importan

Hay dos valores «de»: y el phishing explota justo la distancia entre ellos.

• Remitente del sobre (Return-Path / MAIL FROM): se usa para el encaminamiento y los rebotes; lo comprueba SPF.
• From de cabecera (From:): lo que ve el usuario en su cliente.

Una suplantación suele mostrar un From: de confianza mientras el Return-Path apunta a otro sitio sin relación.

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

El nombre mostrado (IT Helpdesk) lo controla por completo el atacante y no prueba nada.

Interpretar Authentication-Results

La cabecera más importante con diferencia es Authentication-Results, añadida por su servidor receptor (fíese solo de la de su propio dominio, arriba del todo):

Authentication-Results: mx.yourcompany.example;
  spf=pass (sender IP is 198.51.100.10) [email protected];
  dkim=fail header.d=yourbank.example;
  dmarc=fail (p=reject) header.from=yourbank.example

Interprétela con cuidado:

• spf=pass aquí es una trampa: pasó para sketchy-host.ru, no para el visible yourbank.example. SPF comprueba el sobre, no el From:.
• dkim=fail: no hay firma válida alineada con el dominio de From:.
• dmarc=fail (p=reject): este es el veredicto que cuenta, la autenticación del dominio visible no se alinea. Un mensaje que llega a la bandeja pese a dmarc=fail merece escrutinio.

Compare siempre el dominio que cada mecanismo autenticó (smtp.mailfrom, header.d) con el dominio de From:. Autenticación sin alineación no significa nada.

Rastrear la ruta con Received

Cada salto antepone una línea Received:. Léalas de abajo arriba:

Received: from mail.evilrelay.ru (mail.evilrelay.ru [203.0.113.7])
    by mx.yourcompany.example ...; Tue, 08 Jul 2026 09:14:22 +0000
Received: from unknown (HELO localhost) (185.220.101.5)
    by mail.evilrelay.ru ...

Señales de alarma:

• La IP del salto de origen se geolocaliza lejos de donde el remitente dice estar.
• Un HELO falsificado (localhost, o un nombre de host que no cuadra con el DNS inverso).
• Huecos sospechosos o saltos de zona horaria en las marcas de tiempo.
• El primer salto de confianza es su propio MX: todo lo que está por debajo lo aporta el atacante y es falsificable, así que pondérelo en consecuencia.

Otras pistas en las cabeceras

• Divergencia de Reply-To: el From: parece un compañero, pero Reply-To desvía las respuestas a una dirección externa. Un clásico del BEC y del fraude del CEO.
• Dominio del Message-ID que no coincide con el dominio emisor.
• Cabeceras X-Mailer / X-PHP-Script que delatan una herramienta de envío masivo o un script PHP en un servidor comprometido.
• Unicode o punycode en el dominio de From: (xn--): un ataque homógrafo.

Lista rápida de triaje

1. ¿Dominio de From: == dominio de Return-Path?        (discrepancia = sospechoso)
2. Authentication-Results: ¿dmarc=pass y alineado?      (fail = sospechoso)
3. ¿Qué dominio autenticaron realmente SPF/DKIM?        (debe coincidir con From:)
4. ¿Reply-To difiere de From:?                          (sí = sospechoso)
5. ¿De dónde procede el salto Received inferior?        (geo inesperada = sospechoso)
6. ¿Punycode u homoglifos en el dominio de From:?       (sí = sospechoso)

Una sola cabecera rara vez prueba por sí misma una suplantación. El veredicto viene de la alineación: ¿coincide el dominio que se autenticó con el que ve la persona? DMARC existe precisamente para automatizar esa comparación, pero en el correo entrante de otros dominios sigue haciendo falta leerlo a mano.

Cómo ayuda GottaPhish

Leer cabeceras es una destreza reactiva y de especialistas, y la mayoría de los usuarios no las ve nunca. GottaPhish y su equipo de expertos tienden ese puente: phishing simulado realista —brechas de alineación, Reply-To cambiado, dominios parecidos— más paneles que informan exactamente de quién reportó, hizo clic o entregó credenciales. Nuestros expertos acompañan la puesta en marcha, diseñan escenarios que ejercitan los trucos de cabecera que usan los atacantes reales y ayudan a interpretar los resultados, afinando los manuales de triaje de los equipos técnicos mientras la formación enseña al resto las señales visibles que hay detrás de esas cabeceras.