Pujar DMARC fins a reject sense trencar res

Es puja a p=reject per subdominis i per temps, no per percentatges, perquè des del maig del 2026 els percentatges ja no existeixen. La revisió de DMARC va eliminar el tag pct, així que el manual que circula per internet (publicar pct=10, després pct=25, després pct=50) descriu un mecanisme que avui no és a la norma. La política s'aplica sencera o no s'aplica.

El que sí que funciona és això: observar amb p=none fins a tenir tancat l'inventari de qui envia en nom teu, començar l'enforcement pel flux que controles al cent per cent, blindar els subdominis amb sp i np mentre el domini arrel continua tolerant, i deixar l'arrel per al final. Entre sis i dotze setmanes, segons com de desendreçada tinguis la casa.

El que va canviar el maig del 2026

DMARC va deixar de ser un document informatiu i va passar a la via d'estàndard. El RFC 7489 queda obsolet i el substitueixen tres documents: el RFC 9989 (protocol i política), el RFC 9990 (informes agregats) i el RFC 9991 (informes de fallada). Aquests són els canvis que toquen la feina diària:

Regla pràctica de transició: publica registres que es llegeixin bé amb la norma vella i amb la nova. Ni facis servir pct per a res, ni donis per fet que t= t'està protegint.

Abans de tocar la política: els quatre calaixos

Pujar a reject és prometre al món que tot el que surt amb el teu domini al From està autenticat i alineat. Si aquesta promesa és falsa per a un sol emissor amb volum, el dia del canvi deixen d'arribar els seus missatges: normalment l'ERP que envia les factures, el CRM, el formulari del web o l'agència de màrqueting. Per això la feina de debò no és publicar el registre, és tancar l'inventari. Cada IP que apareix als informes agregats va a un d'aquests quatre calaixos:

1. Calaix 1 · Legítima i alineadaÉs teva, autentica i alinea. No hi ha res a fer. Només s'anota per no tornar-la a investigar el mes que ve.
2. Calaix 2 · Legítima i no alineadaÉs teva i autentica, però amb el domini d'un altre: signa amb d= del proveïdor, o amb el seu Return-Path. S'arregla signant amb el teu domini o canviant el Return-Path. Aquest calaix és el que decideix el calendari: mentre tingui volum material, no es puja de graó.
3. Calaix 3 · ReenviamentsVolum baix repartit entre moltes IP diferents, amb SPF fail i DKIM pass. És el comportament normal d'un reenviament i no s'arregla des del teu costat: ho mitiga ARC, que posa l'intermediari. No és motiu per no pujar.
4. Calaix 4 · SuplantacióVolum variable, cap autenticació, orígens que no reconeixes. És exactament la raó per la qual existeix DMARC i per la qual val la pena arribar a reject.

El criteri numèric per passar de fase és un de sol: almenys el 98 per cent del volum legítim passant DMARC durant set dies seguits. No serveix un dia bo, perquè hi ha emissors que només envien a final de mes.

Setmana 0: observar sense canviar res

_dmarc.empresa.es. IN TXT "v=DMARC1; p=none; rua=mailto:rua@rep.empresa.es; ruf=mailto:ruf@rep.empresa.es; fo=1; adkim=r; aspf=r"

Durada mínima: dues setmanes. Durada realista: entre quatre i sis si l'empresa té facturació, ERP, CRM, formularis web i una agència pel mig. Sempre hi ha un emissor oblidat, i apareix tard. Dos avisos sobre aquest registre: la bústia del rua ha de ser una que algú processi de debò, perquè publicar un rua que ningú no llegeix és no tenir DMARC; i no comptis amb els informes de fallada (ruf), que avui gairebé ningú no envia per protecció de dades, Google inclòs.

Setmanes 2 a 6: inventari i sanejament

Amb els informes a la mà, la llista de fonts emissores ha de quedar tancada: cada IP i cada domini que envia en nom teu, o s'autentica alineat o s'apaga. El patró que més veuràs als XML és aquest, i convé saber llegir-lo abans de discutir-lo amb un proveïdor:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>     <!-- resultat d'ALINEACIÓ -->
  <spf>pass</spf>
</policy_evaluated>
...
<auth_results>
  <dkim><domain>proveedor.com</domain><result>pass</result></dkim>   <!-- signatura correcta -->
  <spf><domain>empresa.es</domain><result>pass</result></spf>
</auth_results>

Setmanes 6 a 8: enforcement pel flux més controlat

Es comença pel subdomini de menys risc, que gairebé sempre és el transaccional: el genera un sistema, surt per un sol proveïdor i ningú no el reenvia a mà.

_dmarc.mail.empresa.es. IN TXT "v=DMARC1; p=reject; rua=mailto:rua@rep.empresa.es"

Setmanes 8 a 10: l'arrel a quarantine, els subdominis a reject

_dmarc.empresa.es. IN TXT "v=DMARC1; p=quarantine; sp=reject; np=reject; rua=mailto:rua@rep.empresa.es; fo=1"

Aquí convé entendre el tree walk, perquè canvia a qui s'aplica el teu sp. Abans, per saber quin era el domini organitzatiu d'un subdomini, els receptors consultaven la Public Suffix List. Ara pugen per l'arbre amb fins a vuit consultes DNS fins a trobar un registre DMARC. Conseqüència pràctica: un subdomini sense política pròpia hereta la del pare pel camí curt, i els dominis sota sufixos estranys deixen de donar sorpreses.

Setmanes 10 a 12: el domini arrel a reject

_dmarc.empresa.es. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=r; rua=mailto:rua@rep.empresa.es; fo=1"

Els dominis que no envien correu

Els dominis defensius, les marques antigues i els dominis comprats per semblança no necessiten escala: no envien, així que no hi ha res a trencar. Van directes a reject, amb SPF i DKIM nuls, i és de les coses més rendibles que es poden fer en una tarda.

parked.es.                  IN TXT "v=spf1 -all"
*._domainkey.parked.es.     IN TXT "v=DKIM1; p="
_dmarc.parked.es.           IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s;"

Els tres errors que trenquen correu de debò

I un quart que no trenca correu però costa diners: creure que reject arregla l'entregabilitat. No l'arregla. DMARC impedeix que altres facin servir el teu domini i és un requisit dels grans proveïdors, però no millora per si sol la teva reputació ni et treu de la carpeta de correu no desitjat. Això depèn de les queixes, de la higiene de la llista i del contingut.

Si en llegir això t'has adonat que el problema és un pas abans, en el fet que els fluxos no alineen, la guia de SPF, DKIM i DMARC explica d'on surt aquella alineació i com es comprova en un missatge real. I si el que vols saber és què t'exigeixen exactament Gmail, Outlook i Yahoo per no rebutjar-te, és a la guia de requisits, amb la taula comparada dels tres.