SPF, DKIM y DMARC: cómo pasar de p=none a p=reject

SPF dice qué servidores pueden enviar correo en nombre de tu dominio, DKIM firma cada mensaje para demostrar que no se ha modificado, y DMARC le dice al receptor qué hacer cuando un correo falla esas comprobaciones y a quién mandar el informe. Por separado ninguno impide que alguien suplante tu dominio en el campo From que ve el usuario. DMARC con p=reject sí.

Y aun así, muchísimos dominios llevan años con DMARC publicado en p=none. Es el equivalente a tener una alarma que solo apunta en una libreta quién ha entrado.

Qué comprueba cada registro

SPF

Un registro TXT en el dominio con la lista de IPs y servicios autorizados:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

Dos detalles que rompen más SPF de los que deberían: el límite de 10 consultas DNS (cada include cuenta, y los anidados también) y que SPF valida el remitente del sobre (Return-Path), no el From visible.

DKIM

El servidor emisor firma cabeceras y cuerpo con una clave privada, y publica la pública en DNS bajo un selector (selector1._domainkey.tudominio.com). Sobrevive a reenvíos mejor que SPF, que es justo por lo que DMARC acepta cualquiera de los dos.

DMARC

DMARC exige alineación: que el dominio que pasa SPF o DKIM coincida con el del From. Ahí está la protección real contra la suplantación.

v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; fo=1

Por qué ya no es opcional

Desde febrero de 2024, Google y Yahoo exigen SPF, DKIM y DMARC a quien envíe más de 5.000 correos al día a sus usuarios, y Microsoft anunció requisitos equivalentes para Outlook.com en 2025. Para un dominio corporativo pequeño el volumen no llega a esos umbrales, pero la dirección es clara: el correo sin autenticar cada vez llega peor.

El proceso por fases hasta p=reject

1. Inventario. Publica p=none con rua y deja que lleguen informes agregados al menos dos o tres semanas. Te van a aparecer remitentes que nadie recordaba: el CRM, la herramienta de facturas, el formulario de la web, el escáner de la oficina.
2. Arreglar cada remitente legítimo. Para cada uno, configurar DKIM con tu dominio (mejor que añadirlo a SPF, que tiene el límite de 10 consultas).
3. p=quarantine con pct bajo. Empieza con pct=10 o 25, revisa informes, sube.
4. p=reject cuando los informes lleven un tiempo limpios. Aquí también conviene sp=reject para los subdominios, que es por donde entra la suplantación cuando el dominio principal ya está protegido.

Los informes agregados son XML y leerlos a mano es una tortura. Para revisar un mensaje concreto, el analizador de cabeceras de Blue Team Hub muestra el resultado de SPF, DKIM y DMARC y los saltos del correo sin enviar nada a ningún servidor.

Lo que DMARC no hace

DMARC protege tu dominio exacto. No impide que alguien registre tudominio-pagos.com o use un nombre visible engañoso con una cuenta de Gmail. Contra eso hacen falta filtros del lado receptor y formación. Tampoco sirve si el atacante entra en un buzón real de tu organización, que es el escenario del BEC con cuenta comprometida.

Preguntas frecuentes

¿Puedo poner p=reject directamente?

Puedes, pero si hay un servicio legítimo que envía en tu nombre y no está alineado, sus correos se rechazarán sin aviso. Las semanas en p=none sirven precisamente para descubrirlos.

¿Qué diferencia hay entre ~all y -all en SPF?

~all (softfail) marca como sospechoso lo que no está en la lista; -all (fail) lo marca como no autorizado. Con DMARC en reject, la política que manda es la de DMARC, así que la diferencia importa menos de lo que parece.

¿Hace falta DMARC en un dominio que no envía correo?

Sí, y es el caso más fácil: v=spf1 -all y v=DMARC1; p=reject. Los dominios aparcados sin protección son los favoritos para campañas de suplantación.