Il tuo record TXT _dmarc contiene ancora un tag pct=50? Non serve più a nulla dal 20 maggio 2026. Quel giorno, l’IETF ha pubblicato DMARCbis sotto forma di tre RFC: la 9989 per il nucleo del protocollo, affiancata dalla 9990 e dalla 9991 per il reporting, che sostituiscono ufficialmente la RFC 7489 del 2015 (dmarc.org, maggio 2026). Il tag pct scompare, arrivano due nuovi tag e cambia il meccanismo con cui si scopre il dominio organizzativo. Perdere il 30% di delivery in tre mesi senza alcun cambiamento nei contenuti, con un SaaS di emailing che continua a mostrare uno stato verde, a volte è riconducibile a una configurazione DNS mai rivista piuttosto che al contenuto delle campagne. Per i fondamentali del protocollo, in particolare ciò che non copre, DMARC: 5 cose che non può fare resta il riferimento. Qui si parla del passaggio in sé e di cosa correggere prima che i grandi provider di posta (Google, Microsoft, Yahoo) allineino i loro parser.
Cosa cambia concretamente DMARCbis rispetto alla RFC 7489?
La RFC 7489 aveva lo status «Informational» sin dalla sua pubblicazione nel 2015: DMARC non era mai diventato uno standard Internet in senso stretto secondo l’IETF. La RFC 9989 corregge questo punto. Il protocollo passa a Proposed Standard, il primo gradino normativo dell’IETF, e rende obsolete sia la RFC 7489 sia la RFC 9091, l’estensione PSD DMARC rimasta sperimentale. La RFC 9990 disciplina ora i rapporti aggregati XML; la RFC 9991 copre i rapporti di errore messaggio per messaggio. Il tutto deriva dalla bozza draft-ietf-dmarc-dmarcbis-41, pubblicata il 4 aprile 2025 al termine di un lavoro iniziato nel 2019, sulla scia del completamento del protocollo ARC.
Un aspetto rassicura gli amministratori più frettolosi. Il valore v=DMARC1 non cambia. Un record pubblicato nel 2019 continua a funzionare nel 2026, senza interruzioni di servizio il giorno del passaggio.
I tag che DMARCbis elimina
Tre tag escono dalla specifica, con pct in testa. Pensato per applicare la policy a una percentuale del traffico, soffriva di un difetto documentato da anni: in pratica, solo i valori 0 e 100 venivano applicati in modo affidabile, mentre i valori intermedi producevano comportamenti incoerenti da un provider all’altro (dmarcian, 2025). Viene sostituito da un tag binario, t, con solo due valori: t=y per la modalità test, equivalente al vecchio pct=0, e t=n per l’applicazione completa, equivalente a pct=100. Insieme a lui scompaiono rf, il formato dei rapporti aggregati, e ri, l’intervallo tra i rapporti, spostati nei documenti di reporting RFC 9990 e RFC 9991. Un record che contiene ancora uno di questi tre tag continua a funzionare, diventa semplicemente obsoleto.
I tag che DMARCbis aggiunge
Il tag np colpisce un punto cieco reale della RFC 7489, quello dei sottodomini che non esistono nel DNS. Un attaccante poteva finora inviare da fake.pagamento.esempio.com senza che si applicasse alcuna policy DMARC, dato che il sottodominio semplicemente non aveva un record da interrogare (dmarcian, 2025). Con np=reject o np=quarantine, il proprietario del dominio chiude questa porta senza dover irrigidire il resto del suo traffico legittimo. Al suo fianco, il tag psd riprende il contenuto della vecchia RFC 9091: segna un dominio come suffisso pubblico (psd=y), un’informazione che alimenta il meccanismo di discovery descritto più avanti. Un dominio che punta alla visualizzazione BIMI in Gmail dovrà comunque passare per p=quarantine o p=reject: la precisazione introdotta da np non cambia nulla a questo prerequisito già in vigore.
La discovery tramite albero DNS sostituisce la Public Suffix List
Prendiamo mail.marketing.esempio.com. Sotto la RFC 7489, determinare il dominio organizzativo di questo indirizzo dipendeva dalla Public Suffix List, un elenco mantenuto manualmente da Mozilla, aggiornato fuori banda, mai formalmente standardizzato. Un registro dimenticato o un nuovo TLD assente dall’elenco produceva un falso negativo silenzioso. La RFC 9989 sostituisce questo meccanismo con un DNS Tree Walk: il ricevente interroga in sequenza mail.marketing.esempio.com, poi marketing.esempio.com, poi esempio.com, poi il TLD, e si ferma non appena trova un record con psd=n (dominio organizzativo) o psd=y (suffisso pubblico). L’algoritmo è limitato a 8 query DNS, un numero fissato nella sezione 4.10 della RFC stessa. I rapporti aggregati della RFC 9990 aggiungono due campi finora assenti: discovery_method e testing, che indicano come è stata trovata la policy e se il dominio gira in modalità t=y. Un amministratore che leggeva i propri rapporti XML senza mai controllare questi due campi dovrà integrarli nella propria dashboard.
L’impatto sull’allineamento SPF e DKIM
L’allineamento segue sempre la stessa meccanica: confrontare il dominio autenticato da SPF o DKIM con il dominio organizzativo del dominio From. Ciò che cambia è il calcolo di questo dominio organizzativo, che non deriva più da un elenco esterno ma da una risoluzione DNS deterministica. Su un dominio dallo schema classico, del tipo esempio.com senza sottolivelli particolari, non cambia nulla. Su una struttura DNS profonda, con più livelli di sottodomini gestiti da entità diverse, il risultato del tree walk può differire da quello che restituiva la PSL, soprattutto quando un livello intermedio pubblica ora un record psd. La RFC 9989 chiarisce anche un punto già vero nei fatti ma raramente scritto nero su bianco: l’allineamento SPF riguarda solo l’identità MAIL FROM del comando SMTP, mai l’identità HELO. Un dominio che puntava su un allineamento HELO in realtà non è mai stato coperto; la precisazione non fa che renderlo esplicito. Per i punti di frizione strutturali del protocollo SPF stesso, il limite dei 10 lookup DNS e le conseguenze di un SPF assente restano attuali, DMARCbis non li elimina.
Resta un limite. Oltre le otto query DNS, il tree walk non risolve nulla. La RFC fissa questo tetto per evitare loop e attacchi di amplificazione, ma un’architettura a delega profonda, un fornitore DNS impilato su un altro fornitore, può scontrarsi con questo limite ancora prima di raggiungere il vero dominio organizzativo.
Quali tag DNS TXT _dmarc correggere prima del passaggio?
La documentazione IETF non specifica entro quanto tempo i grandi provider di posta (Google, Microsoft, Yahoo) migreranno i loro parser di ricezione a DMARCbis. Le tre RFC sono pubblicate; l’adozione lato provider resta graduale e senza scadenze precise in questa fase. Correggere il record ora evita di trovarsi in ritardo il giorno in cui uno dei tre passerà alla lettura predefinita aggiornata.
- Rimuovere qualsiasi tag pct= dal record TXT _dmarc, indipendentemente dal suo valore attuale.
- Eliminare rf= e ri= se presenti, due parametri che un provider conforme alla RFC 9989 non legge più.
- Aggiungere np=quarantine o np=reject non appena la policy principale, p=, è già applicata, per chiudere la porta ai sottodomini inesistenti.
- Verificare la struttura dei sottodomini gestiti da fornitori esterni, registro, filiale, marchio secondario, e valutare se un tag psd=y o psd=n debba essere pubblicato a un livello intermedio.
- Documentare la modalità t= scelta, t=y in test o t=n in applicazione, invece di lasciare che un valore pct ereditato faccia fede.
Nessuna di queste correzioni richiede di annullare o riconfigurare un record SPF o DKIM esistente. Il lavoro resta circoscritto al campo DMARC, anche se tocca la stessa zona DNS delle registrazioni CNAME già in uso per altri scopi.
«I cambiamenti e i miglioramenti noti come DMARCbis sono ora ufficiali: il protocollo passa sulla via normativa dell’IETF» (dmarc.org, maggio 2026).
Cosa cambia il passaggio per la reputazione di invio
Ripulire il record DMARC risolve solo una parte del problema. Un dominio perfettamente allineato che invia verso una lista degradata continua a generare rifiuti, ma per un altro motivo. Il tasso di hard bounce sale, la sender reputation peggiora presso il postmaster di Gmail, e un DMARC reject su un dominio per il resto pulito finisce per essere letto come un segnale di spam piuttosto che come un’anomalia isolata. È l’obiezione classica: verificare una lista prima dell’invio ha un costo, tanto vale filtrare a posteriori. Peccato che un rifiuto DMARC post-autenticazione non si recuperi in fase di smistamento come un soft bounce ordinario: danneggia la reputazione dell’IP ancora prima che questo smistamento avvenga. I feedback loop degli ISP e il complaint rate salgono di solito prima che l’SNDS di Microsoft segnali qualcosa di anomalo. Un passaggio a DMARCbis mal preparato, unito a una lista mai ripulita, somma le due cause di rifiuto invece di isolarne una sola. Per capire perché i rifiuti SMTP aumentano e come farli scendere, il tema si ricollega a quello del record DNS trattato qui. L’unico modo per sapere quale delle due cause pesi di più è passare la lista al setaccio prima della prossima campagna, separatamente dal lavoro sul record DNS.
I protocolli si aggiornano da soli. I record DNS, mai.
