DMARCbis: la guida completa per capire e migrare verso il nuovo standard DMARC

⚡TL;DR

• DMARCbis sostituisce DMARC (RFC 7489) e diventa un Proposed Standard IETF. I tre documenti sono in coda al RFC Editor, con pubblicazione prevista nel corso del 2026.
• Il DNS Tree Walk sostituisce la Public Suffix List: la scoperta del dominio organizzativo avviene tramite query DNS successive (max 8), senza dipendenza da una lista esterna.
• Tre tag aggiunti: psd (marcatore Public Suffix Domain), np (policy per sottodomini inesistenti), t (modalità testing binaria).
• Tre tag rimossi: pct (sostituito da t), ri e rf (spostati nei documenti di reporting).
• I tuoi record DMARC attuali restano validi (v=DMARC1). La migrazione consiste nel rimuovere i tag obsoleti e adottare progressivamente quelli nuovi.

DMARC protegge i domini contro lo spoofing email dal 2015. Ma la RFC 7489 soffriva di debolezze strutturali: dipendenza da una lista esterna (la Public Suffix List), un tag pct poco compreso e mal implementato, nessun meccanismo per i sottodomini inesistenti.

DMARCbis corregge questi problemi. Non è un semplice aggiornamento: è una riscrittura che porta DMARC al rango di Proposed Standard IETF, il primo status normativo del protocollo. I tre documenti (base, report aggregati, report di errore) sono in coda al RFC Editor dalla fine del 2025. La pubblicazione è imminente.

Questa guida si rivolge agli amministratori di sistema, ai responsabili email e agli ingegneri della sicurezza che devono capire i cambiamenti e preparare la migrazione. Troverai il funzionamento dettagliato del DNS Tree Walk, un confronto completo dei tag, un piano di migrazione e le implicazioni per la conformità (PCI DSS 4.0, Google, Yahoo, Microsoft).

Un glossario alla fine dell'articolo definisce i termini tecnici: PSL, PSD, PSO, Tree Walk, Organizational Domain, Author Domain.

Cos'è DMARCbis?

DMARCbis è il successore di DMARC come definito dalla RFC 7489. Il termine "bis" segue la convenzione IETF per indicare la seconda iterazione di un protocollo. Concretamente, DMARCbis raggruppa tre documenti normativi:

• draft-ietf-dmarc-dmarcbis: il documento base (scoperta della policy, allineamento, tag)
• draft-ietf-dmarc-aggregate-reporting: i report aggregati XML
• draft-ietf-dmarc-failure-reporting: i report di errore (messaggio per messaggio)

Perché questa revisione?

La RFC 7489, pubblicata nel 2015, aveva lo status "Informational". Ciò significa che DMARC non era uno standard Internet in senso stretto. DMARCbis corregge questa anomalia diventando un Proposed Standard, il che gli conferisce un peso normativo nell'ecosistema IETF.

Le motivazioni tecniche sono precise:

1. La Public Suffix List è fragile. Mantenuta manualmente da Mozilla, non standardizzata, aggiornata fuori banda. Un registro dimenticato o un nuovo TLD non elencato provoca falsi negativi.
2. Il tag pct era inutile. In pratica, solo i valori 0 e 100 venivano utilizzati. Le implementazioni variavano tra i riceventi, rendendo il comportamento imprevedibile.
3. I sottodomini inesistenti non erano protetti. Un attaccante poteva inviare da falso.sottodominio.captaindns.com senza che DMARC si applicasse.
4. PSD DMARC (RFC 9091) restava sperimentale. DMARCbis integra e sostituisce questa estensione unificando il modello tramite il tag psd e il Tree Walk.

Cronologia IETF

Data	Evento
2015	RFC 7489 pubblicata (Informational)
2021	RFC 9091 PSD DMARC (Experimental)
2024-2025	Draft DMARCbis iterativi nel WG DMARC
Q4 2025	I tre draft entrano in coda al RFC Editor (stato EDIT)
Q1/Q2 2026	Pubblicazione prevista come Proposed Standard

Punto essenziale: la versione del record DNS resta v=DMARC1. Non esiste un v=DMARC2. I record esistenti continuano a funzionare.

Il tree walk DNS: la fine del PSL

Il cambiamento più strutturale di DMARCbis è la sostituzione della Public Suffix List con un algoritmo di scoperta puramente DNS: il Tree Walk.

Il problema del PSL

Con DMARC v1, per determinare il dominio organizzativo (Organizational Domain), il ricevente consultava la Public Suffix List. Questa lista, mantenuta da Mozilla, elenca i suffissi pubblici (co.uk, com.au, gouv.fr). Il ricevente sottraeva il suffisso pubblico dal dominio per identificare l'organizzazione.

I limiti erano noti:

• La lista deve essere scaricata e aggiornata regolarmente (possibile disallineamento)
• I nuovi TLD o suffissi non elencati provocano errori
• Il meccanismo non è standardizzato: ogni implementazione gestisce la lista in modo diverso
• Nessuna autorità DNS valida l'esattezza della lista

Come funziona il tree walk?

Il Tree Walk interroga direttamente il DNS per scoprire la policy DMARC applicabile. L'algoritmo è il seguente:

Input: il dominio dell'header From: (Author Domain)

Passi:

1. Interrogare _dmarc.<AuthorDomain>. Se un record DMARC viene trovato con psd=n (o senza tag psd), questo dominio è il dominio organizzativo. Fine.
2. Se non viene trovato nessun record, rimuovere l'etichetta più a sinistra e ripetere.
3. Se viene trovato un record con psd=y, il dominio organizzativo si trova un'etichetta sotto il dominio corrente.
4. Se viene trovato un record con psd=u, continuare la risalita.
5. Ripetere fino a trovare un risultato o raggiungere il limite di 8 query DNS.

Output: il dominio organizzativo e la policy applicabile (oppure "nessun DMARC" se non viene trovato nulla).

Esempi concreti

Caso 1: dominio semplice

Per newsletter.captaindns.com:

Query 1: _dmarc.newsletter.captaindns.com → nessun record
Query 2: _dmarc.captaindns.com → "v=DMARC1; p=reject; psd=n"

Risultato: psd=n conferma che captaindns.com è il dominio organizzativo. 2 query DNS.

Caso 2: Public Suffix Domain

Per contact.banque.co.uk:

Query 1: _dmarc.contact.banque.co.uk → nessun record
Query 2: _dmarc.banque.co.uk → nessun record
Query 3: _dmarc.co.uk → "v=DMARC1; p=reject; psd=y"

Risultato: psd=y segnala che co.uk è un PSD. Il dominio organizzativo è banque.co.uk (un'etichetta sotto il PSD). 3 query DNS.

Caso 3: dominio profondo

Per un dominio con più di 8 etichette, l'algoritmo salta direttamente a 7 etichette dopo la prima query, poi risale etichetta per etichetta. Il limite di 8 query garantisce che il processo termini.

Confronto tra PSL e tree walk

Aspetto	PSL (RFC 7489)	DNS Tree Walk (DMARCbis)
Fonte di verità	Lista statica (Mozilla)	Il DNS stesso
Aggiornamento	Download periodico	Tempo reale tramite query DNS
Copertura	Manuale, potenzialmente incompleta	Qualsiasi dominio che pubblica un record _dmarc
Rilevamento PSD	Lookup nella lista	Tag psd=y nel record DNS
Standardizzazione	Progetto comunitario, non normativo	Standards Track IETF

Prestazioni del tree walk

Per un dominio tipico a 3 etichette (come newsletter.captaindns.com), il Tree Walk aggiunge al massimo 1 query DNS supplementare rispetto a DMARC v1. Il limite di 8 query garantisce che i domini profondi non causino sovraccarico.

La cache DNS attenua l'impatto in pratica. I record _dmarc del dominio organizzativo vengono messi in cache dopo la prima query. Anche le risposte NXDOMAIN vengono messe in cache secondo il TTL del campo MINIMUM del SOA. Un dominio che riceve migliaia di messaggi all'ora genererà solo una manciata di query Tree Walk effettive.

In confronto, l'approccio PSL non generava alcuna query DNS per la scoperta. Ma richiedeva il download periodico di una lista di circa 250 KB e la sua manutenzione in memoria.

Raccomandazione TTL: pubblica i tuoi record _dmarc con un TTL di almeno 3600 s. Un TTL di 86400 s riduce ulteriormente il carico DNS. Questo è particolarmente utile per i record con psd=n o psd=y, che fungono da punti di ancoraggio per il Tree Walk.

Cosa cambia nei tag DMARC

DMARCbis aggiunge tre tag, ne rimuove tre e modifica il comportamento di due esistenti. Il tag di versione (v=DMARC1) e i tag fondamentali (p, sp, adkim, aspf, fo) restano invariati.

Tag aggiunti

Il tag psd: marcatore di suffisso pubblico

Il tag psd indica se il dominio che pubblica il record è un Public Suffix Domain.

Valore	Significato
y	Questo dominio è un PSD (es.: co.uk, gouv.fr). Il dominio organizzativo si trova un'etichetta sotto.
n	Questo dominio è un dominio organizzativo normale.
u	Non determinato. Il Tree Walk continua la risalita.

Valore predefinito: u (undetermined).

Chi deve usarlo? Solo gli operatori di suffissi pubblici (registri TLD, registri settoriali). Per un dominio standard, lascia psd assente o indica psd=n.

Esempio per un registro:

_dmarc.co.uk. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:dmarc-agg@registry.co.uk"

Il tag np: policy per sottodomini inesistenti

Il tag np colma un punto cieco di DMARC v1: i sottodomini che non esistono nel DNS. Un attaccante poteva inviare da falso.captaindns.com senza una policy applicabile se nessun record _dmarc esisteva a quel livello.

Con np, il dominio organizzativo può dichiarare una policy specifica per questi casi. I valori sono identici a p: none, quarantine, reject.

La catena di fallback è: np (se presente) poi sp (se presente) poi p.

Il ricevente verifica l'esistenza del sottodominio tramite DNS. Se il DNS restituisce NXDOMAIN, la policy np si applica.

Esempio:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-agg@captaindns.com"

Risultato: i sottodomini esistenti ereditano p=quarantine. I sottodomini inesistenti vengono bloccati da np=reject.

Il tag t: modalità testing

Il tag t sostituisce l'uso di pct=0 per la modalità test. La semantica è binaria:

• t=y: la policy viene retrocessa di un livello (reject diventa quarantine, quarantine diventa none)
• t=n: la policy si applica normalmente (valore predefinito)

La modalità testing non influisce sul reporting: i report aggregati vengono inviati normalmente, il che permette di monitorare i risultati prima di applicare la policy restrittiva.

Punto critico per la transizione: i riceventi DMARC v1 ignorano i tag sconosciuti. Se pubblichi p=reject; t=y, un ricevente che non implementa ancora DMARCbis applicherà reject senza tenere conto del t=y. Questo comportamento è previsto per design: garantisce che la policy più restrittiva si applichi di default.

Tag rimossi

Tag	Motivo della rimozione	Sostituzione
pct	In pratica, solo i valori 0 e 100 venivano utilizzati. Il comportamento variava tra le implementazioni.	t=y per la modalità test, eliminazione per il resto
ri	L'intervallo di reporting era standardizzato de facto a 24 h. I riceventi ignoravano gli altri valori.	Gestito dal documento Aggregate Reporting
rf	Esisteva un solo formato (afrf). Nessuna alternativa è mai stata implementata.	Gestito dal documento Failure Reporting

Se i tuoi record DMARC contengono ancora pct, ri o rf, continueranno a funzionare (i riceventi li ignoreranno). Ma è consigliato rimuoverli per evitare qualsiasi ambiguità.

Tag modificati

rua (report aggregati): la sintassi di limite dimensione (!10m) è stata rimossa. La verifica della destinazione esterna è rafforzata: se il dominio dell'indirizzo rua differisce dal dominio DMARC, deve esistere un record di autorizzazione _dmarc-report._report.<rua-domain>.

ruf (report di errore): definito in un documento RFC separato (Failure Reporting). Stessa verifica di destinazione esterna di rua.

Tabella riepilogativa v1 vs DMARCbis

Tag	DMARC v1	DMARCbis	Stato
v	DMARC1	DMARC1	Invariato
p	none / quarantine / reject	Identico	Invariato
sp	Policy sottodomini	Identico	Invariato
adkim	r / s	Identico	Invariato
aspf	r / s	Identico	Invariato
fo	0 / 1 / d / s	Identico	Invariato
rua	URI con limite dimensione	URI senza limite, verifica esterna rafforzata	Modificato
ruf	URI	Definito in RFC separato	Modificato
pct	0-100	Rimosso	Rimosso
ri	Secondi	Rimosso	Rimosso
rf	afrf	Rimosso	Rimosso
np	N/A	none / quarantine / reject	Nuovo
psd	N/A	y / n / u	Nuovo
t	N/A	y / n	Nuovo

Il reporting si separa in tre documenti

DMARC v1 raggruppava tutto nella RFC 7489: policy, report aggregati e report di errore. DMARCbis separa queste responsabilità in tre documenti normativi distinti.

I report aggregati

I report aggregati restano in formato XML, ma lo schema evolve. Le principali modifiche:

• Nuovo namespace XML: urn:ietf:params:xml:ns:dmarc-2.0
• Nuovo campo <testing>: indica se il dominio era in modalità test (t=y)
• Nuovo campo <np>: policy per sottodomini inesistenti
• Nuovo campo <discovery_method>: come la policy è stata scoperta (Tree Walk vs diretto)
• Nuova disposizione pass: aggiunta alle disposizioni possibili
• Rimozione di sampled_out: il motivo di override scompare con pct

Ogni URI elencato in rua riceve il proprio report. Non è più opzionale: i riceventi DEVONO inviare un report distinto a ciascun indirizzo.

I report di errore

I report di errore sono ora coperti da un documento separato. Questa modifica riflette la realtà: la maggior parte dei grandi provider non inviava report di errore, per ragioni di privacy e di volume.

Il documento chiarisce i requisiti di riservatezza e i casi in cui l'invio è appropriato.

Altre modifiche rilevanti

• SPF limitato a MAIL FROM: DMARCbis elimina la verifica SPF basata su HELO/EHLO. Solo il dominio MAIL FROM viene valutato per l'allineamento.
• Indicazioni rafforzate su p=reject: i domini con p=reject devono utilizzare DKIM (non solo SPF). I riceventi non devono rifiutare un messaggio unicamente sulla base di p=reject senza valutazione DKIM/SPF. I domini i cui utenti pubblicano su mailing list non dovrebbero pubblicare p=reject.

DMARCbis e le mailing list

Le mailing list sono il caso d'uso più problematico per DMARC dal 2015. DMARCbis non risolve il problema, ma lo documenta formalmente e rafforza le raccomandazioni.

Perché le mailing list rompono l'allineamento?

Una mailing list modifica il messaggio in transito. L'envelope SMTP cambia (nuovo MAIL FROM), il che rompe l'allineamento SPF. Il contenuto viene spesso modificato (aggiunta di un prefisso all'oggetto, footer di disiscrizione), il che invalida la firma DKIM. Il risultato: un fallimento DMARC sistematico per i domini con p=reject.

DMARCbis rafforza formalmente la raccomandazione: i domini i cui utenti partecipano a mailing list non dovrebbero pubblicare p=reject. La policy p=quarantine è preferibile in questo caso.

ARC come meccanismo di fallback

ARC (Authenticated Received Chain, RFC 8617) permette agli intermediari di preservare una catena di autenticazione. DMARCbis fa riferimento ad ARC come meccanismo che i riceventi POSSONO utilizzare per recuperare i risultati di autenticazione originali. Ma DMARCbis non rende ARC obbligatorio. È un'opzione, non una garanzia.

I tipi di override nei report aggregati

DMARCbis riconosce i seguenti tipi di override nei report aggregati:

• forwarded: messaggio reindirizzato da un terzo
• mailing_list: messaggio proveniente da una mailing list
• trusted_forwarder: forwarder di fiducia identificato dal ricevente
• local_policy: policy locale del ricevente (whitelist, reputazione)
• policy_test_mode: nuovo tipo, sostituisce sampled_out (rimosso con pct)

Questi tipi permettono di capire perché un ricevente ha scelto di non applicare la policy pubblicata.

Consiglio pratico

I software moderni di mailing list (Mailman 3, Sympa) includono mitigazioni DMARC integrate. La più comune: la riscrittura del From: per utilizzare l'indirizzo della lista al posto dell'indirizzo originale. Se il tuo dominio è utilizzato da mailing list, verifica che queste mitigazioni siano attivate. E preferisci p=quarantine a p=reject.

DMARCbis e i provider di invio (ESP)

Nessun ESP maggiore (SendGrid, Mailgun, Amazon SES, Postmark, Brevo) ha annunciato un supporto DMARCbis specifico a marzo 2026. È normale e atteso: DMARCbis è un cambiamento lato ricevente, non lato mittente. Gli ESP non hanno bisogno di modificare la propria infrastruttura.

L'allineamento DKIM: la questione critica

La questione principale per gli ESP resta l'allineamento DKIM. Esistono due modalità di firma:

• Dominio condiviso (es.: d=sendgrid.net): la firma DKIM utilizza il dominio dell'ESP. L'allineamento strict fallisce perché il dominio DKIM non corrisponde al dominio From:. Anche l'allineamento relaxed fallisce.
• Dominio personalizzato via CNAME (es.: d=captaindns.com): la firma DKIM utilizza il tuo dominio. L'allineamento passa sia in strict che in relaxed.

DMARCbis raccomanda adkim=s (strict). Questa raccomandazione rende la firma DKIM personalizzata indispensabile per qualsiasi dominio che utilizza un ESP.

SPF e il dominio di rimbalzo

DMARCbis elimina la verifica SPF basata su HELO/EHLO. Solo il dominio MAIL FROM (Return-Path) conta per l'allineamento SPF. La maggior parte degli ESP utilizza un dominio di rimbalzo generico di default (es.: bounce.sendgrid.net). Questo dominio non corrisponde al tuo dominio From:, il che fa fallire l'allineamento SPF.

La soluzione: configura un dominio di rimbalzo personalizzato (Return-Path) che corrisponda al tuo dominio From:. La maggior parte degli ESP propone questa opzione tramite un CNAME DNS.

Checklist ESP

1. Verificare la firma DKIM personalizzata: il tuo ESP deve firmare con d=captaindns.com, non con il proprio dominio.
2. Verificare il Return-Path personalizzato: il dominio di rimbalzo deve corrispondere al tuo dominio From:.
3. Testare l'allineamento strict: invia un'email di test e verifica gli header. I campi d= (DKIM) e Return-Path devono corrispondere al dominio From:.
4. Iniziare in relaxed, passare a strict: pubblica adkim=r prima, valida i report, poi passa ad adkim=s.

Come migrare verso DMARCbis

La buona notizia: la migrazione è progressiva. I tuoi record DMARC attuali restano funzionali. Ecco i passi consigliati.

Passo 1: audit dei record attuali

Identifica tutti i tuoi domini e sottodomini che pubblicano un record _dmarc. Annota i tag utilizzati, in particolare pct, ri e rf.

Esempio di record esistente:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=100; ri=86400; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Passo 2: rimuovere i tag obsoleti

Elimina pct, ri e rf dai tuoi record. Questi tag verranno ignorati dai riceventi DMARCbis e non apportano nulla ai riceventi v1.

Record ripulito:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Passo 3: attivare la modalità testing se necessario

Se stai preparando un passaggio da quarantine a reject, usa t=y per testare prima:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Con t=y, i riceventi DMARCbis applicheranno quarantine al posto di reject. I report rifletteranno questa modalità test. Dopo la validazione (da 2 a 4 settimane di report puliti), rimuovi t=y oppure passa a t=n.

Promemoria: i riceventi DMARC v1 ignoreranno t=y e applicheranno p=reject direttamente. Non è un bug: è il comportamento previsto.

Passo 4: proteggere i sottodomini inesistenti

Aggiungi np=reject per bloccare lo spoofing da sottodomini che non esistono nel tuo DNS:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; sp=quarantine; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Passo 5: verificare l'allineamento DKIM

DMARCbis raccomanda adkim=s (strict) per i domini in cui controlli la firma DKIM. L'allineamento strict impedisce a un sottodominio di riutilizzare la firma di un dominio padre.

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; adkim=s; aspf=r; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Passo 6: validare le autorizzazioni di reporting esterno

Se i tuoi indirizzi rua o ruf puntano verso un dominio diverso dal dominio DMARC, verifica che il record di autorizzazione esista:

captaindns.com._dmarc-report._report.monitoring.captaindns.com. IN TXT "v=DMARC1"

Errori comuni di migrazione

Sette trappole ricorrono regolarmente durante la migrazione verso DMARCbis. Conoscerle ti eviterà sorprese in produzione.

1. Pubblicare t=y senza capire il comportamento v1. I riceventi DMARC v1 (ancora la maggioranza a marzo 2026) ignorano t=y perché è un tag sconosciuto. Applicano p=reject direttamente, senza retrocessione. Questo comportamento è previsto per design, ma sorprende spesso gli amministratori che si aspettano una modalità test universale.

2. Tenere pct=0 con t=y. Questa combinazione crea un comportamento incoerente. I riceventi v1 applicano pct=0 (nessun enforcement). I riceventi DMARCbis ignorano pct e applicano t=y (enforcement retrocesso). Risultato: due popolazioni di riceventi con comportamenti diversi. Soluzione: rimuovi pct prima di aggiungere t.

3. Tree Walk che produce un dominio organizzativo diverso dal PSL. Alcuni TLD poco comuni hanno un'entry PSL non aggiornata. Il Tree Walk può allora identificare un dominio organizzativo diverso da quello determinato dal vecchio meccanismo PSL. Mitigazione: pubblica un record _dmarc esplicito con psd=n al livello del tuo dominio organizzativo.

4. Dimenticare i record di autorizzazione di reporting esterno. Quando cambi provider di monitoring DMARC, i vecchi record _dmarc-report._report puntano verso il vecchio provider. I report cessano silenziosamente senza messaggio di errore. Aggiorna questi record a ogni cambio di provider.

5. Non testare l'impatto di np=reject. Questa policy può influire su servizi legittimi che utilizzano sottodomini dinamici. Alcuni CDN, piattaforme marketing o strumenti di campagna creano sottodomini al volo. Verifica che questi servizi non inviino email da sottodomini non registrati nel tuo DNS.

6. Fidarsi dei report di errore (ruf). I grandi provider (Google, Yahoo, Microsoft) hanno quasi cessato di inviare report di errore per ragioni di privacy e conformità GDPR. Utilizza i report aggregati (rua) come fonte principale di analisi. I report di errore sono un complemento, non una base affidabile.

7. Pianificare un deployment progressivo senza pct. Con pct rimosso in DMARCbis, il deployment per percentuale non esiste più. Le opzioni sono t=y (retrocessione completa) o enforcement completo (niente t oppure t=n). Usa t=y con finestre di monitoraggio manuali da 2 a 4 settimane per riprodurre un deployment progressivo.

DMARCbis e la conformità normativa

Conformità anti-phishing e standard di pagamento

La versione 4.0 di PCI DSS (applicabile da marzo 2025) richiede controlli anti-phishing per le entità che trattano pagamenti. DMARC in modalità enforcement (quarantine o reject) fa parte delle misure attese. DMARCbis rafforza questa postura con np=reject (protezione dei sottodomini inesistenti) e la raccomandazione di allineamento strict DKIM.

I requisiti di Google e Yahoo per l'invio massivo

Da febbraio 2024, Google e Yahoo richiedono DMARC per i mittenti di più di 5.000 messaggi al giorno. Anche se questi provider non hanno ancora implementato DMARCbis, riconosceranno i record ripuliti (senza pct, ri, rf) poiché questi tag sono già largamente ignorati.

Microsoft e Exchange Online

Microsoft applica progressivamente verifiche DMARC più restrittive su Exchange Online e Outlook. L'adozione di DMARCbis da parte di Microsoft non è ancora stata annunciata, ma la preparazione anticipata eviterà aggiustamenti dell'ultimo minuto.

Adozione attuale (marzo 2026)

L'adozione lato riceventi è ancora marginale. Solo United Internet AG (GMX, mail.com, WEB.DE) emette report in formato DMARCbis (3 reporter su 3.493 nei dati osservati). Google, Microsoft, Yahoo e Amazon SES non hanno ancora migrato. È il momento di preparare i tuoi record: quando i grandi provider passeranno a DMARCbis, sarai pronto.

Piano d'azione: preparare la transizione

1. Inventariare tutti i domini e sottodomini che pubblicano un record _dmarc. Identificare gli Author Domain reali e le zone senza record DMARC.
2. Testare con il DMARCbis Checker la compatibilità di ogni dominio. Identificare i tag obsoleti e le raccomandazioni specifiche.
3. Ripulire i record: rimuovere pct, ri, rf. Mantenere v=DMARC1.
4. Aggiungere np=reject al livello del dominio organizzativo per proteggere i sottodomini inesistenti.
5. Usare t=y per ogni scalata di policy (passaggio da quarantine a reject).
6. Rafforzare l'allineamento: puntare ad adkim=s come priorità, mantenere aspf=r salvo necessità strict.
7. Validare le autorizzazioni esterne se i tuoi indirizzi rua/ruf puntano verso un terzo.
8. Monitorare i report aggregati per 2-4 settimane dopo ogni modifica per rilevare anomalie.

FAQ

Bisogna cambiare v=DMARC1 in v=DMARC2?

No. La versione del record resta v=DMARC1. DMARCbis non modifica il tag di versione. I tuoi record esistenti continuano a funzionare senza alcuna modifica del tag v.

Cos'è il DNS tree walk?

Il DNS Tree Walk è l'algoritmo DMARCbis che sostituisce la Public Suffix List per scoprire la policy DMARC applicabile a un dominio. Interroga il DNS risalendo etichetta per etichetta dal dominio mittente (Author Domain), con un limite di 8 query, fino a trovare un record _dmarc che identifica il dominio organizzativo tramite il tag psd.

Il PSL scompare completamente?

Sì, dal punto di vista di DMARCbis. La scoperta della policy e la determinazione del dominio organizzativo passano interamente dal DNS Tree Walk. La Public Suffix List non è più referenziata nello standard. Alcuni riceventi potranno mantenere un fallback PSL durante la transizione, ma non è richiesto.

Perché il tag pct è stato rimosso?

In pratica, solo i valori 0 (modalità test) e 100 (applicazione completa) venivano utilizzati. Il comportamento per i valori intermedi variava tra i riceventi, rendendo il risultato imprevedibile. Il tag t=y/n lo sostituisce con una semantica binaria chiara: o la policy viene retrocessa di un livello (test), o si applica normalmente.

Il mio record DMARC attuale è compatibile con DMARCbis?

Sì, a condizione che il tag v=DMARC1 sia presente. DMARCbis è retrocompatibile. I tag pct, ri e rf verranno ignorati dai riceventi DMARCbis, senza provocare errori. La migrazione consigliata consiste nel rimuoverli e adottare progressivamente np, psd e t.

Posso pubblicare p=reject per tutti i miei domini?

DMARCbis sconsiglia p=reject per i domini ad uso generale (mailing list, alias, reindirizzamenti). Riserva p=reject ai domini in cui controlli ogni intermediario da capo a capo. Per gli altri casi, p=quarantine resta consigliato. I riceventi non devono rifiutare un messaggio solo perché p=reject è pubblicato: devono incrociare con altri segnali (ARC, reputazione, mailing list).

Il tag t=y è rischioso durante la transizione?

C'è un rischio calcolato. I riceventi DMARC v1 ignorano t=y (tag sconosciuto) e applicano la policy così com'è. Se pubblichi p=reject; t=y, un ricevente v1 applicherà reject senza retrocessione. Un ricevente DMARCbis applicherà quarantine. Questo comportamento è intenzionale: favorisce la sicurezza di default. Usa t=y solo se accetti che la policy restrittiva si applichi presso i riceventi che non hanno ancora migrato.

Chi deve usare il tag psd?

Solo gli operatori di suffissi pubblici: registri TLD (co.uk, com.au, gouv.fr), registri settoriali, e le grandi organizzazioni che delegano sottodomini a entità indipendenti. Per un dominio aziendale standard, lascia psd assente o indica psd=n.

Quando i grandi provider implementeranno DMARCbis?

Nessuna data è stata annunciata pubblicamente (marzo 2026). L'adozione lato riceventi è marginale: solo United Internet AG (GMX, mail.com, WEB.DE) emette report in formato DMARCbis. La pubblicazione delle RFC innescherà probabilmente l'implementazione presso i grandi provider. Preparare i tuoi record adesso ti posiziona in anticipo.

Come funziona la catena di fallback np, sp, p?

Quando un ricevente DMARCbis riceve un'email da un sottodominio, verifica prima se quel sottodominio esiste nel DNS. Se non esiste (NXDOMAIN), si applica la policy np. Se np non è definito, il ricevente usa sp. Se nemmeno sp è definito, si applica p. Per i sottodomini esistenti, il fallback è sp poi p (identico a DMARC v1).

DMARCbis rallenta l'elaborazione delle email?

No. Il Tree Walk aggiunge da 1 a 2 query DNS per un dominio tipico a 3 etichette. La cache DNS attenua questo impatto: i record _dmarc e le risposte NXDOMAIN vengono messi in cache. Il limite di 8 query garantisce un tempo di elaborazione limitato, anche per i domini profondi. In pratica, la differenza di latenza è trascurabile.

Il mio ESP deve supportare DMARCbis?

DMARCbis è un cambiamento lato ricevente. Il tuo ESP non ha bisogno di supportarlo in modo specifico. Tuttavia, verifica due punti critici: la firma DKIM personalizzata (con d= corrispondente al tuo dominio) e il Return-Path personalizzato (dominio di rimbalzo allineato con il tuo dominio From:). Questi due elementi sono indispensabili per l'allineamento strict raccomandato da DMARCbis.

Glossario

• Author Domain: dominio utilizzato nell'header From: del messaggio. È il punto di partenza del Tree Walk e dell'allineamento DMARC.
• DNS Tree Walk: algoritmo DMARCbis che risale l'albero DNS etichetta per etichetta per trovare un record _dmarc e determinare il dominio organizzativo. Limite di 8 query.
• Organizational Domain: dominio principale di un'organizzazione, identificato dal Tree Walk (tramite psd=n o assenza di psd). Fa autorità per la policy DMARC applicabile ai suoi sottodomini.
• PSL (Public Suffix List): lista mantenuta da Mozilla dei suffissi pubblici. Utilizzata da DMARC v1, sostituita dal Tree Walk in DMARCbis.
• PSD (Public Suffix Domain): suffisso di nome di dominio operato da un'entità che delega sottodomini (es.: co.uk, gouv.fr). Identificato da psd=y nel record DMARC.
• PSO (Public Suffix Operator): entità che amministra un PSD e può pubblicare una policy DMARC di riferimento per i domini collegati.

Guide email correlate

• DKIM2: cosa c'è di nuovo
• ARC: la catena di autenticazione spiegata
• BIMI, VMC, CMC: compatibilità DNS
• Gmail Bulk Sender 2025

Fonti

1. draft-ietf-dmarc-dmarcbis (IETF Datatracker)
2. draft-ietf-dmarc-aggregate-reporting (IETF Datatracker)
3. draft-ietf-dmarc-failure-reporting (IETF Datatracker)
4. DMARC.org Resources
5. PCI DSS 4.0 Summary of Changes (PCI SSC)