Anatomía de un Email de Phishing: Headers, SPF, DKIM, DMARC y Red Flags

Por qué un analista SOC necesita leer headers

El cuerpo de un email de phishing es lo que ve la víctima. Los headers son lo que ve el analista. Mientras que el contenido visible puede falsificarse con un par de clics en cualquier herramienta de envío masivo, los headers SMTP cuentan la historia real del recorrido del mensaje: de dónde salió, por qué servidores pasó, si la autenticación fue legítima y qué mecanismos de protección fallaron (o se ignoraron).

Un analista que sabe leer headers convierte un email sospechoso en inteligencia accionable en minutos. Identifica la infraestructura del atacante, determina si el dominio remitente fue suplantado o comprometido, y extrae IOCs (IPs, dominios, URLs) que alimentan reglas de detección y bloqueo. Un analista que no sabe leerlos depende de lo que el gateway le diga, y los gateways no siempre aciertan.

Este artículo desmonta un email de phishing header por header. Explica cada campo relevante, los tres protocolos de autenticación (SPF, DKIM, DMARC) y los 15 red flags técnicos que distinguen un email legítimo de uno malicioso.

Estructura de un email SMTP

Un email tiene dos partes diferenciadas a nivel de protocolo:

El sobre SMTP (envelope): la conversación entre servidores. Se produce durante la sesión SMTP y contiene dos datos fundamentales: MAIL FROM (dirección del remitente real a nivel de transporte) y RCPT TO (destinatario). Esta información no es visible para el usuario final en la mayoría de clientes de correo.

El mensaje (headers + body): lo que se transmite después del comando DATA. Incluye los headers visibles (From:, To:, Subject:, Date:) y el cuerpo del mensaje (texto plano, HTML, adjuntos codificados en MIME).

La clave para entender el phishing es que el sobre y el mensaje son independientes. Un atacante puede configurar MAIL FROM: [email protected] en el sobre pero poner From: [email protected] en los headers del mensaje. El cliente de correo del usuario solo muestra el segundo. Esta desconexión es la base del email spoofing.

┌─────────────────────────────────────┐
│         SOBRE SMTP (Envelope)       │
│  MAIL FROM: [email protected]       │  ← Solo servidores lo ven
│  RCPT TO: [email protected]       │
├─────────────────────────────────────┤
│         HEADERS DEL MENSAJE         │
│  From: CEO <[email protected]>        │  ← El usuario ve esto
│  To: [email protected]            │
│  Subject: Urgente - Transferencia   │
│  Return-Path: [email protected]     │
│  Received: from mail.evil.com ...   │
│  Authentication-Results: ...        │
├─────────────────────────────────────┤
│         CUERPO (BODY)               │
│  HTML con enlace malicioso          │
│  Adjuntos (.pdf, .docx, .html)      │
└─────────────────────────────────────┘

Headers clave para el análisis

Return-Path

El Return-Path se establece a partir del MAIL FROM del sobre SMTP. Es la dirección a la que se envían los bounces (mensajes no entregados). En un email legítimo, coincide con el dominio del From:. En un email spoofed, revela el dominio real del atacante.

Return-Path: <[email protected]>

Si recibes un email supuestamente de [email protected] pero el Return-Path apunta a sendgrid.net o a un dominio desconocido, tienes el primer indicador de que algo no cuadra. No es definitivo por sí solo (muchas empresas usan servicios de envío legítimos), pero es el primer dato a cruzar.

Received (la cadena de custodia)

Cada servidor que procesa el email añade un header Received: en la parte superior. Se leen de abajo hacia arriba para seguir el recorrido cronológico del mensaje. Es el equivalente digital de una cadena de custodia forense.

Received: from gateway.empresa.com (10.0.1.5) by mx.empresa.com
    with ESMTPS; Thu, 05 Jun 2026 09:15:32 +0000
Received: from relay.proveedor.com (203.0.113.50) by gateway.empresa.com
    with ESMTP; Thu, 05 Jun 2026 09:15:30 +0000
Received: from mail.dominio-atacante.xyz (192.0.2.100) by relay.proveedor.com
    with SMTP; Thu, 05 Jun 2026 09:15:28 +0000

El último Received (el de abajo) revela el servidor de origen. La IP 192.0.2.100 y el dominio mail.dominio-atacante.xyz son IOCs directos. Los headers Received intermedios pueden ser forjados por el atacante, pero los que añade tu propia infraestructura (los de arriba) son fiables.

Regla práctica: confía en los headers Received que añadieron tus servidores. Desconfía de los que vienen de fuera.

From y Reply-To

From: es lo que el cliente de correo muestra al usuario. Es trivial de falsificar. Reply-To: indica a dónde irán las respuestas. En phishing tipo BEC (Business Email Compromise), el atacante pone un From: corporativo convincente y un Reply-To: diferente para capturar las respuestas.

From: "Director Financiero" <[email protected]>
Reply-To: [email protected]

La diferencia entre empresa.com y empresa-corp.com es sutil pero crítica. Este patrón (From legítimo, Reply-To en dominio lookalike) es uno de los más comunes en campañas BEC.

Message-ID

Identificador único del email, generado por el servidor de origen. El dominio tras el @ en el Message-ID suele coincidir con el servidor que originó el mensaje.

Message-ID: <[email protected]>

Si el email dice venir de empresa.com pero el Message-ID contiene @bulk-mailer.xyz, hay una discrepancia que merece investigación. Los servicios de email marketing legítimos (Mailchimp, SendGrid) generan Message-IDs con sus propios dominios, lo cual es normal. Pero un Message-ID con un dominio desconocido o sospechoso en un email supuestamente corporativo es un red flag.

Content-Type y MIME

El header Content-Type define el formato del cuerpo y los adjuntos. Los atacantes explotan MIME de varias formas:

Content-Type: multipart/mixed; boundary="----=_Part_12345"

Red flags en Content-Type:

• Doble extensión en adjuntos: factura.pdf.exe codificado en base64
• Content-Type mismatch: un archivo llamado documento.pdf con Content-Type: application/x-msdownload
• HTML embebido: Content-Type: text/html con JavaScript ofuscado que redirige a un kit de phishing
• Archivos .eml o .msg adjuntos: email dentro de email para evadir scanners

X-Headers

Los headers que comienzan con X- proporcionan información adicional del remitente y los servidores intermedios. No son estándar, pero son valiosos para el análisis:

Header	Qué revela
X-Originating-IP	IP real del cliente que envió el email (no siempre presente)
X-Mailer	Software usado para enviar (Outlook, Thunderbird, PHPMailer, custom)
X-Spam-Score	Puntuación de spam del gateway receptor
X-Spam-Flag	Si el gateway lo marcó como spam
X-MS-Exchange-Organization-AuthAs	Tipo de autenticación en Exchange (Anonymous = sospechoso)
X-Google-DKIM-Signature	Firma DKIM adicional de Google
X-Forefront-Antispam-Report	Detalles del filtrado de Microsoft 365
X-PHP-Originating-Script	Script PHP que generó el email (webshell indicator)

X-Originating-IP es particularmente valioso: si el email dice venir de la sede corporativa en Madrid pero el X-Originating-IP geolocaliza en un hosting barato en un país donde la empresa no tiene presencia, la discrepancia es significativa.

X-Mailer: PHPMailer o X-PHP-Originating-Script en un email corporativo que debería venir de Exchange/Microsoft 365 es un indicador fuerte de que el email se envió desde un servidor web comprometido.

SPF: Sender Policy Framework

Cómo funciona

SPF permite al propietario de un dominio declarar qué servidores están autorizados a enviar email en su nombre. Esta declaración se publica como un registro TXT en DNS.

empresa.com.  IN  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all"

Este registro dice: "Solo pueden enviar email como @empresa.com las IPs en el rango 203.0.113.0/24 y los servidores de Google Workspace. Todo lo demás, recházalo (-all)."

Resultados SPF

Cuando un servidor receptor recibe un email, consulta el registro SPF del dominio en el MAIL FROM del sobre y compara la IP del servidor que se lo entregó:

Resultado	Significado	Implicación para phishing
pass	IP autorizada en el SPF	El servidor está autorizado (no implica que el email sea legítimo)
fail	IP no autorizada, política -all	Spoofing probable. El dominio dice explícitamente que esa IP no debería enviar
softfail	IP no autorizada, política ~all	Sospechoso. El dominio no lo autoriza pero tampoco pide rechazo estricto
neutral	Política ?all, no se pronuncia	El dominio no tiene opinión. Común en configuraciones débiles
none	No hay registro SPF	Sin protección. Cualquier servidor puede enviar como ese dominio
temperror	Error temporal en DNS	No se pudo verificar. Algunos atacantes provocan esto intencionalmente
permerror	Registro SPF mal formado	Configuración rota. Frecuente en dominios abandonados que los atacantes reutilizan

Limitaciones de SPF

SPF tiene un problema fundamental: verifica el dominio del sobre (MAIL FROM), no el del header From: que ve el usuario. Un atacante puede usar MAIL FROM: [email protected] (que pasa SPF de evil.com) y From: [email protected] (que es lo que la víctima ve). SPF aprueba, pero el email es spoofed. DMARC existe precisamente para cerrar esta brecha.

Otra limitación: SPF se rompe con el reenvío de email. Si un usuario reenvía un email corporativo a su cuenta personal, el servidor reenviador cambia la IP de origen pero mantiene el MAIL FROM, provocando un fallo SPF legítimo.

DKIM: DomainKeys Identified Mail

Firma y verificación

DKIM añade una firma criptográfica al email. El servidor emisor firma ciertos headers y el cuerpo del mensaje con una clave privada. El receptor obtiene la clave pública del DNS del dominio firmante y verifica la firma.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=empresa.com; s=selector2026;
    h=from:to:subject:date:message-id;
    bh=LPJNul+wow64TY9F5BSb8iQ2dLxvN4F2rm5O/+lO3cY0=;
    b=dHJ5IG5vdCB0byBkZWNvZGUgdGhpcywgaXQncyBq
      dXN0IGEgcGxhY2Vob2xkZXI=

Los campos clave:

• d=: dominio que firma (el que se verifica)
• s=: selector, identifica qué clave pública usar en DNS
• h=: headers incluidos en la firma
• bh=: hash del body
• b=: la firma en sí

Para verificar, el receptor consulta selector2026._domainkey.empresa.com en DNS y obtiene la clave pública. Si la firma coincide, el contenido no fue alterado en tránsito y el dominio d= firmó el email.

Qué protege y qué no

DKIM garantiza integridad (el email no fue modificado) y autenticación del dominio firmante. Pero no impide que un atacante registre empresa-corp.com, configure DKIM correctamente y envíe emails firmados desde ese dominio lookalike. La firma DKIM será válida porque el atacante controla las claves de su propio dominio.

DKIM tampoco falla si la cuenta fue comprometida: un atacante que accede a una cuenta legítima de Microsoft 365 envía emails que pasan DKIM porque Microsoft firma con su infraestructura autorizada.

DMARC: Domain-based Message Authentication, Reporting and Conformance

El pegamento entre SPF y DKIM

DMARC resuelve el problema que ni SPF ni DKIM resuelven por separado: ¿qué hacer cuando el dominio del From: visible no coincide con los dominios verificados por SPF o DKIM?

DMARC introduce el concepto de alignment: el dominio del From: visible debe coincidir con el dominio verificado por SPF (MAIL FROM) o DKIM (d=). Sin alignment, SPF y DKIM pueden pasar sin que el From: visible esté protegido.

_dmarc.empresa.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

Las tres políticas

Política	Acción	Nivel de protección
p=none	Solo monitorizar, no actuar	Ninguno. Útil para fase inicial de despliegue
p=quarantine	Enviar a spam/cuarentena	Parcial. El email llega pero marcado
p=reject	Rechazar el email	Máximo. El email no se entrega

La realidad del panorama DMARC en 2026: la mayoría de dominios corporativos en España todavía usan p=none o directamente no tienen DMARC publicado. Esto significa que cualquiera puede enviar emails que parezcan venir de esos dominios sin consecuencias técnicas. Los atacantes lo saben y lo explotan activamente.

Alignment: strict vs relaxed

• Strict: el dominio debe coincidir exactamente. From: [email protected] no alinea con SPF/DKIM de empresa.com.
• Relaxed (default): basta con que el organizational domain coincida. mail.empresa.com alinea con empresa.com.

El modo relaxed es el más común y razonable para organizaciones con múltiples subdominios.

El header Authentication-Results

Este es el header que el servidor receptor genera tras evaluar SPF, DKIM y DMARC. Concentra los resultados de autenticación en un solo lugar y es el primer header que un analista SOC debería consultar.

Authentication-Results: mx.empresa.com;
    spf=fail (sender IP is 192.0.2.100) [email protected];
    dkim=fail (signature verification failed) header.d=empresa.com;
    dmarc=fail (p=REJECT) header.from=empresa.com;
    compauth=fail reason=000

Lectura rápida de este ejemplo:

1. SPF falló: la IP 192.0.2.100 no está autorizada para enviar como evil.com
2. DKIM falló: la firma no se verificó (el atacante no tiene la clave privada de empresa.com)
3. DMARC falló: ni SPF ni DKIM alinearon con el From: empresa.com, y la política es reject
4. compauth=fail: evaluación compuesta de Microsoft (combina múltiples señales)

Un email con triple fail (SPF + DKIM + DMARC) que aun así llega a la bandeja de entrada indica un problema en la configuración del gateway. Esto debería generar una alerta de configuración, no solo un ticket de phishing.

Caso práctico: análisis de un email de phishing

A continuación, un ejemplo sanitizado con headers reales de una campaña de phishing que suplantaba a un banco español. Las IPs y dominios están documentados como IOCs en fuentes públicas.

Return-Path: <[email protected]>
Received: from mx01.victima.es (10.0.0.5) by mail.victima.es
    with ESMTPS id ABC123; Thu, 05 Jun 2026 10:22:15 +0200
Received: from relay.hostingbarato.ru (91.215.XX.XX) by mx01.victima.es
    with ESMTP id DEF456; Thu, 05 Jun 2026 10:22:13 +0200
Received: from localhost (unknown [192.168.1.1])
    by srv-banco.xyz (Postfix) with ESMTP id GHI789;
    Thu, 05 Jun 2026 08:22:10 +0000
From: "Servicio de Seguridad" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: =?UTF-8?B?QWN0dWFsaXphY2nDs24gZGUgc2VndXJpZGFkIG9ibGlnYXRvcmlh?=
Date: Thu, 05 Jun 2026 08:22:10 +0000
Message-ID: <[email protected]>
X-Mailer: PHPMailer 6.8.1
X-PHP-Originating-Script: 1000:send.php
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_99887766"
Authentication-Results: mx01.victima.es;
    spf=softfail (domain of srv-banco.xyz does not designate 91.215.XX.XX
        as permitted sender) [email protected];
    dkim=none (no DKIM signature);
    dmarc=none (no DMARC record found for banco-ejemplo.es)
X-Spam-Score: 7.2
X-Spam-Flag: YES

Disección paso a paso

1. Return-Path vs From: [email protected] (Return-Path) no coincide con [email protected] (From). Dos dominios distintos. Spoofing evidente.

2. Cadena Received: el email se originó en srv-banco.xyz (Postfix en un servidor probablemente comprometido), pasó por relay.hostingbarato.ru (hosting ruso) y llegó al MX de la víctima. La IP 91.215.XX.XX es el IOC de red principal.

3. Reply-To: apunta a [email protected], no al banco real. Las respuestas irán al atacante.

4. Message-ID: @srv-banco.xyz confirma el origen real. No es el dominio del banco.

5. X-Mailer + X-PHP-Originating-Script: PHPMailer ejecutado desde send.php. Esto indica un servidor web comprometido o un hosting comprado para la campaña. Un banco legítimo enviaría desde Exchange, Google Workspace o una plataforma enterprise.

6. Authentication-Results:

• SPF softfail: srv-banco.xyz no tiene la IP del relay ruso en su SPF
• DKIM none: no hay firma DKIM (el atacante no se molestó en configurarla)
• DMARC none: banco-ejemplo.es no tiene registro DMARC publicado, lo que permite el spoofing del From: sin consecuencias

7. Subject codificado en Base64: "Actualización de seguridad obligatoria". El encoding Base64 del Subject es un intento de evadir filtros basados en keywords.

IOCs extraídos:

• IP: 91.215.XX.XX (relay)
• Dominio: srv-banco.xyz (infraestructura del atacante)
• Dominio: hostingbarato.ru (relay probablemente comprometido)
• Email: [email protected], [email protected]
• Software: PHPMailer 6.8.1 ejecutado desde send.php

Técnicas de spoofing

Direct spoofing (suplantación directa)

El atacante falsifica el From: sin controlar el dominio suplantado. Funciona cuando el dominio objetivo no tiene DMARC con política reject. Es la técnica más básica y la más fácil de prevenir con una configuración correcta de SPF + DKIM + DMARC.

Display name spoofing

El atacante no falsifica la dirección de email, sino el nombre visible:

From: "CEO Empresa" <[email protected]>

En clientes móviles que solo muestran el display name, el usuario ve "CEO Empresa" sin ver la dirección real. SPF, DKIM y DMARC pasan porque gmail.com tiene su autenticación correcta. Esta técnica explota la interfaz de usuario, no el protocolo.

Cousin domain (dominio primo)

El atacante registra un dominio similar al legítimo y configura SPF, DKIM y DMARC correctamente en ese dominio:

Dominio legítimo	Dominio primo	Técnica
empresa.com	empresa-corp.com	Adición de palabra
banco.es	banc0.es	Homoglifo (o → 0)
microsoft.com	rnicrosoft.com	Homoglifo (m → rn)
paypal.com	paypa1.com	Homoglifo (l → 1)
empresa.com	empresa.co	TLD diferente
empresa.com	empressa.com	Typosquatting

Toda la autenticación pasa porque el atacante es el propietario legítimo del dominio primo. La detección requiere monitorización de dominios similares (servicios como dnstwist, URLCrazy) y reglas de gateway que detecten dominios recién registrados.

Cuenta comprometida

La técnica más difícil de detectar. El atacante obtiene credenciales de una cuenta legítima (phishing previo, credential stuffing, password spray) y envía emails desde esa cuenta. SPF pasa, DKIM pasa, DMARC pasa. El email es técnicamente legítimo porque viene de la infraestructura autorizada.

Los indicadores en este caso son comportamentales, no de headers: horario inusual de envío, destinatarios fuera del patrón habitual del usuario, lenguaje atípico, adjuntos sospechosos, y cambios recientes de reglas de buzón (reenvío automático, borrado de enviados).

Red flags técnicos: los 15 indicadores

#	Indicador	Dónde mirarlo	Severidad
1	Return-Path no coincide con From	Return-Path: vs From:	Alta
2	SPF fail o softfail	Authentication-Results	Alta
3	DKIM fail o ausente	Authentication-Results	Alta
4	DMARC fail o none	Authentication-Results	Alta
5	Reply-To en dominio diferente al From	Reply-To: vs From:	Alta
6	Message-ID en dominio desconocido	Message-ID: dominio tras @	Media
7	X-Mailer: PHPMailer en email corporativo	X-Mailer:	Media
8	X-PHP-Originating-Script presente	X-PHP-Originating-Script:	Alta
9	IP de origen en hosting/VPS barato	Received: (último hop externo)	Media
10	Dominio registrado hace menos de 30 días	WHOIS del dominio en From/Return-Path	Alta
11	Subject codificado en Base64 innecesariamente	Subject: con =?UTF-8?B?	Baja
12	Content-Type mismatch con adjunto	Content-Type: vs extensión del archivo	Alta
13	Received chain con saltos geográficos ilógicos	Geolocalización de IPs en Received:	Media
14	Múltiples From: o discrepancias en encoding	Headers duplicados o malformados	Media
15	Timestamp inconsistente entre Received hops	Date: vs tiempos en Received:	Baja

Regla de scoring práctico: un email con 3 o más indicadores de severidad Alta merece escalado inmediato. Un email con 5 o más indicadores totales (cualquier severidad) debería tratarse como phishing confirmado hasta que se demuestre lo contrario.

Herramientas de análisis

Análisis de headers

Herramienta	Tipo	Uso
MXToolbox Header Analyzer	Web gratuita	Pega los headers y obtiene un desglose visual con alertas
Google Admin Toolbox Messageheader	Web gratuita	Análisis de headers con timeline de delivery
Mail Header Analyzer (mha.azurewebsites.net)	Web gratuita	Visualización de la cadena Received con geolocalización
msgconvert + exiftool	CLI (Linux)	Parseo de archivos .msg y .eml para extracción de metadata
PhishTool	Plataforma SaaS	Análisis automatizado con scoring y extracción de IOCs

Verificación de autenticación

Herramienta	Qué verifica
dig TXT empresa.com	Registro SPF del dominio
dig TXT _dmarc.empresa.com	Política DMARC
dig TXT selector._domainkey.empresa.com	Clave pública DKIM
MXToolbox SuperTool	SPF, DKIM, DMARC, blacklists, MX, todo en uno
dmarcian.com	Análisis y monitorización DMARC con reportes agregados
DMARC Analyzer (EasyDMARC)	Visualización de reportes RUA/RUF

Investigación de IOCs extraídos

Herramienta	Para qué
VirusTotal	Reputación de IPs, dominios, hashes de adjuntos
URLScan.io	Análisis visual de URLs (screenshots, DOM, conexiones)
Shodan / Censys	Información del servidor de origen (puertos, servicios, certificados)
AbuseIPDB	Reportes de abuso de la IP de origen
dnstwist	Detección de dominios primo/lookalike
WHOIS (whois.domaintools.com)	Fecha de registro, registrant, nameservers del dominio sospechoso

Recursos y referencias

RFCs fundamentales:

• RFC 5321: protocolo SMTP
• RFC 7208: SPF (Sender Policy Framework)
• RFC 6376: DKIM (DomainKeys Identified Mail)
• RFC 7489: DMARC
• RFC 8601: Authentication-Results header

Guías de referencia:

• NIST SP 800-177 Rev. 1: Trustworthy Email
• CISA: Email Authentication Best Practices
• M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group): Best Practices

MITRE ATT&CK:

• T1566.001: Phishing: Spearphishing Attachment
• T1566.002: Phishing: Spearphishing Link
• T1566.003: Phishing: Spearphishing via Service
• T1534: Internal Spearphishing

Datasets de entrenamiento:

• Nazario phishing corpus (histórico, investigación académica)
• APWG eCrime reports (tendencias cuantitativos por trimestre)
• PhishTank (base de datos comunitaria de URLs de phishing verificadas)

La autenticación de email (SPF + DKIM + DMARC) es el mínimo necesario, no el máximo posible. Protege contra el spoofing directo de tu dominio, pero no contra las técnicas más sofisticadas: dominios primo, cuentas comprometidas o ataques que explotan la confianza entre organizaciones. El siguiente artículo de esta serie cubre las reglas Sigma y YARA específicas para detectar campañas de phishing en tu infraestructura.