SPF, DKIM y DMARC en la práctica: deja de que suplanten tu dominio

El correo electrónico nació sin ninguna forma de verificar quién envía qué. Por defecto, cualquiera puede poner tu dominio en el campo From: y mandar un correo que parece tuyo. De ahí vive el phishing, el fraude del CEO y buena parte del spam. La solución son tres registros DNS que, combinados, dejan claro qué servidores pueden enviar en tu nombre y qué hacer con lo que no cuadra: SPF, DKIM y DMARC.

Ninguno es difícil por separado; lo que falla casi siempre es el orden y algunos detalles que rompen la protección en silencio. Vamos a montarlos bien.

1. SPF — quién puede enviar como tú

SPF (Sender Policy Framework) es un registro TXT que lista los servidores autorizados a enviar correo de tu dominio. El receptor comprueba la IP del emisor contra esa lista.

ejemplo.com.  IN  TXT  "v=spf1 include:_spf.google.com include:amazonses.com -all"

Las piezas clave:

• include: delega en el SPF de tu proveedor (Google Workspace, Microsoft 365, SendGrid…).
• ip4:/ip6: autorizan una IP concreta (tu propio servidor).
• El mecanismo final -all significa «rechaza todo lo demás». Es el objetivo. ~all (softfail) es un paso intermedio aceptable; ?all no protege y +all es un desastre: autoriza a cualquiera.

El error nº 1: pasarse de 10 consultas DNS

El estándar SPF permite como máximo 10 consultas DNS al evaluar el registro. Cada include, a, mx o redirect cuenta, y los include anidados suman los suyos. Si te pasas, muchos receptores devuelven permerror y tu SPF deja de proteger. Es facilísimo llegar a 10 encadenando proveedores. Consolida includes y elimina los que ya no uses.

2. DKIM — la firma criptográfica

SPF valida la IP, pero no sobrevive a los reenvíos y no firma el contenido. Ahí entra DKIM (DomainKeys Identified Mail): tu servidor firma cada correo con una clave privada, y el receptor verifica la firma con la clave pública que publicas en el DNS.

selector1._domainkey.ejemplo.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

• El selector (selector1 arriba) te permite tener varias claves y rotarlas. Lo elige tu proveedor o tú.
• La clave privada vive en el servidor de correo y no sale de ahí. Solo publicas la pública.
• Usa claves de 2048 bits. Las de 1024 se consideran débiles.

Si gestionas tú el firmado (por ejemplo, Postfix con OpenDKIM), necesitas generar el par de claves. Puedes hacerlo sin instalar nada: el generador crea el par con WebCrypto en tu propio navegador y la privada no se envía a ningún sitio.

3. DMARC — qué hacer con lo que no autentica

SPF y DKIM dicen si un correo es legítimo; DMARC le dice al receptor qué hacer cuando falla y te manda informes de quién envía en tu nombre. Es el pegamento que cierra el círculo.

_dmarc.ejemplo.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com; adkim=s; aspf=s"

• p= es la política: none (solo observa), quarantine (a spam) o reject (rechaza). El objetivo es reject.
• rua= es el correo donde recibes los informes agregados. Sin esto vas a ciegas.
• Alineación: DMARC exige que el dominio del From: case con el de SPF o DKIM. En modo estricto (adkim=s/aspf=s) tiene que ser exacto; en relajado, basta el dominio organizativo.

El error nº 2: quedarse en p=none para siempre

Mucha gente publica p=none y lo deja ahí. Eso solo monitoriza: no bloquea ni un solo correo suplantado. p=none es el punto de partida, no el destino.

El despliegue, en el orden correcto

1. SPF y DKIM primero. Asegúrate de que todo tu correo legítimo (tu proveedor, boletines, facturación, la app que manda avisos…) pasa SPF o DKIM y que alinea con tu dominio.
2. DMARC en p=none con rua. Deja que lleguen informes unas 2–4 semanas y revísalos: descubrirás remitentes legítimos que no conocías.
3. Sube a p=quarantine, opcionalmente con pct= para aplicarlo a un porcentaje del correo mientras ganas confianza.
4. Llega a p=reject. Aquí ya frenas de verdad la suplantación.

La regla de oro: no subas la política hasta que los informes confirmen que tu correo bueno alinea. Si te precipitas, tiras correo legítimo.

Cómo verificarlo

Antes y después de cada cambio, comprueba el estado real de los tres registros de tu dominio (y del de tus proveedores). Es la forma más rápida de detectar un SPF con demasiadas consultas, un DMARC olvidado en p=none o un DKIM que no encuentra su selector.

Errores frecuentes (resumen)

• Dos registros SPF en el mismo dominio: solo puede haber uno; con dos, permerror.
• Superar las 10 consultas DNS de SPF encadenando includes.
• Terminar en ~all o ?all y olvidarse de pasar a -all.
• DMARC eterno en p=none sin revisar los informes rua.
• Olvidar los subdominios: si no fijas sp=, heredan la política del dominio; que no queden más débiles por accidente.
• Claves DKIM de 1024 bits o selectores revocados (con p= vacío) que siguen publicados.

Con los tres bien puestos, suplantar tu dominio pasa de trivial a muy difícil, y de paso mejora la entregabilidad de tu correo legítimo. Media hora de DNS que ahorra muchos dolores de cabeza.

Sergio Belmonte Morales
Analista de Ciberseguridad · SOC · Especialista en Sentinel/KQL