SPF/DKIM/DMARC

SPF/DKIM/DMARC

La mayoría de las organizaciones no publica una política DMARC de rechazo (p=reject) —a escala mundial solo en torno al 4 % la aplica—, y eso deja sus dominios expuestos a la suplantación de identidad por correo. El phishing que suplanta a la Agencia Tributaria existe y está documentado por INCIBE; ahora bien, la propia AEAT sí publica p=reject, de modo que un correo que finja venir de su dominio no supera la alineación y los grandes proveedores (Gmail, Outlook) pueden rechazarlo antes de que llegue a la víctima. Este glosario explica cómo funcionan SPF, DKIM y DMARC y cómo se analizan en la pericia de un correo.

Definición Técnica

SPF/DKIM/DMARC son tres protocolos autenticación email complementarios que trabajan juntos para verificar legitimidad del remitente y prevenir suplantación de identidad (spoofing) mediante validación técnica de servidores autorizados, firmas criptográficas y políticas de rechazo.

SPF (Sender Policy Framework):

• Qué hace: Lista servidores IP autorizados para enviar email desde un dominio
• Cómo funciona: Registro DNS TXT con IPs permitidas
• Válida: “¿Este servidor está autorizado enviar email @example.com?”
• Resultado: PASS (autorizado), FAIL (no autorizado), SOFTFAIL (sospechoso)

DKIM (DomainKeys Identified Mail):

• Qué hace: Firma criptográfica digital en cada email enviado
• Cómo funciona: Clave privada (servidor) firma mensaje, clave pública (DNS) verifica
• Válida: “¿Este email fue modificado en tránsito?”
• Resultado: PASS (firma válida), FAIL (firma inválida/ausente)

DMARC (Domain-based Message Authentication, Reporting & Conformance):

• Qué hace: Política de qué hacer si SPF/DKIM fallan
• Cómo funciona: Registro DNS TXT con reglas rechazo/cuarentena
• Válida: “¿Qué hacer con emails que fallan SPF y DKIM?”
• Resultado: none (solo monitorizar), quarantine (carpeta spam), reject (rechazar)

Por qué importan juntos:

SPF solo: Valida IP servidor, NO contenido mensaje
DKIM solo: Valida integridad mensaje, NO dominio remitente visible
DMARC: combina SPF y DKIM con alineación y una política solicitada.
       No es «protección completa»: reduce mucho la suplantación
       del propio dominio, pero no impide dominios parecidos ni
       obliga al receptor a rechazar

Adopción de DMARC en el mundo:

• En el segundo trimestre de 2025, el 18,2 % de los diez millones de dominios más populares tenía un registro DMARC válido, y el 3,9 % política de rechazo también en subdominios (Fortra). No son «todos los dominios del mundo» ni datos de 2026.
• Un análisis publicado en 2023 encontró que el 41 % de una muestra de entidades bancarias no tenía protección DMARC. No es un censo actual.
• Coste medio de una brecha iniciada por phishing: 4,88 millones de dólares (no euros), según IBM: «Breaches caused by phishing cost organizations an average of USD 4.88 million» (URL de marca: sirve siempre la última edición —hoy la de 2026—, no la que declara este texto.)

Marco legal:

• RGPD: Art. 32 (medidas seguridad técnicas apropiadas)
• Directiva NIS2 (UE): el art. 21.1 exige medidas «adecuadas y proporcionadas» y menciona la autenticación multifactorial o continua «cuando proceda». No impone nominalmente SPF, DKIM ni DMARC.
• Sobre la responsabilidad: ni una brecha ni la ausencia de estos tres controles generan por sí solas negligencia o responsabilidad civil. El art. 32 del RGPD manda ponderar riesgos de «probabilidad y gravedad variables», y eso es un juicio de caso.

Cómo funcionan SPF, DKIM y DMARC: autenticación email técnica

SPF (Sender Policy Framework)

Registro DNS SPF:

example.com.  IN  TXT  "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 include:_spf.google.com -all"

Desglose:
  v=spf1             → Versión SPF 1
  ip4:192.0.2.0/24   → Rango IPs autorizadas (192.0.2.0 - 192.0.2.255)
  ip4:198.51.100.123 → IP específica autorizada
  include:_spf.google.com → Incluir IPs autorizadas Google (Gmail business)
  -all               → Política FAIL (rechazar resto IPs)

Alternativas -all:
  ~all  → SOFTFAIL (marcar sospechoso, no rechazar)
  ?all  → NEUTRAL (no validar)
  +all  → PASS (permitir todo) ⚠️ INSEGURO

Flujo validación SPF:

1. Remitente envía email:
   From: contacto@example.com
   SMTP servidor: 192.0.2.50

2. Servidor destino (Gmail, Outlook) recibe email:
   - Extrae el dominio del MAIL FROM del sobre (o del HELO
     cuando procede): es la identidad que SPF evalúa, NO el
     dominio visible de la cabecera From
   - Extrae IP servidor origen: 192.0.2.50
   (Es DMARC, después, quien compara el identificador SPF
    autenticado con el dominio del From visible)

3. Query DNS SPF:
   $ dig TXT example.com
   "v=spf1 ip4:192.0.2.0/24 -all"

4. Validación:
   ¿192.0.2.50 está en rango 192.0.2.0/24? → SÍ
   Resultado: SPF PASS ✅

5. Si IP fuera 203.0.113.45 (no autorizada):
   ¿203.0.113.45 está en rango 192.0.2.0/24? → NO
   Política -all → SPF FAIL ❌
   Acción: Rechazar o marcar spam

Análisis forense SPF email phishing:

Email phishing suplantando banco BBVA:

Headers email:
  From: seguridad@bbva.com (FALSO - spoofed)
  Return-Path: <phishing@offshore-server.ru>
  Received: from mail.offshore-server.ru [203.0.113.45]

Validación SPF:
  1. Dominio visible: bbva.com
  2. IP del servidor de origen (en los ejemplos de esta página
     se usa 203.0.113.45, del bloque TEST-NET-3 que la RFC 5737
     reserva para documentación: NO identifica ningún país
     ni operador real)

  3. Query DNS SPF del dominio suplantado:
     $ dig TXT <dominio>
     (Los registros SPF cambian: consúltalos en el momento del
      análisis y guarda la salida fechada. Las que aparecían aquí
      no corresponden al DNS actual y no llevaban captura ni fecha)

  4. ¿203.0.113.45 está en rangos autorizados BBVA? → NO

  Resultado: SPF FAIL ❌
  Conclusión: Email NO enviado desde servidores autorizados BBVA
  Evidencia: Phishing demostrado técnicamente

DKIM (DomainKeys Identified Mail)

Registro DNS DKIM (clave pública):

default._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3..."

Desglose:
  v=DKIM1     → Versión DKIM 1
  k=rsa       → Algoritmo criptográfico RSA
  p=MIG...    → Clave pública RSA (Base64) para verificar firma

Firma DKIM en email (header):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=default;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGkwf8...

Desglose:
  v=1                  → Versión DKIM
  a=rsa-sha256         → Algoritmo firma (RSA + SHA256 hash)
  d=example.com        → Dominio firmante
  s=default            → Selector (identifica clave pública DNS)
  h=from:to:subject... → Headers incluidos en firma
  bh=2jUSO...          → Hash cuerpo mensaje (body hash)
  b=dzdVy...           → Firma digital completa (RSA signature)

Proceso firma y verificación DKIM:

ENVÍO (servidor remitente example.com):
  1. Servidor genera hash SHA256 cuerpo email → bh=2jUSO...
  2. Servidor genera hash headers seleccionados → h=from:to:subject...
  3. Servidor firma hash con clave PRIVADA RSA → b=dzdVy...
  4. Añade header DKIM-Signature al email
  5. Envía email

RECEPCIÓN (servidor destino Gmail):
  1. Extrae header DKIM-Signature
  2. Identifica dominio (d=example.com) y selector (s=default)
  3. Query DNS clave pública:
     $ dig TXT default._domainkey.example.com
     p=MIGfMA0GCS... (clave pública RSA)

  4. Recalcula hash cuerpo email actual → bh'
  5. Compara bh (firma) vs bh' (recalculado):
     ¿bh == bh'? → SÍ = cuerpo NO modificado ✅

  6. Verifica firma digital b con clave pública:
     RSA_verify(b, p) → VÁLIDA ✅

  Resultado: DKIM PASS ✅
  Conclusión: la firma cubre el cuerpo hasta la longitud firmada
  y los campos enumerados en h=. No acredita que el objeto
  entero llegara sin modificar: el tag l= puede dejar parte del
  cuerpo fuera, y con l=0 queda sin firmar por completo

Análisis forense DKIM email phishing:

Email phishing AEAT (Agencia Tributaria):

Headers:
  From: notificaciones@agenciatributaria.gob.es (FALSO)
  DKIM-Signature: v=1; a=rsa-sha256; d=phishing-domain.tk; ...

Validación DKIM:
  1. Dominio firmante DKIM: phishing-domain.tk (NO agenciatributaria.gob.es)
  2. Query DNS phishing-domain.tk:
     - Clave pública existe
     - Firma VÁLIDA para phishing-domain.tk

  Problema: DKIM PASS para phishing-domain.tk
  PERO dominio visible (From) es agenciatributaria.gob.es (diferente)

  Resultado: DKIM alignment FAIL ❌
  Conclusión: Email firmado por dominio diferente (suplantación)

  ⚠️ DKIM solo NO protege contra spoofing (necesita DMARC alignment)

DMARC (Domain-based Message Authentication)

Registro DNS DMARC:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=s"

Desglose:
  v=DMARC1         → Versión DMARC
  p=reject         → Política si FAIL: reject (rechazar), quarantine (spam), none (monitorizar)
  rua=mailto:...   → Email recibir reportes agregados (diarios)
  ruf=mailto:...   → Dirección para informes por mensaje. NO se
                     recibe uno por cada fallo: el receptor «MAY
                     choose», y muchos no los envían por privacidad
  pct=             → ELIMINADO por el RFC 9989 (apéndice A.6).
                     No usarlo en despliegues nuevos
  adkim=s          → DKIM alignment: s (strict), r (relaxed)
  aspf=s           → SPF alignment: s (strict), r (relaxed)

Políticas DMARC:
  p=none       → Solo monitorizar (enviar reportes, NO rechazar)
  p=quarantine → Marcar spam si falla SPF/DKIM
  p=reject     → RECHAZAR si falla SPF/DKIM (máxima protección)

DMARC Alignment (alineación dominios):

DMARC valida que dominio visible (From header) COINCIDA con:
  - Dominio SPF (Return-Path)
  - Dominio DKIM (d= firma)

Ejemplo LEGÍTIMO:
  From: contacto@example.com
  Return-Path: <bounce@example.com>
  DKIM d=example.com

  SPF alignment: example.com == example.com ✅
  DKIM alignment: example.com == example.com ✅
  DMARC: PASS ✅

Ejemplo PHISHING:
  From: seguridad@bbva.com (FALSO)
  Return-Path: <phishing@offshore-server.ru>
  DKIM d=offshore-server.ru

  SPF alignment: bbva.com != offshore-server.ru ❌
  DKIM alignment: bbva.com != offshore-server.ru ❌
  DMARC: FAIL ❌

  Política DMARC bbva.com: p=reject
  Acción típica del receptor: rechazar antes de la entrega —aunque
  el RFC 9989 le prohíbe hacerlo SOLO por la política publicada,
  así que la decisión final es suya

Flujo completo SPF + DKIM + DMARC:

Email recibido:
  From: contacto@example.com
  Servidor origen: 192.0.2.50
  DKIM firma: d=example.com, b=dzdVy...

Gmail/Outlook validación:

  1. Validación SPF:
     ¿192.0.2.50 autorizada para example.com? → Consulta DNS SPF
     Resultado: SPF PASS ✅

  2. Validación DKIM:
     ¿Firma DKIM válida? → Consulta DNS clave pública + verifica firma
     Resultado: DKIM PASS ✅

  3. Validación DMARC:
     Query DNS _dmarc.example.com → p=reject

     ¿SPF alignment OK? example.com == example.com ✅
     ¿DKIM alignment OK? example.com == example.com ✅
     Resultado: DMARC PASS ✅

  Decisión final: Email LEGÍTIMO → Bandeja entrada

Si NINGUNO de los dos pasa alineado con el dominio del From:
  (basta con que UNO de ellos pase y esté alineado para que
   DMARC pase; no hacen falta los dos)
  4. DMARC política solicitada: p=reject
  Decisión del receptor: normalmente rechazar, pero el RFC 9989
  prohíbe hacerlo SOLO por la política: manda su política local
  Enviar reporte DMARC a rua=dmarc-reports@example.com

Análisis forense email phishing: SPF/DKIM/DMARC como evidencias

Escenario 1: análisis de una campaña que suplanta a la AEAT

Contexto: campaña de phishing que suplanta a la Agencia Tributaria

Email fraudulento recibido:

From: notificaciones@agenciatributaria.gob.es
Subject: Devolución IRPF 2025 pendiente - €1,247 a su favor
Date: Mon, 5 Feb 2026 09:15:32 +0100

Estimado contribuyente,

Su declaración IRPF 2025 ha sido revisada. Importe devolución: €1,247

Confirme datos bancarios para transferencia:
https://aeat-devolucion[.]info/irpf2025

Plazo 72h o devolución cancelada.

Agencia Estatal de Administración Tributaria

Análisis headers email:

Return-Path: <campaign@bulk-sender.tk>
Received: from mail.bulk-sender.tk ([203.0.113.45])
  by mx.google.com with ESMTPS
From: notificaciones@agenciatributaria.gob.es
DKIM-Signature: v=1; a=rsa-sha256; d=bulk-sender.tk; s=default; ...

Validación SPF:

## Query SPF Agencia Tributaria
$ dig TXT agenciatributaria.gob.es

agenciatributaria.gob.es. IN TXT "v=spf1 ip4:195.77.198.96/32
                                  ip4:195.77.198.97/32 -all"

(Consulta de 3 de septiembre de 2026. Los rangos que figuraban
 antes aquí —195.55.0.0/16 y 217.126.0.0/16— no corresponden al
 DNS real y no llevaban fecha ni captura.)

## Validación:
Email enviado desde: 203.0.113.45 (bulk-sender.tk)
¿203.0.113.45 está en rangos autorizados AEAT?
  195.55.0.0/16 → NO
  217.126.0.0/16 → NO

Resultado: SPF FAIL ❌
Conclusión: Servidor NO autorizado por AEAT

Validación DKIM:

## DKIM signature en email:
DKIM-Signature: d=bulk-sender.tk; s=default; ...

## Query clave pública
$ dig TXT default._domainkey.bulk-sender.tk
"v=DKIM1; k=rsa; p=MIGfMA0..."

## Verificación firma:
Firma DKIM: VÁLIDA para bulk-sender.tk ✅

PERO:
  Dominio From visible: agenciatributaria.gob.es
  Dominio DKIM firmante: bulk-sender.tk

Alignment: agenciatributaria.gob.es != bulk-sender.tk ❌
Resultado: DKIM alignment FAIL ❌

Validación DMARC:

## Query DMARC AEAT
$ dig TXT _dmarc.agenciatributaria.gob.es

RESULTADO (consulta de 3 de septiembre de 2026):
"v=DMARC1; p=reject; fo=1; ri=3600;
 rua=mailto:informesdmarc@correo.aeat.es;
 ruf=mailto:informesdmarc@correo.aeat.es"

La AEAT SÍ publica DMARC con política de rechazo, de modo que un
correo que falsee su dominio exacto no supera la alineación.

Lo que una política p=reject NO garantiza:
  - El RFC 9989 prohíbe rechazar SOLO por p=reject; el receptor
    aplica además su política local
  - Un dominio parecido pero distinto (aeat-algo.info) no está
    cubierto por el DMARC de agenciatributaria.gob.es

Ante un correo que falsee el dominio exacto agenciatributaria.gob.es:
  1. Gmail detecta SPF FAIL + DKIM alignment FAIL
  2. Consulta la política DMARC → p=reject
  3. Rechaza el correo antes de la entrega
  4. La víctima no llega a ver ese correo
Por eso el fraude real no falsea el dominio exacto, sino dominios
parecidos (aeat-algo.info) que el DMARC de la AEAT no cubre.

Peritaje forense evidencias:

Informe pericial incluye:

1. Headers email completos (raw)
2. Análisis SPF:
   - Registro SPF AEAT (DNS query captura)
   - IP servidor origen (203.0.113.45)
   - Conclusión: SPF FAIL (servidor no autorizado)

3. Análisis DKIM:
   - Firma DKIM (d=bulk-sender.tk)
   - Dominio From (agenciatributaria.gob.es)
   - Conclusión: Alignment FAIL (dominios diferentes)

4. Análisis DMARC:
   - Query DNS _dmarc.agenciatributaria.gob.es
   - Resultado: v=DMARC1; p=reject (política de rechazo publicada)
   - Conclusión: el dominio suplantado SÍ tiene DMARC en rechazo; el
     correo falso no supera la alineación con agenciatributaria.gob.es

5. Evidencia phishing (ilustrativa):
   - URL fraudulenta del cuerpo del correo, preservada con su hash
   - WHOIS del dominio, consultado y fechado: un registro reciente es
     un indicio, no una prueba de autoría
   - IP y alojamiento, documentados con la consulta conservada; una IP
     de CDN o proxy no acredita la ubicación real del servidor

Qué sostiene el análisis, y qué no:
  ✓ Los resultados de autenticación son indicios técnicos de que
    el correo no salió de la infraestructura del dominio suplantado
  ✗ No prueban por sí solos la autoría ni cierran la valoración:
    el art. 326.2 LEC remite a la sana crítica del tribunal
  ✗ Y no cabe imputar negligencia a la AEAT por falta de DMARC,
    porque sí lo tiene configurado con p=reject

Escenario 2: BEC (Business Email Compromise)

Contexto: un atacante suplanta al CEO y solicita una transferencia urgente

Email fraudulento:

From: carlos.ruiz@example-corp.com (CEO real)
To: finanzas@example-corp.com
Subject: RE: Transferencia urgente - Operación China

María,

Necesito transferencia urgente €120,000 a proveedor China.
Operación confidencial, board aprobó ayer.

IBAN: ES76 0081 XXXX XXXX XXXX XXXX (cuenta mula)
Beneficiario: Shanghai Trading Ltd
Concepto: Anticipo materias primas Q1

Ejecutar antes 16:00h hoy. Llamaré mañana, ahora reunión.

Carlos Ruiz, CEO

Análisis headers:

Return-Path: <carlos.ruiz@examp1e-corp.com> ← ⚠️ Typosquatting (1 en lugar de l)
Received: from mail.examp1e-corp.com ([203.0.113.45])
From: carlos.ruiz@example-corp.com (spoofed)

Validación SPF:

## Query SPF empresa real
$ dig TXT example-corp.com
"v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all"

## Validación:
Email enviado desde: 203.0.113.45 (examp1e-corp.com typosquatting)
¿203.0.113.45 autorizada para example-corp.com? → NO

Resultado: SPF FAIL ❌

Validación DKIM:

## DKIM ausente en email fraudulento
No header DKIM-Signature encontrado

Resultado: DKIM FAIL ❌ (no firmado)

Validación DMARC:

## Query DMARC empresa real
$ dig TXT _dmarc.example-corp.com

⚠️ RESULTADO: "v=DMARC1; p=none; rua=mailto:dmarc@example-corp.com"

Problema:
  - DMARC configurado PERO política p=none (solo monitorizar)
  - NO rechaza emails que fallan SPF/DKIM
  - Email llega bandeja entrada

Gmail valida:
  SPF FAIL ❌ + DKIM FAIL ❌
  Consulta DMARC → p=none (no hacer nada)
  Acción: Entregar email (solo añade warning sutil)

Consecuencia:
  - Empleada finanzas NO ve alerta clara
  - Confía en remitente (parece CEO)
  - Ejecuta transferencia €120,000
  - Descubre fraude 24h después (irrecuperable)

Si DMARC fuera p=reject:
  Gmail rechaza email automáticamente
  Empleada NO ve email fraudulento
  Fraude: EVITADO

Herramientas verificación SPF/DKIM/DMARC

MXToolbox (mxtoolbox.com)

Checks disponibles:

SPF Record Lookup:
  URL: https://mxtoolbox.com/spf.aspx
  Input: example.com
  Output:
    - Registro SPF encontrado: v=spf1 ip4:192.0.2.0/24 -all
    - IPs autorizadas listadas
    - Errores sintaxis (si existen)
    - Warnings (ej: más de 10 DNS lookups)

DKIM Record Lookup:
  URL: https://mxtoolbox.com/dkim.aspx
  Input: Dominio + selector (ej: default._domainkey.example.com)
  Output:
    - Clave pública RSA
    - Algoritmo (rsa, ed25519)
    - Validez registro

DMARC Record Lookup:
  URL: https://mxtoolbox.com/dmarc.aspx
  Input: example.com
  Output:
    - Política DMARC (none, quarantine, reject)
    - Alineación (strict, relaxed)
    - Emails reportes (rua, ruf)
    - Score seguridad (0-100)

Email Headers Analyzer:
  URL: https://mxtoolbox.com/emailheaders.aspx
  Input: Headers email completos (raw)
  Output:
    - Resultado SPF (PASS/FAIL)
    - Resultado DKIM (PASS/FAIL)
    - Resultado DMARC (PASS/FAIL)
    - Ruta email (servidores intermedios)

dmarcian (dmarcian.com)

Análisis DMARC avanzado:

DMARC Inspector:
  URL: https://dmarcian.com/dmarc-inspector/
  Funciones:
    - Validación sintaxis DMARC
    - Recomendaciones mejora política
    - Simulación enforcement (qué pasaría con p=reject)

DMARC Reports Analyzer:
  - Procesa reportes XML DMARC (rua)
  - Dashboard visual: fuentes email legítimas vs fraudulentas
  - Identifica servidores no autorizados enviando email tu dominio
  - Recomendaciones SPF/DKIM fixes

Ejemplo dashboard:
  ┌────────────────────────────────────────┐
  │ MAQUETA de panel DMARC (datos inventados) │
  ├────────────────────────────────────────┤
  │ Total emails: 847,293 (últimos 7 días) │
  │                                        │
  │ ✅ DMARC PASS: 98.2% (831,842)         │
  │ ❌ DMARC FAIL:  1.8% (15,451)          │
  │                                        │
  │ Top failures (IP sources):             │
  │   - 203.0.113.45 (documentación, RFC 5737): 8,200 │
  │   - 203.0.113.90 (sin identificar): 4,100 │
  │   - 198.51.100.200 (MailChimp): 3,151  │
  │     ↳ Fix: Añadir include:servers.     │
  │             mcsv.net al SPF            │
  └────────────────────────────────────────┘

Google Admin Toolbox (toolbox.googleapps.com)

Messageheader (Google):

URL: https://toolbox.googleapps.com/apps/messageheader/

Función: Analiza headers email Gmail

Output:
  - SPF resultado + IP origen
  - DKIM resultado + firma verificada
  - DMARC resultado + política aplicada
  - Delays entrega (latencia servidores)
  - Ruta completa email (hops)

Ideal para:
  - Debugging entregas Gmail
  - Análisis phishing recibido Gmail
  - Verificar configuración SPF/DKIM propia

Implementación SPF/DKIM/DMARC: guía configuración

Paso 1: Configurar SPF

1.1 Identificar servidores email:

Pregunta clave: ¿Qué servidores envían email tu dominio?

Fuentes comunes:
  - Servidor web propio (IP servidor)
  - Google Workspace (include:_spf.google.com)
  - Microsoft 365 (include:spf.protection.outlook.com)
  - Mailchimp (include:servers.mcsv.net)
  - Zendesk (include:mail.zendesk.com)

1.2 Crear registro SPF DNS:

example.com.  IN  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:servers.mcsv.net -all"

Explicación:
  ip4:192.0.2.0/24           → Servidor web propio
  include:_spf.google.com    → Google Workspace
  include:servers.mcsv.net   → Mailchimp
  -all                       → Rechazar resto (recomendado)

⚠️ Límite: Máximo 10 DNS lookups (includes cuentan)

1.3 Validar SPF:

## Verificar registro publicado
$ dig TXT example.com

## Validar sintaxis
https://mxtoolbox.com/spf.aspx

## Enviar email prueba y revisar headers

Paso 2: Configurar DKIM

2.1 Generar par claves (servidor email):

## Ejemplo: OpenDKIM (Linux)
$ opendkim-genkey -s default -d example.com

Genera:
  - default.private (clave PRIVADA, guardar secreto)
  - default.txt (clave PÚBLICA, publicar DNS)

2.2 Publicar clave pública DNS:

default._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU..."

Nombre registro: default._domainkey.example.com
  - "default" = selector (identificador clave, puedes usar cualquier nombre)
  - "_domainkey" = estándar DKIM

2.3 Configurar servidor email firmar:

Google Workspace:
  Admin console → Apps → Google Workspace → Gmail
  → Authenticate email → Generate new record
  → Copiar registro DKIM a DNS

Microsoft 365:
  Admin center → Exchange → Protection → DKIM
  → Enable DKIM signing for domain
  → Añadir registros DNS indicados

2.4 Validar DKIM:

## Verificar registro DNS
$ dig TXT default._domainkey.example.com

## Enviar email prueba y validar firma
https://mxtoolbox.com/dkim.aspx

Paso 3: Configurar DMARC

3.1 Fase 1 - Monitorización (p=none):

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Explicación:
  p=none                            → Solo monitorizar (no rechazar)
  rua=mailto:dmarc-reports@...      → Email recibir reportes diarios

Duración fase 1: 2-4 semanas (monitorizar)

3.2 Analizar reportes DMARC:

Usar: dmarcian.com o parsedmarc (Python)

Identificar:
  - Fuentes legítimas email (autorizadas)
  - Fuentes fraudulentas (no autorizadas)
  - Servidores propios faltantes en SPF (fix antes p=reject)

3.3 Fase 2 - Cuarentena (p=quarantine):

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Explicación:
  p=quarantine                      → Marcar spam si falla
  adkim=r, aspf=r                   → Alignment relaxed (menos estricto)

Duración fase 2: 2-4 semanas adicionales

3.4 Fase 3 - Rechazo (p=reject) ✅:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=s"

Explicación:
  p=reject                          → RECHAZAR si falla (máxima protección)
  ruf=mailto:dmarc-forensic@...     → Reportes forenses (cada fallo)
  adkim=s, aspf=s                   → Alignment strict (máxima seguridad)

✅ LOS TRES MECANISMOS ACTIVOS Y ALINEADOS

3.5 Validar DMARC:

## Verificar registro
$ dig TXT _dmarc.example.com

## Validar sintaxis
https://mxtoolbox.com/dmarc.aspx

## Enviar email prueba externo (spoof) y verificar rechazo

Limitaciones y casos edge

Forwarding Email (Reenvío)

Problema:

Usuario A (Gmail) reenvía email a Usuario B (Outlook):
  Email original:
    From: contacto@example.com
    SPF: PASS (enviado desde servidor example.com autorizado)

  Gmail reenvía:
    From: contacto@example.com (sin cambiar)
    Servidor origen: Gmail servers (NO example.com)

  Outlook valida:
    SPF: ¿Gmail autorizado para example.com? → NO → SPF FAIL
    DMARC example.com: p=reject
    Acción: RECHAZAR email (legítimo pero reenviado)

Solución:
  1. SRS (Sender Rewriting Scheme): reescribe el MAIL FROM del
     sobre, no la cabecera From visible
  2. ARC (Authenticated Received Chain): Preserva autenticación original
  3. Configuración DMARC: aspf=r (relaxed, más permisivo)

Listas Distribución (Mailing Lists)

Problema similar forwarding:

Email enviado lista Mailman:
  - Lista modifica Subject (añade [Lista])
  - DKIM rompe (contenido modificado)
  - SPF falla (servidor lista != dominio original)

Solución:
  - Lista reescribe From: lista@ejemplo.com
  - O usa DMARC p=none para listas conocidas

Subdominios

DMARC subdomains:

Registro DMARC padre:
  _dmarc.example.com → p=reject

Subdomain sin DMARC propio:
  newsletter.example.com → ¿Qué política?

Comportamiento:
  - Subdomain HEREDA política padre (p=reject)
  - O publica propio: _dmarc.newsletter.example.com → p=none

Recomendación:
  - Política padre conservadora (p=quarantine)
  - Subdomains activos: políticas específicas
  - Subdomains no usados: p=reject

FAQ

P: ¿SPF/DKIM/DMARC previenen 100% phishing? R: NO. Previenen suplantación DOMINIO (email from spoofing) pero NO: 1) Phishing dominios similares (examp1e.com vs example.com), 2) Phishing texto email (URLs maliciosas), 3) Archivos adjuntos malware. Son CAPA crítica, NO solución completa.

P: ¿Puedo tener solo SPF sin DKIM/DMARC? R: Técnicamente SÍ, PERO protección limitada. SPF solo válida IP servidor, NO contenido ni dominio visible. Atacante puede enviar desde servidor autorizado dominio diferente. DMARC (que requiere SPF o DKIM) es necesario enforcement real.

P: ¿DMARC p=reject puede bloquear emails legítimos? R: SÍ si configuración incorrecta. Por eso implementar gradual: 1) p=none (2-4 semanas), 2) Analizar reportes, 3) Fijar SPF/DKIM fuentes legítimas, 4) p=quarantine (2-4 semanas), 5) p=reject. Monitorizar reportes continuamente.

P: ¿Cómo saber si dominio tiene DMARC configurado? R: Query DNS: dig TXT _dmarc.example.com o herramienta web MXToolbox. Si devuelve NXDOMAIN significa que no hay registro en ese nombre exacto, no que no haya política aplicable: el algoritmo vigente del RFC 9989 hace un recorrido ascendente («Tree Walk») y puede acabar aplicando la política del dominio organizativo. Si devuelve registro TXT con v=DMARC1 = configurado (revisar política p=).

P: ¿Perito informático puede usar SPF/DKIM/DMARC como evidencia judicial? R: son un indicio técnico valioso, no una prueba automática. Un correo legítimo puede fallar SPF por un reenvío, y un atacante puede superar la autenticación con un dominio propio. La LEC admite los instrumentos electrónicos, pero su valor lo fija el tribunal «conforme a las reglas de la sana crítica» (art. 326.2). Lo que sostiene el informe es la preservación y el contexto, no los tres resultados por sí solos. Informe pericial debe incluir: 1) Headers raw email, 2) Query DNS SPF/DKIM/DMARC (captura), 3) Análisis validación, 4) Conclusión legitimidad. Admisible juicio.

Referencias y Fuentes

1. PowerDMARC. (2026). “Email Phishing And DMARC Statistics: 2026 Security Trends”. powerdmarc.com

   • Only 18% world’s 10M domains publish valid DMARC, just 4% enforce reject policy
   • 41% banking institutions lack DMARC protection

2. SkyNet Hosting. (2026). “SPF DKIM DMARC Explained 2026: Complete Email Authentication Setup Guide”. skynethosting.net

   • In 2026, major inbox providers increasingly require authenticated email

3. Muy Seguridad. (2026). “Guardia Civil alerta phishing AEAT: estafa masiva 2026”. muyseguridad.net

   • Large-scale phishing campaign impersonating Spanish Tax Agency (AEAT)

4. INCIBE. (2025). “Actúa con precaución ante supuesta notificación Agencia Tributaria - phishing y smishing”. incibe.es

   • Official INCIBE alerts about AEAT phishing campaigns

5. Cloudflare. (2025). “What are DMARC, DKIM, and SPF?”. cloudflare.com

   • Technical explanation how SPF, DKIM, DMARC work together

6. DMARCLY. (2024). “How to Implement DMARC/DKIM/SPF to Stop Email Spoofing/Phishing: The Definitive Guide”. dmarcly.com

   • Comprehensive implementation guide for email authentication

7. PowerDMARC. (2026). “Email Security Predictions 2026: What To Expect”. powerdmarc.com

   • Email security trends: AI-driven phishing, stricter DMARC rules

8. Guardian Digital. (2025). “SPF DKIM DMARC: Protecting Your Inbox from Email Spoofing Threats”. guardiandigital.com

   • How authentication protocols secure email against sender fraud

9. EasyDMARC. (2025). “Stop Email Phishing with DMARC, DKIM, and SPF”. easydmarc.com

   • Practical guide implementing email authentication to prevent phishing

10. Nightingale, J. (2017). Email Authentication Mechanisms: DMARC, SPF and DKIM, NIST TN 1945 — publicado el 16 de febrero de 2017; la actualización web de 2018 no lo convierte en obra de 2023.

    • Official NIST technical documentation on email authentication standards

Última actualización: 9 de septiembre de 2026 Categoría: Análisis (ANA-008) Nivel técnico: Avanzado Relevancia forense: ALTA (evidencia técnica phishing, análisis headers email) Adopción mundial: ~18 % dominios con DMARC válido, ~4 % con p=reject (Q2 2025)