DMARCbis: tutto ciò che cambia (e come prepararsi)

Situazione al 29 ottobre 2025. Il corpus DMARCbis è quasi definitivo: il documento principale dmarcbis-41 e aggregate-reporting-32 sono nel RFC Editor Queue (MISSREF), in attesa che si chiuda failure-reporting. I record DMARC esistenti restano nel formato v=DMARC1.

TL;DR

• Policy discovery e dominio organizzativo: la Public Suffix List (PSL) viene sostituita da un DNS Tree Walk e dal nuovo marcatore psd (y/n).
• Nuovi tag: psd, np (politica per non-existent domains), t (testing, rimpiazza l'uso pratico di pct=0).
• Tag rimossi: pct, ri, rf.
• Reporting: suddiviso in due documenti normativi (aggregati e failure); eliminato il limite di lunghezza delle URI; ogni URI indicata DEVE ricevere un report.
• Interoperabilità: DMARCbis sconsiglia p=reject sui domini a uso generale (liste, alias, inoltri) e raccomanda p=quarantine finché la catena di autenticazione non è completamente sotto controllo; mantenere p=reject solo quando si gestiscono tutti gli intermediari. Gli MTA non devono rifiutare solo perché è pubblicato p=reject.
• Compatibilità: i record DMARC attuali continuano a funzionare; pianifica la migrazione verso i nuovi tag e le nuove pratiche.

👉 In coda all'articolo c'è un glossario con i concetti chiave: Public Suffix Domain, Organizational Domain e DNS Tree Walk.

1) Calendario e stato

• 17 marzo 2025: Aggregate Reporting v**–32** → RFC Editor Queue (MISSREF).
• 4 aprile 2025: DMARCbis v**–41** → RFC Editor Queue (MISSREF).
• 9 ottobre 2025: Failure Reporting v**–17** entra in WG Last Call.
• Pubblicazione prevista nel 2025 se le referenze pendenti vengono risolte.
• Impatto immediato: nessun cambio di versione (v=DMARC1); tuttavia gli operatori devono prepararsi ai nuovi algoritmi e tag.

2) Policy discovery e Organizational Domain: il DNS Tree Walk

DMARCbis sostituisce la dipendenza dalla PSL con una risalita dell'albero DNS che

1. individua la politica applicabile (Policy Discovery), e
2. determina il dominio organizzativo (Organizational Domain) per l'Alignment.

Principi chiave:

• Si cerca prima "_dmarc." + AuthorDomain. In assenza, si risale etichetta per etichetta (massimo 8 query) finché non si trova un Organizational Domain o un PSD.
• Il tag psd guida l'interpretazione:
  • psd=n ⇒ il dominio che pubblica il record è un Organizational Domain.
  • psd=y (a un livello superiore) ⇒ l'Organizational Domain si trova un'etichetta sotto.
• Se la politica arriva da un dominio padre (Org o PSD), si applica sp ai sottodomini esistenti e np quando il sottodominio non esiste.
• Se non si trova nulla, DMARC non si applica al messaggio.

3) Tag: aggiunte, rimozioni, invariati

Aggiunti

• psd: contrassegna un dominio come Public Suffix Domain (y/n) per guidare il Tree Walk.
• np: politica per domini inesistenti (ereditata dai pilot PSD).
• t: modalità test (y/n) — rimpiazza il modello pct=0 (vedi più avanti).

Rimossi

• pct: i rollout parziali erano incoerenti; il binario 0/100 passa su t.
• ri: intervallo dei report aggregati (ora nel documento Aggregate Reporting e nella prassi operativa).
• rf: formato dei failure report (specificato nel documento Failure Reporting).

Invariati (esempi)

v, p, sp, adkim, aspf, fo, rua, ruf, pct (eliminato: da rimuovere).

4) psd: marcatore di Public Suffix Domain

Il tag psd indica se il dominio che pubblica il record DMARC deve essere trattato come Public Suffix Domain dall'algoritmo di Tree Walk:

• psd=y: il dominio è considerato un PSD. La politica pubblicata copre il suffisso che gestisci, ma i domini registrabili al di sotto restano responsabili del proprio DMARC.
• psd=n: il dominio è un Organizational Domain e fa da ancoraggio al discovery per i suoi sottodomini.

Riserva psd=y agli operatori di suffissi (TLD, registri di settore, grandi organizzazioni con sottodomini delegati). Negli altri casi, ometti il tag o imposta esplicitamente psd=n per chiarire che la zona è un dominio di invio “classico”.

5) np: politica per domini inesistenti

Il tag np estende DMARC ai sottodomini inesistenti individuati durante il Tree Walk:

• Si applica solo quando non c'è un record _dmarc dedicato per il sottodominio (NXDOMAIN).
• I valori ammessi (none, quarantine, reject) seguono la semantica di p/sp.
• Se np manca, si riutilizza il valore di p (o il sp ereditato).

Pubblica np=reject sul tuo dominio organizzativo (o sul PSD) per bloccare i tentativi di spoofing su sottodomini “vuoti” senza dover creare record DMARC individuali.

6) t = testing: il successore pratico di pct=0

Il tag t=y non disabilita il reporting, ma chiede un'applicazione più morbida della politica:

• p=reject + t=y ⇒ trattare i fail come quarantine.
• p=quarantine + t=y ⇒ trattare i fail come none.
• p=none ⇒ invariato.

Obiettivo: consentire una scalata sicura senza i problemi di interoperabilità causati da pct.

7) Reporting: separazione, deliverability e sicurezza

• Diviso in due RFC: report aggregati (XML) e failure report (messaggio per messaggio).
• Eliminato il limite di lunghezza della URI.
• Più URI in rua/ruf: ogni URI DEVE ricevere il proprio report.
• Destinazioni esterne (rua/ruf verso un altro dominio): il meccanismo di autorizzazione resta invariato (record pubblicati dal destinatario del report).
• Privacy: attiva i failure report con cautela; la maggior parte degli operatori continua a privilegiare i report aggregati.

8) Interoperabilità e politiche

• DMARCbis chiarisce che per i domini di messaggistica generale (liste, alias, forwarding) non andrebbe pubblicato p=reject; è preferibile p=quarantine finché la catena di autenticazione end-to-end non è sotto controllo, mantenendo p=reject solo dove ogni hop è sotto la tua autorità.
• I destinatari non dovrebbero rifiutare un messaggio solo perché esiste una politica reject; devono correlare altri segnali (comportamento delle liste, riscritture di header, ARC, reputazione, ecc.).
• Per evitare bypass in modalità relaxed, pubblica i record DMARC il più vicino possibile ai domini che inviano davvero (e valuta adkim=s/aspf=s dove opportuno).

9) Compatibilità e transizione

• v=DMARC1 resta: i record esistenti rimangono validi.
• Da rimuovere: pct, ri, rf.
• Da introdurre: psd dove rilevante (PSO / TLD o domini registrabili particolari), np per controllare i non-existent domains, t per pilotare il rollout.

Esempi di record

Politica organizzativa + scalata controllata

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; adkim=s; aspf=r; 
  rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; t=y"

Marcatura PSD da parte di un operatore di suffisso

_dmarc.bank.example. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:psd-agg@pso.example"

Politica per domini inesistenti

_dmarc.example.net. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:agg@example.net"

10) Playbook CaptainDNS (checklist pratica)

1. Inventario: elenca Author Domains reali e sottodomini attivi; individua le zone senza DMARC.
2. Alberi DNS: verifica l'esito del Tree Walk (dove cade l'Organizational Domain?) e pubblica record il più vicino possibile agli effettivi mittenti.
3. Politiche: parti da p=quarantine + t=y; monitora i report aggregati per 2–4 settimane; passa a t=n e indurisci se i falsi positivi sono sotto controllo.
4. Alignment: punta prima a adkim=s (DKIM firmato sul From); mantieni aspf=r salvo necessità di SPF strict.
5. PSD / np: se gestisci un dominio radice o “di famiglia”, usa np per bloccare i non-existent domains; pubblica psd solo se sei PSO/PSD.
6. Reporting: caselle dedicate rua/ruf, cifrate in transito; verifica le autorizzazioni esterne se un terzo riceve i report.
7. Liste / intermediari: prevedi le riscritture di From:; ARC aiuta a preservare la reputazione evitando rifiuti ingiustificati.
8. Pulizia: rimuovi pct, ri, rf; monitora gli aggregati per cogliere anomalie di interoperabilità.

11) FAQ

• Dobbiamo cambiare v=DMARC1 in v=DMARC2? No — il valore resta DMARC1.
• pct viene ancora rispettato? È stato rimosso dalla specifica; alcuni destinatari potrebbero ignorarlo. Usa t.
• La PSL scompare definitivamente? Sì, per DMARCbis: il discovery ora si basa sul DNS Tree Walk.
• Posso pubblicare p=reject ovunque? Solo se controlli completamente la catena di autenticazione; per la posta di uso generale (liste, alias, inoltri) DMARCbis consiglia di restare su p=quarantine.

12) Glossario

• Public Suffix List (PSL): elenco di suffissi pubblici mantenuto storicamente da Mozilla; DMARCbis ne sostituisce l'uso con il DNS Tree Walk.
• Public Suffix Domain (PSD): suffisso di dominio gestito da un'entità che delega sottodomini ad altri (es. TLD, registri settoriali) e può pubblicare una politica DMARC per l'intero suffisso.
• Public Suffix Operator (PSO): soggetto che gestisce un suffisso pubblico (PSD) e può pubblicare una politica DMARC di riferimento per i domini collegati.
• DNS Tree Walk: procedura DMARCbis che risale l'albero DNS etichetta per etichetta per trovare un record _dmarc, riconoscere un PSD e, se necessario, applicare una politica ereditata (p, sp, np).
• Organizational Domain: dominio principale di un'organizzazione, individuato dal Tree Walk, che governa la politica DMARC dei sottodomini allineati.
• Author Domain: dominio presente nell'intestazione visibile From:; è la base del calcolo di allineamento DMARC.

---

Illustrazioni: diagrammi SVG autoprodotti per CaptainDNS.