Nel 2015, lo IETF ha pubblicato DMARC (RFC 7489) come RFC Informational e, negli undici anni successivi, la sua adozione è rimasta in una certa misura opzionale. In quanto RFC Informational, non esisteva una standardizzazione rigida del protocollo al di là degli sforzi dei provider di caselle di posta. Anche in quei casi, vi erano ambiguità che diversi fornitori risolvevano in modo diverso. Mentre attori principali come Google, Yahoo e Microsoft potevano avviare cambiamenti all’interno del settore (e stabilire requisiti per i mittenti di email massivi), l’ecosistema email si è evoluto dalla pubblicazione della specifica originale.
Questo cambiamento sta arrivando rapidamente. Nel maggio 2026, lo IETF ha pubblicato la RFC 9989, nota comunemente come DMARCbis, che ufficialmente porta quest’atteso aggiornamento di DMARC allo status di Proposed Standard. Questa RFC, insieme alla RFC 9990 (report aggregati) e alla RFC 9991 (report di errore), avvicina DMARC a diventare un vero Internet Standard. Il documento aggiornato formalizza DMARC affinché rispecchi il funzionamento attuale dell’email. Insieme al prossimo documento DKIM2 in bozza, stabiliscono una base per l’autenticazione delle email nel mondo di oggi.
Comprendere le nuove RFC
Tutte e tre le RFC sono sul percorso degli Standard come Proposed Standards. Nel processo IETF, Proposed Standard è il primo e più comune passo verso la standardizzazione. Significa che la specifica ha superato la revisione della comunità, ha raggiunto un consenso generale, ed è considerata sufficientemente stabile per l’implementazione.
- RFC 9989 è la specifica fondamentale del protocollo DMARC. Definisce come i proprietari dei domini pubblicano la policy, come i riceventi valutano i messaggi rispetto ad essa e cosa accade quando l’autenticazione fallisce. Questa RFC sostituirà la RFC 7489 come riferimento autorevole per DMARC.
- RFC 9990 riguarda i report aggregati. Sono i report XML giornalieri che i riceventi inviano ai proprietari dei domini, mostrano quali indirizzi IP hanno inviato email per loro conto e come si sono comportate rispetto a SPF, DKIM e ai controlli DMARC. Se hai mai consultato i dati RUA, questa è la specifica che ne regola il contenuto e le modalità di consegna.
- RFC 9991 tratta i report di errore. A differenza dei report aggregati, i report di errore sono quasi in tempo reale e per singolo messaggio. Quando un singolo messaggio fallisce l’autenticazione DMARC, un report di errore fornisce al proprietario del dominio informazioni dettagliate su quel messaggio. Sono richiesti tramite il tag ruf nel tuo record DMARC e sono utili per diagnosticare rapidamente eventuali vulnerabilità d’autenticazione.
Cosa è diverso rispetto alla precedente RFC che trattava DMARC?
Sebbene l’attribuzione di Proposed Standard sia importante, lo sono anche i cambiamenti tecnici introdotti dalla suite.
Innanzitutto, il tag pct verrà eliminato. Questo tag consentiva ai mittenti di applicare la policy DMARC solo a una percentuale delle email fallite, con conseguente applicazione incoerente tra i riceventi. Ora, DMARC dovrà essere applicato a tutto il traffico, senza eccezioni. Se hai utilizzato pct come configurazione a lungo termine invece che come meccanismo di transizione, è il momento di completare la migrazione. L’aggiornamento introduce il nuovo tag t=y o t=n per definire una modalità di test che sostituisce di fatto l’uso di pct. Altri due tag eliminati, raramente usati, sono rf e ri.
Anche il supporto al Public Suffix Domain (PSD) ora fa formalmente parte della specifica principale. Il cambiamento principale riguarda l’identificazione dei public suffix. In passato, i riceventi utilizzavano la Public Suffix List, un elenco aggiornato manualmente ai cui operatori ci si doveva iscrivere e confidare che tutti i riceventi avessero una copia aggiornata. PSD ora lo sostituisce con un DNS Tree Walk: i public suffix vengono identificati direttamente dal DNS, controllati dagli stessi operatori, funzionando ovunque senza dover aspettare l’aggiornamento di una lista.
Inoltre, il tag psd=n consente di designare i sottodomini come Organizational Domains. Questo ha effetti sull’allineamento e sull’ereditarietà delle policy.
Sul fronte dei report, il lavoro ora è stato suddiviso deliberatamente. La RFC 9990 definisce il formato dei report aggregati come standard, compreso lo schema XML, la gestione dei cambi di policy durante il periodo di reportistica e i requisiti di consegna. La RFC 9991 fa lo stesso con i report di errore: report quasi in tempo reale, per singolo messaggio, che aiutano i titolari dei domini a individuare specifici fallimenti di autenticazione. Entrambi i documenti sono ora Standard Track, e questo offre ai riceventi criteri di conformità molto più chiari di quanto non fosse possibile con il precedente modello a documento unico.
Nota pratica sui report di errore: la RFC 9991 specifica esplicitamente che questi possono includere intestazioni complete del messaggio e il contenuto del corpo, che possono contenere dati personali identificabili.
Cosa devono fare ora i mittenti
Se la tua configurazione DMARC è correttamente impostata sull’enforcement, a livello operativo oggi non cambia nulla. La RFC 9989 non invalida i record esistenti né richiede la ripubblicazione degli stessi. Tuttavia, ci sono alcune azioni da considerare:
- Verifica l’utilizzo del tag
pct. I riceventi potrebbero tollerare ancora il tag durante una fase di transizione, ma lo scopo della nuova specifica è chiaro. - Rivaluta p=none. La comunità ha concordato formalmente cosa significa una corretta implementazione DMARC e i mittenti che restano all’infinito in modalità monitoring sono sempre più fuori asse rispetto all’evoluzione del settore.
In breve: mantieni la calma
DMARC che diventa uno Standard Proposto non cambia istantaneamente il panorama delle minacce, ma indica che siamo un passo più vicini a riconoscere le migliori pratiche sull’intero protocollo. Queste RFC rappresentano un ottimo progresso per l’email e per Internet nel suo complesso. Un ecosistema digitale più sicuro è vantaggioso per tutti e raggiungere presto il giusto livello di enforcement ti salva da molti problemi quando DMARC diventerà finalmente uno Standard Internet.
Se vuoi sapere qual è la situazione attuale dei tuoi domini, Red Sift Investigate verifica la configurazione per DMARC, SPF, DKIM, BIMI, MTA-STS e TLS inviando una vera email, non