SPF, DKIM y DMARC:

cómo se autentica el correo y por qué aún te cuelan phishing

Correo y seguridad web  |  unfantasmaenelsistema.com

El correo electrónico se diseñó en los años 80 para una red pequeña donde todos los servidores se conocían y nadie mentía. De aquella época heredamos un problema que seguimos pagando: el protocolo SMTP no comprueba quién envía un mensaje. Cualquier servidor puede afirmar «esto viene de tu-banco.es» y, por defecto, el correo se entrega igual. Sobre ese agujero se construye buena parte del phishing, el fraude del CEO y la suplantación de marcas.

SPF, DKIM y DMARC son las tres capas que la industria ha ido añadiendo por encima de SMTP para tapar ese agujero sin romper el correo que ya funcionaba. No son alternativas entre sí: se complementan, y solo cuando están las tres bien configuradas un dominio queda razonablemente protegido contra la suplantación directa. Aun así, dejan huecos que conviene conocer, porque explican por qué sigues recibiendo phishing pese a que «el correo ya está autenticado».

1. El problema de raíz: SMTP se fía de tu palabra

Cuando un servidor entrega un correo a otro, mantiene un diálogo SMTP en el que anuncia de dónde viene y para quién es. Nada en ese diálogo obliga a demostrar la identidad anunciada. El servidor receptor, históricamente, aceptaba el mensaje y lo colocaba en la bandeja de entrada confiando en lo que le habían dicho.

Para entender las tres tecnologías hay que distinguir dos direcciones de remitente distintas que viajan en cada correo y que casi nadie sabe que existen:

• El remitente de sobre (envelope-from, o Return-Path, o MAIL FROM): la dirección que se usa en el diálogo SMTP y a la que vuelven los rebotes. El usuario normalmente no la ve.
• El remitente de cabecera (el campo From: que muestra tu programa de correo): el «De:» que lees en la pantalla. Es texto libre dentro del mensaje.

Un atacante puede poner lo que quiera en ambos campos. La clave está en que SPF valida el remitente de sobre, DKIM valida una firma sobre la cabecera y el cuerpo, y DMARC es el que por fin comprueba el From: que ve el usuario y exige que cuadre con lo anterior. Por eso las tres juntas tienen sentido y por separado se quedan cortas.

2. SPF: qué servidores pueden enviar en nombre de tu dominio

SPF (Sender Policy Framework) es una lista blanca publicada en el DNS del dominio. Dice: «los correos cuyo remitente de sobre sea @midominio.com solo son legítimos si salen de estas IPs o de estos proveedores». El servidor que recibe el correo mira la IP real desde la que le llega, la compara con esa lista y obtiene un resultado: pass, fail, softfail, neutral o none.

Se publica como un único registro TXT en la raíz del dominio:

; Registro SPF de ejemplo (tipo TXT en midominio.com)
midominio.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.protection.outlook.com -all"
 
; v=spf1                      -> version
; ip4:203.0.113.10           -> nuestro servidor de correo propio
; include:_spf.google.com    -> autorizamos a Google Workspace a enviar por nosotros
; include:spf.protection...  -> y a Microsoft 365
; -all                       -> todo lo demas: FAIL (rechazable)

3. DKIM: una firma criptográfica en cada correo

DKIM (DomainKeys Identified Mail) añade una firma digital a cada mensaje saliente. El servidor de envío calcula un hash de un conjunto de cabeceras elegidas (From, To, Subject, Date…) y del cuerpo, lo firma con una clave privada, y añade el resultado en una cabecera DKIM-Signature. La clave pública correspondiente está publicada en el DNS del dominio.

Quien recibe el correo lee la cabecera DKIM-Signature, ve qué dominio (d=) y qué selector (s=) se han usado, descarga la clave pública de ese punto del DNS y verifica la firma. Si valida, dos cosas quedan demostradas: el correo lo autorizó quien controla ese dominio, y el contenido firmado no se ha modificado en tránsito.

; La clave PUBLICA se publica en:  <selector>._domainkey.<dominio>
s1._domainkey.midominio.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB..."
 
; Y cada correo saliente lleva una cabecera asi:
DKIM-Signature: v=1; a=rsa-sha256; d=midominio.com; s=s1;
    h=from:to:subject:date; bh=<hash-del-cuerpo>;
    b=<firma-de-las-cabeceras>

• El selector (s=) permite tener varias claves a la vez (una por proveedor, o rotarlas sin cortar servicio). Se recomienda claves RSA de 2048 bits y rotarlas periódicamente.
• DKIM sí sobrevive a los reenvíos simples, porque la firma viaja dentro del mensaje. Se rompe si un intermediario modifica el cuerpo o alguna cabecera firmada (por ejemplo, listas de correo que añaden un pie o cambian el asunto).
• DKIM por sí solo no dice nada sobre qué dominio debe firmar: un correo puede llevar una firma DKIM válida de un dominio cualquiera y un From: de otro. Ese vínculo lo pone DMARC.

4. DMARC: la política que ata todo al From: que ve el usuario

DMARC (Domain-based Message Authentication, Reporting and Conformance) es la pieza que convierte SPF y DKIM en una defensa real contra la suplantación. Hace tres cosas:

4.1 Exige alineación

DMARC comprueba que el dominio del From: visible coincide con el dominio validado por SPF o por DKIM. Esto es lo que se llama alineación (alignment). Un correo pasa DMARC si SPF da pass y el dominio de sobre está alineado con el From:, o si DKIM valida y el dominio de la firma está alineado con el From:. Con que una de las dos vías cuadre, basta. La alineación puede ser estricta (dominio idéntico) o relajada (mismo dominio organizativo; por defecto es relajada).

4.2 Fija una política para los que fallan

El dueño del dominio decide qué debe hacer el receptor con los correos que no pasan: p=none (no hacer nada, solo observar), p=quarantine (a spam) o p=reject (rechazar en el propio diálogo SMTP, el correo nunca se entrega).

4.3 Pide informes

DMARC pide a los receptores del mundo que envíen informes de qué correos dicen venir de tu dominio y cómo les ha ido con la autenticación. Es la única forma de ver quién suplanta tu marca y qué envíos legítimos tuyos están mal configurados.

; Registro DMARC: siempre en el subdominio _dmarc
_dmarc.midominio.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:informes@midominio.com;
    ruf=mailto:forense@midominio.com; adkim=s; aspf=s; pct=100; fo=1"
 
; p=reject          -> rechazar lo que no autentique y alinee
; rua=mailto:...     -> a donde mandar los informes AGREGADOS (diarios, XML)
; ruf=mailto:...     -> informes FORENSES (por mensaje; muchos proveedores ya no los mandan)
; adkim=s / aspf=s   -> alineacion estricta para DKIM y SPF
; pct=100            -> aplicar la politica al 100% de los correos

5. Cómo migrar sin cortar correo legítimo

El error clásico es publicar p=reject el primer día. Casi todas las organizaciones tienen envíos legítimos que desconocen: la herramienta de facturación, el CRM, el formulario de la web, el boletín, un servidor antiguo. Si los rechazas de golpe, dejas de recibir facturas y nadie sabe por qué. La migración se hace por fases:

6. Por qué aún te cuelan phishing con las tres activas

SPF, DKIM y DMARC protegen contra una cosa muy concreta: que alguien envíe correo poniendo exactamente tu dominio en el From:. Eso es mucho, pero el phishing tiene otras vías que estas tecnologías no tocan:

• Suplantación del nombre visible: el atacante envía desde atacante@gmail.com pero pone como nombre para mostrar «Soporte de Tu Banco». DMARC valida el dominio gmail.com (que es real), no el texto del nombre. En el móvil solo se ve el nombre, no la dirección.
• Dominios parecidos (lookalike / cousin domains): tu-banco-seguridad.com, tubanco.com.es, tubanc0.com. Son dominios que el atacante controla de verdad, con su propio SPF/DKIM/DMARC perfectos. La autenticación pasa porque el dominio es suyo.
• Homógrafos (IDN): caracteres Unicode que se ven como latinos (una «а» cirílica en «pаypal»). El dominio es otro, pero a la vista es idéntico.
• Cuentas legítimas comprometidas: si el atacante roba las credenciales de un proveedor tuyo real, sus correos salen firmados y alineados de verdad.
• El reenvío rompe SPF: cuando un correo legítimo se reenvía por un servidor intermedio, SPF falla en destino. Para eso existe ARC (Authenticated Received Chain), que preserva el resultado de autenticación original a través de los saltos de confianza.

7. Resumen: qué valida cada mecanismo y qué no cubre

8. Herramientas para comprobarlo

• MXToolbox (mxtoolbox.com): comprobación rápida de SPF, DKIM y DMARC de cualquier dominio desde el navegador, sin registro.
• dmarcian (dmarcian.com): analizador de registros y, sobre todo, agregador de informes RUA con panel visual; plan gratuito para volúmenes bajos.
• learndmarc.com: simulador interactivo que envía un correo de prueba y te enseña paso a paso el diálogo SMTP, la comprobación SPF, la firma DKIM y la evaluación DMARC. Muy recomendable para entenderlo de verdad.
• Enviar un correo a una cuenta de Gmail y usar «Mostrar original»: muestra las tres comprobaciones (PASS/FAIL) y la alineación, gratis y en 10 segundos.
• Consola: dig txt midominio.com, dig txt _dmarc.midominio.com y dig txt selector._domainkey.midominio.com

Conclusión

SPF dice qué servidores pueden enviar, DKIM firma el mensaje para probar que no se ha tocado, y DMARC es quien por fin comprueba que el remitente que ve el usuario es el que dice ser y decide qué hacer cuando no lo es. Las tres son un requisito básico hoy: sin ellas, cualquiera puede enviar correo con tu dominio, y desde febrero de 2024 los grandes proveedores directamente penalizan o rechazan a quien envía en volumen sin autenticar.

Pero autenticar el dominio no es autenticar la intención. El phishing que funciona ya no falsifica tu dominio: usa el nombre visible, un dominio parecido o una cuenta robada. SPF, DKIM y DMARC cierran la puerta principal —y hay que cerrarla— pero la formación de los usuarios y el filtrado por contenido siguen siendo imprescindibles para las ventanas.

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