SPF, DKIM i DMARC: com passar de p=none a p=reject

SPF diu quins servidors poden enviar correu en nom del teu domini, DKIM signa cada missatge per demostrar que no s'ha modificat, i DMARC li diu al receptor què fer quan un correu falla aquestes comprovacions i a qui enviar l'informe. Per separat cap d'ells impedeix que algú suplanti el teu domini al camp From que veu l'usuari. DMARC amb p=reject sí.

I tot i així, moltíssims dominis porten anys amb DMARC publicat en p=none. És l'equivalent de tenir una alarma que només apunta en una llibreta qui ha entrat.

Què comprova cada registre

SPF

Un registre TXT al domini amb la llista d'IP i serveis autoritzats:

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

Dos detalls que trenquen més SPF dels que haurien: el límit de 10 consultes DNS (cada include compta, i els aniuats també) i que SPF valida el remitent del sobre (Return-Path), no el From visible.

DKIM

El servidor emissor signa capçaleres i cos amb una clau privada, i publica la pública a DNS sota un selector (selector1._domainkey.tudominio.com). Sobreviu als reenviaments millor que SPF, que és just el motiu pel qual DMARC accepta qualsevol dels dos.

DMARC

DMARC exigeix alineació: que el domini que passa SPF o DKIM coincideixi amb el del From. Aquí hi ha la protecció real contra la suplantació.

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

Per què ja no és opcional

Des del febrer de 2024, Google i Yahoo exigeixen SPF, DKIM i DMARC a qui enviï més de 5.000 correus al dia als seus usuaris, i Microsoft va anunciar requisits equivalents per a Outlook.com el 2025. Per a un domini corporatiu petit el volum no arriba a aquests llindars, però la direcció és clara: el correu sense autenticar arriba cada cop pitjor.

El procés per fases fins a p=reject

1. Inventari. Publica p=none amb rua i deixa que arribin informes agregats almenys dues o tres setmanes. Et sortiran remitents que ningú recordava: el CRM, l'eina de factures, el formulari del web, l'escàner de l'oficina.
2. Arreglar cada remitent legítim. Per a cadascun, configurar DKIM amb el teu domini (millor que afegir-lo a SPF, que té el límit de 10 consultes).
3. p=quarantine amb pct baix. Comença amb pct=10 o 25, revisa informes, puja.
4. p=reject quan els informes portin un temps nets. Aquí també convé sp=reject per als subdominis, que és per on entra la suplantació quan el domini principal ja està protegit.

Els informes agregats són XML i llegir-los a mà és una tortura. Per revisar un missatge concret, l'analitzador de capçaleres de Blue Team Hub mostra el resultat de SPF, DKIM i DMARC i els salts del correu sense enviar res a cap servidor.

El que DMARC no fa

DMARC protegeix el teu domini exacte. No impedeix que algú registri tudominio-pagos.com o faci servir un nom visible enganyós amb un compte de Gmail. Contra això calen filtres del costat receptor i formació. Tampoc serveix si l'atacant entra en una bústia real de la teva organització, que és l'escenari del BEC amb compte compromès.

Preguntes freqüents

Puc posar p=reject directament?

Pots, però si hi ha un servei legítim que envia en nom teu i no està alineat, els seus correus es rebutjaran sense avís. Les setmanes en p=none serveixen precisament per descobrir-los.

Quina diferència hi ha entre ~all i -all a SPF?

~all (softfail) marca com a sospitós el que no és a la llista; -all (fail) ho marca com a no autoritzat. Amb DMARC en reject, la política que mana és la de DMARC, així que la diferència importa menys del que sembla.

Cal DMARC en un domini que no envia correu?

Sí, i és el cas més fàcil: v=spf1 -all i v=DMARC1; p=reject. Els dominis aparcats sense protecció són els preferits per a campanyes de suplantació.