Anatomía forense de un correo de phishing:

leer las cabeceras paso a paso

Correo y seguridad web  |  unfantasmaenelsistema.com

Un correo de phishing bien hecho engaña a simple vista: el logo del banco está perfecto, el tono es urgente pero verosímil y el remitente parece el de siempre. Pero un correo electrónico no es solo lo que ves en la pantalla. Debajo del mensaje viaja un bloque de metadatos —las cabeceras— que registra cada servidor por el que ha pasado, qué comprobaciones de autenticación superó y cuáles no, y a qué dirección real respondería si pulsas «Responder». Ese bloque es difícil de falsificar por completo, y es donde un analista confirma en treinta segundos lo que la vista tardaría en sospechar.

Este artículo es la continuación práctica de nuestro texto sobre SPF, DKIM y DMARC. Allí vimos cómo se autentica el correo; aquí vamos a abrir un mensaje sospechoso y leer sus tripas línea a línea: el sobre SMTP frente a las cabeceras, la cadena de servidores Received, los resultados de autenticación, y cómo examinar un enlace o un adjunto sin llegar a abrirlos. Todos los ejemplos usan un correo de laboratorio propio.

1. Un correo tiene tres capas, no una

Antes de analizar nada conviene separar tres cosas que el cliente de correo mezcla en una sola vista.

• El sobre SMTP: los datos que los servidores se intercambian durante la entrega con los comandos MAIL FROM y RCPT TO. Es como el sobre de una carta postal: el cartero lo usa para entregarla y luego se tira. El destinatario normalmente no lo ve, pero deja rastro en la cabecera Return-Path.
• Las cabeceras: decenas de líneas con formato Nombre: valor al principio del mensaje (From, To, Subject, Date, Received, DKIM-Signature…). Son el historial y la ficha técnica del correo.
• El cuerpo: el contenido que lees, en texto plano, en HTML, o ambos, más los adjuntos.

La clave del análisis es esta: el remitente que ves en tu cliente sale del cuerpo de la cabecera From, y esa línea la escribe quien envía el correo. No hay ninguna comprobación en el protocolo SMTP que obligue a que sea cierta. SPF, DKIM y DMARC existen precisamente para ponerle una verificación encima, y el resultado de esa verificación también queda escrito en las cabeceras.

1.1 Cómo abrir las cabeceras completas

• Gmail: abre el correo, menú de tres puntos, «Mostrar original». Te da la fuente completa y un resumen de SPF/DKIM/DMARC.
• Outlook (escritorio): abre el mensaje en ventana propia, Archivo, Propiedades, campo «Encabezados de Internet».
• Outlook web / Microsoft 365: menú de tres puntos, «Ver», «Ver origen del mensaje».
• Thunderbird: selecciona el correo y pulsa Ctrl+U, o menú Ver, Código fuente del mensaje.
• Apple Mail: Visualización, Mensaje, Todos los encabezados (Cmd+Shift+H).

2. Las cabeceras Received: el recorrido real del correo

Cada servidor que toca el mensaje añade su propia línea Received en la parte de arriba del bloque de cabeceras, empujando las anteriores hacia abajo. Por eso se leen de abajo arriba: la línea más baja es el primer servidor que aceptó el correo (normalmente el del remitente), y la más alta es el último salto antes de tu buzón.

Una línea Received típica tiene esta forma: «from» el nombre que el servidor emisor dijo tener, seguido de «(» el nombre y la IP reales que el servidor receptor resolvió de esa conexión «)», luego «by» el servidor que recibe, «with» el protocolo, y la marca de tiempo.

Received: from mail.correo-legitimo.example (mail.correo-legitimo.example [198.51.100.24])
        by mx.tu-proveedor.example with ESMTPS id ABC123
        (version=TLS1.3 cipher=TLS_AES_256_GCM_SHA384);
        Tue, 26 Aug 2026 09:14:22 +0000 (UTC)
 
Received: from [10.0.0.5] (host-sospechoso.example [203.0.113.77])
        by mail.correo-legitimo.example with ESMTPA id XYZ789;
        Tue, 26 Aug 2026 09:14:19 +0000 (UTC)

2.1 Qué buscar en la cadena

• Incoherencia entre el nombre anunciado y el real: el servidor dice «from mail.tubanco.example» pero la IP resuelve a un proveedor de hosting sin relación con el banco.
• El país o el proveedor de la primera IP: si un correo supuestamente de una empresa española nace en una IP residencial de otro continente, es una señal.
• Saltos de tiempo raros: fechas que van hacia atrás entre saltos, o retrasos de horas, sugieren manipulación o reenvío por infraestructura intermedia.
• Pocas o ninguna línea Received antes de tu proveedor: correo inyectado directamente en un relay abierto o mal configurado.

3. Authentication-Results: el veredicto de SPF, DKIM y DMARC

El servidor que recibe el correo por ti ejecuta las comprobaciones de autenticación y escribe el resultado en una cabecera Authentication-Results. Es la línea que más rápido resuelve un caso.

Authentication-Results: mx.tu-proveedor.example;
       spf=fail (sender IP is 203.0.113.77)
         smtp.mailfrom=devoluciones.paqueteria.example;
       dkim=none;
       dmarc=fail (p=REJECT) header.from=tubanco.example

El detalle que más se pasa por alto: SPF y DKIM pueden dar pass y aun así ser phishing. SPF valida el dominio del Return-Path, que el atacante elige libremente; DKIM valida el dominio que firma, que puede ser el suyo. Solo DMARC exige que alguno de los dos coincida con el dominio que el usuario ve en el From. Por eso dmarc=fail sobre un dominio conocido es la alarma principal.

3.1 ARC, cuando el correo pasa por una lista o un reenvío

Reenviar un correo o pasarlo por una lista de distribución rompe SPF (cambia la IP de salida) y a veces DKIM (si se modifica el asunto o se añade un pie). ARC (Authenticated Received Chain) permite que cada intermediario firme un «sello» que dice «cuando yo lo recibí, la autenticación estaba bien». Tu proveedor puede confiar en esa cadena ARC si confía en el intermediario. En un análisis, las cabeceras ARC-Seal y ARC-Authentication-Results te dicen por dónde pasó y en qué estado.

4. Return-Path, From y Reply-To: los tres remitentes

Un correo tiene hasta tres direcciones de origen distintas, y en un mensaje legítimo suelen ser coherentes entre sí. En un fraude casi nunca lo son.

4.1 Trucos de dominio que hay que mirar con lupa

• Lookalike: tubanco-seguridad.example, tubanco.example.com, tu-banco.example.
• Homográfico: letras de otro alfabeto que se ven idénticas (una «a» cirílica en lugar de la latina). El dominio real en Punycode empieza por xn--.
• Subdominio engañoso: tubanco.example.verificacion-login.example — el dominio de verdad es siempre lo que va justo antes del primer «/», leyendo de derecha a izquierda hasta el segundo punto.
• TLD distinto: la empresa usa .es y el correo llega de un .top, .xyz o .click recién registrado.

5. X-headers: lo que añade el filtro antispam

Las cabeceras que empiezan por X- no son estándar: cada proveedor y cada pasarela de seguridad añade las suyas. Suelen contener la puntuación de spam y las razones. No son infalibles, pero orientan.

• X-Spam-Score / X-Spam-Level: puntuación numérica; cuanto más alta, más señales negativas.
• X-Spam-Status: a menudo lista las reglas que dispararon (URI en lista negra, texto typical-phish, SPF_FAIL…).
• X-Forefront-Antispam-Report / X-Microsoft-Antispam (Microsoft 365): SCL, BCL y veredictos.
• X-Originating-IP: en algunos sistemas, la IP del cliente que redactó el correo.
• X-Mailer / User-Agent: el programa que generó el mensaje; un banco no envía desde un script PHP casero ni desde un cliente de escritorio.

6. Analizar el enlace y el adjunto sin abrirlos

El objetivo del análisis es sacar indicadores sin ejecutar nada. Todo esto se hace sobre el texto de la cabecera y del cuerpo, o en una máquina aislada.

6.1 La URL

• Copia el enlace como texto (clic derecho, «Copiar dirección»), nunca lo pulses. En el cuerpo HTML, el texto visible y el href real pueden no coincidir.
• Si es un acortador (bit.ly, cutt.ly…), muchos permiten ver el destino añadiendo un «+» al final de la URL, o se resuelve con un servicio de «unfurl» o expansión de enlaces.
• Fíjate en el dominio real (regla del segundo punto de derecha a izquierda), en subdominios larguísimos y en parámetros que llevan tu dirección de correo ya rellenada.
• Consulta la reputación del dominio y su fecha de registro (WHOIS): dominio creado hace tres días = señal muy fuerte. Y busca su certificado en Certificate Transparency (crt.sh).
• Servicios como VirusTotal o urlscan.io analizan la URL en su propia infraestructura y te devuelven capturas y veredictos sin que tú la visites.

6.2 El adjunto

• No lo abras en tu equipo. Guárdalo en una carpeta aislada o trabájalo en una máquina virtual sin red.
• Calcula su hash (SHA-256) y búscalo en VirusTotal: si ya está catalogado, tienes la respuesta sin detonarlo.
• Desconfía de la doble extensión (factura.pdf.exe), de los .htm/.html adjuntos (páginas de login locales), de los .iso/.img/.lnk y de los documentos de Office que piden «Habilitar edición» o «Habilitar contenido».
• Para ver qué hace de verdad, un sandbox de malware (lo cubrimos en otro artículo de la serie) lo ejecuta en un entorno controlado y te da el informe de comportamiento.

7. Herramientas para descomponer una cabecera

# Parsear una cabecera guardada en un fichero, en local, sin conexion
python3 - <<'EOF'
import email, pathlib
msg = email.message_from_bytes(pathlib.Path('sospechoso.eml').read_bytes())
for h in ('From', 'Return-Path', 'Reply-To', 'Authentication-Results'):
    print(h, '->', msg.get(h))
print('--- saltos ---')
for r in msg.get_all('Received', []):
    print(r.split(';')[-1].strip())
EOF

Conclusión

Un correo de phishing puede clonar a la perfección el aspecto de un mensaje legítimo, pero le cuesta mucho más falsificar de forma coherente todo el bloque de cabeceras: la cadena Received registra la IP real de origen, Authentication-Results deja por escrito si DMARC falló, y Return-Path y Reply-To delatan que el remitente visible no es quien parece.

El método es siempre el mismo: abre la fuente completa, lee las Received de abajo arriba hasta el primer servidor fiable, comprueba el veredicto DMARC contra el dominio del From, contrasta los tres remitentes, y saca los indicadores del enlace y del adjunto sin ejecutarlos. Con práctica, ese recorrido lleva menos de un minuto y convierte una sospecha en una certeza.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)