Gli RFC 9989, 9990 e 9991 relativi a DMARC sostituiscono l'RFC 7489

Dopo anni di lavoro all’interno del gruppo di lavoro DMARC dell’IETF, è stato pubblicato l’aggiornamento tanto atteso dello standard DMARC. Tre nuovi documenti, RFC 9989, RFC 9990 e RFC 9991, sostituiscono ora formalmente l'originale RFC 7489 del 2015. Sebbene non si tratti di un termine ufficiale, questi RFC erano noti nella comunità con il nome collettivo di DMARCbis e sono ora pubblicati come specifica DMARC aggiornata con lo stesso numero di versione.

Le nuove specifiche sono state pubblicate nel maggio 2026 e hanno fatto passare DMARC dal precedente status di "Informational" a quello di "Proposed Standard" nell'ambito dell'IETF Standards Track. Si tratta di un passo avanti significativo, poiché conferisce a DMARC un ruolo più solido e formale nel panorama degli standard Internet.

Cosa tratta ogni RFC

La specifica DMARC è stata suddivisa in tre documenti distinti anziché in un unico file di grandi dimensioni. L'RFC 9989 contiene il protocollo di base, che include la valutazione delle politiche, le regole di allineamento e l'elaborazione dei record. L'RFC 9990 definisce il formato di segnalazione aggregato (RUA). L'RFC 9991 riguarda i rapporti di errore, spesso denominati rapporti forensi.

Il tuo record DMARC esistente funziona ancora

Uno degli aspetti più importanti per i proprietari di domini è che non si tratta di una modifica che comporta l'incompatibilità. L'identificatore del protocollo rimane lo stesso, quindi i record continuano a iniziare con v=DMARC1. Non è necessario modificare la configurazione né ripubblicare tutti i record da un giorno all'altro.

Se vuoi rinfrescarti la memoria su come sono strutturati i record, la nostra guida sui tag DMARC illustra in dettaglio ogni campo.

Principali modifiche tecniche

Ci sono alcuni aggiornamenti degni di nota, e vale la pena approfondirne un paio prima di intervenire sul proprio record.

L'elenco dei suffissi pubblici è stato sostituito dal DNS Tree Walk

I destinatari non si affidano più alla Public Suffix List, gestita esternamente, per individuare il dominio organizzativo. Al contrario, risalgono la gerarchia DNS e cercano i record _dmarc a ogni livello. In pratica, un destinatario parte dal dominio in questione e interroga progressivamente le etichette di livello superiore, fino a un massimo di otto ricerche, finché non trova un record DMARC pubblicato. Ciò elimina la dipendenza da terze parti e migliora l'accuratezza nel caso di strutture di dominio complesse.

C’è un’implicazione pratica che vale la pena sottolineare. Poiché il Tree Walk risolve il dominio organizzativo in modo diverso rispetto al vecchio metodo del Public Suffix List, un destinatario che utilizza lo standard RFC 9989 potrebbe, in alcuni casi, ottenere un dominio organizzativo diverso rispetto a un destinatario che utilizza ancora lo standard RFC 7489. Se gestite una gerarchia complessa di sottodomini o utilizzate domini delegati, l’approccio più sicuro consiste nel pubblicare un record DMARC esplicito su ogni dominio e sottodominio da cui inviate effettivamente e-mail. Ciò elimina ogni ambiguità riguardo alla politica applicabile, indipendentemente dalla versione utilizzata da un determinato destinatario.

Nuovi tag: np, psd e t

L'RFC 9989 introduce tre nuovi tag. Ecco a cosa serve ciascuno di essi e in quali casi è opportuno utilizzarli.

np (politica sui sottodomini inesistenti)

Il tag sp consente già di impostare una politica per i sottodomini, ma np fa un ulteriore passo avanti separando la politica per i sottodomini che non esistono affatto, ovvero per cui il DNS restituisce NXDOMAIN. Ciò colma una vera e propria lacuna relativa allo spoofing dei sottodomini, poiché gli aggressori spesso falsificano messaggi provenienti da sottodomini che non sono mai stati registrati. Ad esempio, un record del tipo v=DMARC1; p=none; np=reject; non applicherebbe alcuna politica al dominio principale e ai suoi sottodomini autentici, ma rifiuterebbe comunque le e-mail provenienti da quelli inesistenti. Se il vostro dominio è già impostato su p=reject o sp=reject, la politica rigorosa viene ereditata automaticamente, quindi np=reject non aggiunge nulla e non è necessaria alcuna modifica. Se avete una politica meno rigorosa ma desiderate una protezione mirata contro questo specifico attacco, vale sicuramente la pena aggiungere np=reject.

t (modalità di prova)

Questo è il tag che più facilmente può essere interpretato in modo errato. Impostare t=y non disabilita la politica. Al contrario, richiede ai destinatari di applicare la politica immediatamente meno restrittiva rispetto a quella pubblicata: una politica di rifiuto viene trattata come quarantena, una politica di quarantena viene trattata come “nessuna” e “nessuna” rimane invariata. Si tratta di un comportamento molto più preciso rispetto al vecchio comportamento pct che sostituisce di fatto. Un avvertimento importante: non tutti i destinatari supportano ancora la RFC 9989, quindi alcuni ignoreranno semplicemente t=y. Durante il periodo di transizione, l’approccio più sicuro consiste nell’utilizzare sia pct che t insieme, in modo che sia i destinatari più vecchi che quelli più recenti comprendano la vostra intenzione. Un record a più livelli potrebbe apparire come v=DMARC1; p=reject; pct=50; t=y;. Per ulteriori informazioni su questo cambiamento, potete consultare la nostra nota precedente sul motivo per cui t sostituisce pct.

psd (dominio con suffisso pubblico)

Questo tag aiuta i destinatari a determinare il dominio organizzativo durante la scansione dell'albero DNS. La maggior parte dei normali proprietari di domini dovrebbe semplicemente ometterlo. È rilevante solo in due situazioni: nel caso di un'organizzazione che desideri dichiarare un confine deliberato del dominio organizzativo a livello di sottodominio (impostando psd=n in quel punto), oppure nel caso di un gestore di un dominio con suffisso pubblico come .bank o .gov (impostando psd=y). Si tenga presente che i destinatari che utilizzano ancora lo standard RFC 7489 ignoreranno completamente questo tag, pertanto esso non sostituisce una corretta progettazione dei record.

Sono stati rimossi tre tag: pct, rf e ri

La RFC 9989 elimina tre tag. Nessuna di queste rimozioni causerà problemi ai record esistenti, ma è opportuno comprendere la funzione di ciascun tag e come gestirne l'eliminazione. Si veda la sezione dedicata qui di seguito.

Indicazioni più chiare sulle mailing list e sull'inoltro dei messaggi

I flussi di posta indiretti continuano a compromettere l'allineamento tra SPF e DKIM, e la nuova specifica lo riconosce apertamente. Sconsiglia l'adozione di politiche aggressive di tipo "p=reject" nei contesti in cui è frequente il traffico delle mailing list, il che riflette il comportamento effettivo della posta elettronica nel mondo reale.

Conformità meglio definita

Il nuovo testo chiarisce cosa si intenda per “piena partecipazione al DMARC” sia per i mittenti che per i destinatari, il che dovrebbe ridurre le implementazioni frammentarie che da anni rappresentano un problema.

Rimosso il limite di dimensione degli URI nei report

Una modifica minore che può facilmente passare inosservata: la RFC 9989 ha eliminato la possibilità di specificare una dimensione massima del report nell'URI di segnalazione. I record che utilizzavano un suffisso di dimensione, come ad esempio rua=mailto:[email protected]!10m, non hanno più alcun significato e i destinatari dovrebbero ora ignorare qualsiasi limite di dimensione associato a un indirizzo rua o ruf. Se i vostri URI di segnalazione includono questa sintassi, potete tranquillamente rimuovere la parte relativa al limite di dimensione.

Comprendere i tag rimossi

Se il tuo record attuale utilizza pct, rf o ri, ecco esattamente a cosa serviva ciascuno di essi e cosa dovresti fare ora.

pct (percentuale)

Questo tag è stato progettato per consentire l'implementazione graduale di una politica, applicandola a una percentuale selezionata di messaggi. In pratica, è stato implementato in modo non uniforme tra i vari ricevitori, generando risultati imprevedibili, ed è stato sostituito dal tag t, più pulito. Se si continua a fare affidamento su pct, d'ora in poi non bisogna basarsi esclusivamente su di esso. Durante la fase di transizione, la mossa più sensata è quella di utilizzare contemporaneamente pct e t=y, in modo che sia i client più datati sia quelli conformi alla RFC 9989 comprendano che si sta procedendo gradualmente verso l’applicazione della politica.

rf (formato del rapporto)

Questo tag specificava il formato dei rapporti di errore, ma l'unico valore mai valido era "afrf", il che lo rendeva di fatto superfluo. È possibile rimuoverlo in tutta sicurezza da qualsiasi record in cui compaia.

ri (intervallo di segnalazione)

Questo tag definiva l'intervallo richiesto tra i rapporti aggregati, espresso in secondi. La maggior parte dei destinatari lo ignorava e utilizzava semplicemente l'impostazione predefinita di un rapporto giornaliero; l'RFC 9989 formalizza ora tale prassi, richiedendo ai destinatari di inviare rapporti aggregati almeno una volta al giorno. Lasciare questo tag in essere non comporta alcun rischio, ma è sempre più irrilevante e non si dovrebbe fare affidamento su di esso.

Come aggiornare il record DMARC secondo la specifica RFC 9989?

La pubblicazione della RFC 9989 non comporta alcuna incompatibilità con ciò che già possiedi. Il tuo record rimane nella stessa posizione: un record TXT DNS su _dmarc.tuodominio.com, e il tag di versione è ancora v=DMARC1.

Allora perché aggiornarlo? Perché l’RFC 9989 riflette il funzionamento effettivo della posta elettronica dopo un decennio di implementazione nel mondo reale, e vale la pena integrare fin da ora alcune delle sue modifiche nel proprio sistema, piuttosto che scoprirle in un secondo momento.

Ecco cosa dovrebbero fare i titolari di domini

I titolari dei domini possono seguire la checklist riportata di seguito per aggiornare dinamicamente i propri record:

Rimuovi i tag rf e ri. Entrambi sono obsoleti e possono essere eliminati in tutta sicurezza.
Replace pct with t: use t=y for testing (in place of any pct<100), or drop the tag for full enforcement (t=n is the default)
Valuta la possibilità di aggiungere `np=reject` se desideri bloccare lo spoofing proveniente da sottodomini inesistenti senza modificare la tua politica principale.
Rimuovi il suffisso che indica il limite di dimensione dell'URI di segnalazione, se i tuoi record rua o ruf ne contengono uno.
Non includere "psd" a meno che non sia necessario dichiarare intenzionalmente un confine di dominio organizzativo o si gestisca un dominio con suffisso pubblico.
Pubblica record DMARC espliciti per ogni dominio e sottodominio da cui invii e-mail, per evitare qualsiasi ambiguità relativa al DNS Tree Walk tra i destinatari che seguono lo standard RFC 9989 e quelli che seguono lo standard RFC 7489.

Per un'analisi più approfondita delle modifiche e per sapere come preparare i propri record, consulta la nostra guida completa su DMARCbis.

Un record aggiornato secondo lo standard RFC 9989 si presenta così:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s

Notate cosa manca: non c'è la percentuale. Per implementarla in modo sicuro, aggiungete “t=y”, lasciate che i report aggregati si accumulino, quindi rimuovetela quando sarete pronti per l'applicazione completa.

Noterete inoltre che in questo record mancano due tag validi secondo lo standard RFC 9989 – t e psd – e ciò è intenzionale, poiché entrambi sono da utilizzare in contesti specifici piuttosto che come standard.

Il tag "t" indica la modalità di test temporanea: va aggiunto solo durante la fase di transizione verso l'applicazione definitiva delle regole, poiché indica ai destinatari di applicare la politica immediatamente inferiore rispetto a quella pubblicata. Il tag "psd", invece, è un flag che dichiara un dominio come suffisso pubblico. Gli operatori di suffissi pubblici devono impostare "psd=y", ma per un normale proprietario di dominio l'impostazione predefinita (u) è quella corretta, quindi è sufficiente omettere il tag.

Assicurati che la tua piattaforma DMARC sia pronta

Non tutti gli strumenti disponibili sul mercato si sono ancora adeguati ai nuovi standard, e questa lacuna è significativa. Se la tua piattaforma non è in grado di leggere i nuovi tag o di elaborare i report nel formato aggiornato, perdi visibilità proprio nel momento in cui il protocollo si sta evolvendo.

PowerDMARC è già conforme alle nuove specifiche e supporta:

Generazione di record compatibili con RFC 9989, 9990 e 9991
Analisi sintattica dei nuovi tag np, psd e t
RFC 9990: acquisizione e generazione di report aggregati
Gestione dei domini organizzativi basata sull'albero DNS
Comportamento di elaborazione aggiornato che riflette le nuove regole di conformità

Se vuoi verificare come il tuo record attuale si conforma al nuovo standard, inseriscilo nel nostro strumento gratuito di verifica DMARC e controlla cosa è necessario correggere.

Parole finali

Le RFC aggiornate non costituiscono un nuovo protocollo. Si tratta dello stesso DMARC, riscritto in modo più chiaro e elevato allo status di standard. Dopo oltre un decennio di implementazione nel mondo reale, la specifica riflette ora il funzionamento effettivo della posta elettronica, comprese le sue parti più complesse, come l'inoltro e le mailing list.

Per chiunque si occupi della sicurezza dei domini, la pubblicazione delle RFC 9989, 9990 e 9991 rappresenta un ottimo spunto per verificare i propri record e assicurarsi che gli strumenti in uso siano pronti per i nuovi tag e per l'approccio DNS Tree Walk.

Informazioni su
Ultimi messaggi

Ahona Rudra

Esperto di sicurezza dei domini e delle e-mail presso PowerDMARC

Ahona è la Marketing Manager di PowerDMARC, con oltre 5 anni di esperienza nella scrittura di argomenti di cybersecurity, specializzata in sicurezza dei domini e delle e-mail. Ahona ha conseguito una laurea in Giornalismo e Comunicazione, consolidando la sua carriera nel settore della sicurezza dal 2019.

Ultimi messaggi di Ahona Rudra (vedi tutti)

Gli RFC 9989, 9990 e 9991 relativi al DMARC sostituiscono l'RFC 7489