Email security: SPF, DKIM, DMARC, header analysis y ataques BEC

El correo electrónico sigue siendo el vector de ataque número uno en entornos corporativos. Según el informe IC3 del FBI de 2023, los ataques de Business Email Compromise (BEC) provocaron pérdidas por más de 2.900 millones de dólares solo en Estados Unidos. Y el problema de fondo es simple: el protocolo SMTP, diseñado en 1982, no incluye ningún mecanismo de autenticación del remitente. Cualquiera puede enviar un email diciendo ser quien quiera.

Es la decimotercera lección de la Tanda 8. Aquí vas a entender cómo tres protocolos complementarios (SPF, DKIM y DMARC) intentan cerrar esa brecha, cómo analizar las cabeceras de un correo sospechoso para determinar si es legítimo, y qué técnicas emplean los atacantes en campañas BEC para saltarse esas protecciones. Todo con ejemplos reales de registros DNS, cabeceras y comandos que puedes reproducir.

Las técnicas de análisis de esta lección son para auditoría y defensa en entornos que controlas o tienes autorización para evaluar. Enviar correos suplantados sin permiso es ilegal en la mayoría de jurisdicciones. Practica solo en laboratorios propios o autorizados.

Cómo funciona el envío de un email#

Cuando envías un email, tu cliente de correo se conecta al servidor SMTP de tu dominio (por ejemplo, smtp.empresa.com). Ese servidor busca el registro MX del dominio destino mediante DNS, conecta al servidor receptor y le entrega el mensaje usando el protocolo SMTP. El problema es que en ningún momento del proceso original se verifica que el remitente sea realmente quien dice ser.

El flujo SMTP básico tiene cuatro pasos:

1. Cliente → SMTP emisor:  "Envía esto a [email protected]"
2. SMTP emisor → DNS:       "¿Cuál es el MX de destino.com?"
3. DNS → SMTP emisor:       "mx1.destino.com (prioridad 10)"
4. SMTP emisor → MX receptor: EHLO, MAIL FROM, RCPT TO, DATA

En el paso 4, el campo MAIL FROM del sobre SMTP (envelope sender) y el From: de las cabeceras del mensaje pueden ser completamente diferentes. Un atacante puede poner lo que quiera en ambos campos. SPF, DKIM y DMARC existen para resolver exactamente este problema.

SPF: quién puede enviar en tu nombre#

SPF (Sender Policy Framework, RFC 7208) permite al dueño de un dominio publicar en DNS una lista de IPs y servidores autorizados a enviar correo en su nombre. El servidor receptor consulta ese registro y compara la IP del servidor que le entregó el mensaje.

Un registro SPF es un TXT en la raíz del dominio:

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

Los mecanismos principales:

Los calificadores para all son:

La diferencia entre -all y ~all es crítica. Con ~all los correos de IPs no autorizadas llegan a spam pero no se rechazan. Con -all se rechazan directamente. La mayoría de organizaciones usa ~all al principio para no perder correo legítimo y migra a -all cuando tiene confianza en su configuración.

Puedes consultar el SPF de cualquier dominio:

dig TXT empresa.com +short
# o con nslookup
nslookup -type=TXT empresa.com

DKIM: firma criptográfica del mensaje#

DKIM (DomainKeys Identified Mail, RFC 6376) añade una firma digital a cada correo. El servidor emisor firma partes del mensaje (cabeceras seleccionadas y cuerpo) con su clave privada. El receptor recupera la clave pública desde DNS y verifica la firma.

El registro DNS de DKIM es un TXT en un subdominio con formato selector._domainkey.dominio:

s1._domainkey.empresa.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

Cada firma DKIM viaja en la cabecera DKIM-Signature del mensaje:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=empresa.com; s=s1; h=from:to:subject:date;
  bh=base64delHashDelCuerpo;
  b=base64delaFirma

Los campos clave de la firma:

DKIM garantiza dos cosas: que el mensaje no fue modificado en tránsito y que fue firmado por alguien con acceso a la clave privada del dominio. No impide que un atacante envíe correo sin firmar: para eso necesitas DMARC.

DMARC: la política que une SPF y DKIM#

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) une SPF y DKIM bajo una política que le dice al receptor qué hacer cuando ambos fallan. Además, añade un concepto fundamental: el alineamiento.

El alineamiento verifica que el dominio del From: visible (el que ve el usuario) coincida con el dominio verificado por SPF (envelope sender) o DKIM (campo d=). Sin alineamiento, un atacante podría pasar SPF con su propio dominio mientras muestra otro dominio en el From:.

Registro DMARC en DNS:

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

Las políticas:

Campos adicionales importantes: rua= recibe reportes agregados (XML diarios con estadísticas), ruf= recibe reportes forenses (detalle de cada fallo), pct= define el porcentaje de mensajes al que se aplica la política (útil para despliegues graduales), sp= define la política para subdominios.

La progresión recomendada para implementar DMARC:

Fase 1: p=none       → recoger reportes, identificar fuentes legítimas
Fase 2: p=quarantine → enviar a spam los fallos, verificar que nada legítimo se pierda
Fase 3: p=reject     → bloqueo total de correo no autenticado

Análisis de cabeceras#

Cuando recibes un email sospechoso, las cabeceras contienen toda la información necesaria para determinar si es legítimo. En Gmail puedes verlas con "Mostrar original"; en Outlook con "Ver origen del mensaje".

Las cabeceras más relevantes:

Return-Path: <[email protected]>
Received: from mail.empresa.com (203.0.113.10) by mx.destino.com
Authentication-Results: mx.destino.com;
  spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=empresa.com;
  dkim=pass header.d=empresa.com header.s=s1;
  dmarc=pass (p=reject) header.from=empresa.com
From: Director Financiero <[email protected]>
Reply-To: [email protected]

La cabecera Authentication-Results resume las verificaciones del servidor receptor. Un email legítimo muestra spf=pass, dkim=pass y dmarc=pass. Un email spoofed típicamente falla al menos uno.

La cadena de Received: se lee de abajo hacia arriba. Cada servidor que toca el mensaje añade una línea. Comparar las IPs de Received con los registros SPF revela si el servidor emisor estaba autorizado.

Señales de alarma:

BEC: Business Email Compromise#

BEC es la categoría de ataque donde el adversario suplanta a un ejecutivo, proveedor o empleado para manipular transferencias, datos o accesos. No siempre requiere spoofing técnico; muchas veces basta con registrar un dominio similar.

Técnicas comunes:

El patrón más frecuente: el atacante envía un email que parece venir del CEO pidiendo una transferencia urgente al departamento financiero. Urgencia, autoridad y cambio de cuenta son las tres señales clásicas.

Herramientas de análisis:

# Consultar registros SPF, DKIM, DMARC de un dominio
dig TXT empresa.com +short
dig TXT _dmarc.empresa.com +short
dig TXT s1._domainkey.empresa.com +short

# Verificar cabeceras con herramientas online (solo headers, nunca el cuerpo)
# Google Admin Toolbox: https://toolbox.googleapps.com/apps/messageheader/
# MXToolbox: https://mxtoolbox.com/EmailHeaders.aspx

Cómo se detecta un email fraudulento#

La detección combina verificación técnica y análisis del contenido:

Para análisis en la línea de comandos, puedes extraer las cabeceras de un archivo .eml:

# Extraer cabeceras de un archivo eml
sed '/^$/q' sospechoso.eml

# Buscar Authentication-Results
grep -i "authentication-results" sospechoso.eml

# Ver la cadena de Received
grep -i "^Received:" sospechoso.eml

Explotación paso a paso en un laboratorio#

En los laboratorios snort y orion-recon de whoami-labs puedes practicar reconocimiento de servicios y análisis de logs, habilidades que se aplican directamente a la investigación de correo fraudulento.

Paso 1: reconocimiento DNS del dominio objetivo#

# Comprobar si el dominio tiene SPF
dig TXT IP_DEL_LAB +short

# Comprobar DMARC
dig TXT _dmarc.IP_DEL_LAB +short

# Buscar registros MX
dig MX IP_DEL_LAB +short

Paso 2: analizar un email sospechoso#

# Si tienes el archivo .eml, ver cabeceras completas
cat email_sospechoso.eml | head -50

# Extraer la IP del servidor emisor
grep "Received:" email_sospechoso.eml | head -1

Paso 3: verificar la IP contra SPF#

# Obtener el SPF del dominio que dice el From
dig TXT dominio-del-from.com +short
# Resultado: "v=spf1 ip4:198.51.100.0/24 -all"

# Comparar con la IP de Received
# Si la IP no está en el rango, SPF falla → spoofing confirmado

Paso 4: buscar el dominio en fuentes de reputación#

# Consultar con curl (solo dominio, nunca datos sensibles en URL)
curl -s "https://www.virustotal.com/api/v3/domains/dominio-sospechoso.com" \
  -H "x-apikey: TU_API_KEY" | python3 -m json.tool

Qué puede lograr un atacante#

Cómo se configura correctamente#

Configuración vulnerable (sin protección):

; Sin SPF, sin DKIM, sin DMARC
; Cualquiera puede enviar como @empresa.com
empresa.com.  IN  MX  10 mx.empresa.com.

Configuración segura (protección completa):

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

; DKIM (clave pública del selector s1)
s1._domainkey.empresa.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

; DMARC con política de rechazo y reportes
_dmarc.empresa.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

Pasos para configurar desde cero:

1. Inventariar TODOS los servicios que envían email (app, marketing, soporte, alertas)
2. Publicar SPF con todas las IPs/includes necesarios
3. Configurar DKIM en el servidor de correo y publicar la clave pública
4. Publicar DMARC con p=none y rua= para recibir reportes
5. Analizar reportes durante 2-4 semanas
6. Corregir fuentes legítimas que fallen
7. Subir a p=quarantine, luego a p=reject

Errores comunes al defenderse#

• Dejar DMARC en p=none permanentemente: monitorizar sin actuar no protege de nada.
• SPF con ~all en vez de -all: los emails spoofed llegan a spam en vez de rechazarse.
• Olvidar incluir servicios externos en SPF: un sistema de tickets, un CRM o una plataforma de marketing que envía correo como tu dominio falla SPF si no está en include:.
• No rotar claves DKIM: las claves RSA de 1024 bits deberían migrarse a 2048 bits.
• Ignorar los reportes DMARC (rua): contienen información valiosa sobre intentos de spoofing.
• Confiar solo en SPF sin DKIM: SPF no sobrevive al reenvío de correo (forwarding). DKIM sí.
• No proteger subdominios: sin sp=reject en DMARC, un atacante puede spoofear rrhh.empresa.com.

Preguntas frecuentes#

SPF falla cuando reenvío un email, eso es normal?#

Sí. Cuando reenvías un email, el servidor de reenvío usa su propia IP pero mantiene el envelope sender original. La IP del reenviador no está en el SPF del dominio original, así que falla. Por eso DKIM es importante: la firma sobrevive al reenvío porque está en las cabeceras del mensaje, no depende de la IP.

Puedo tener SPF sin DMARC?#

Puedes, pero pierdes el alineamiento y la capacidad de recibir reportes. Sin DMARC, el receptor decide por su cuenta qué hacer con un fallo de SPF. Con DMARC, tú defines la política.

Qué pasa si tengo dos registros SPF en el mismo dominio?#

Solo se permite un registro SPF por dominio (RFC 7208). Si hay dos, el resultado es permerror y la verificación falla completamente. Es un error de configuración frecuente al añadir servicios externos.

Cómo analizo los reportes DMARC?#

Los reportes rua llegan como XML comprimido en gzip o zip. Herramientas como DMARC Analyzer, Postmark DMARC, Valimail o dmarcian los parsean y presentan gráficos con las fuentes de correo, tasas de fallo y IPs no autorizadas.

Puedo protegerme de dominios lookalike?#

No completamente con SPF/DKIM/DMARC, porque esos protocolos protegen tu propio dominio, no controlan lo que otros registren. Para dominios lookalike: registra variantes comunes tú mismo, monitoriza con servicios como dnstwist o PhishTank, y forma a los empleados para que verifiquen el dominio real letra a letra.

BEC siempre implica spoofing técnico?#

No. Muchos ataques BEC usan compromiso de cuenta real (obtienen la contraseña del ejecutivo) o dominios lookalike que pasan todas las verificaciones SPF/DKIM/DMARC de su propio dominio. La autenticación de email protege contra spoofing directo, pero no contra un atacante que opera desde una cuenta legítima comprometida.

Resumen#

• SMTP no autentica al remitente: SPF, DKIM y DMARC cierran esa brecha.
• SPF define qué IPs pueden enviar en nombre del dominio; DKIM firma criptográficamente el mensaje; DMARC une ambos con una política y reportes.
• Las cabeceras Authentication-Results y la cadena Received: son las fuentes primarias para analizar un correo sospechoso.
• Los ataques BEC combinan suplantación técnica con ingeniería social y causan pérdidas millonarias.
• La configuración correcta sigue una progresión: p=none para monitorizar, p=quarantine para probar, p=reject para proteger.
• Ni SPF, ni DKIM, ni DMARC protegen contra compromiso de cuenta real o dominios lookalike: la formación del usuario sigue siendo esencial.

Fuentes y lecturas recomendadas#

• RFC 7208 — Sender Policy Framework (SPF)
• RFC 6376 — DomainKeys Identified Mail (DKIM)
• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• MITRE ATT&CK T1566 — Phishing
• FBI IC3 — Internet Crime Report
• Google Workspace — Cómo configurar SPF, DKIM y DMARC
• dnstwist — Detección de dominios lookalike