DMARC è ora uno standard IETF proposto: la vostra organizzazione è pronta?

Dopo undici anni in cui è stato ampiamente adottato come convenzione della comunità senza uno status formale nell’ambito dell’IETF, il DMARC è ora un documento dello Standards Track dell’IETF. La RFC 9989, pubblicata nel maggio 2026, rende obsoleta la RFC 7489 e colloca il DMARC nello stesso percorso di standardizzazione (Standards Track) di protocolli fondamentali quali SMTP e IMAP. Per la maggior parte delle organizzazioni, ciò potrebbe apparire come una semplice nota tecnica. Non lo è.

Perché il cambiamento di stato è importante

Il documento RFC 7489 originale è stato pubblicato nel 2015 tramite l’Independent Submission Stream dell’IETF, il che significa che non godeva del peso formale derivante dal consenso dell’IETF; proprio per questo motivo le implementazioni hanno preso direzioni divergenti e alcune lacune sono rimaste irrisolte per anni. La RFC 9989 apporta le seguenti modifiche: i requisiti di DMARC riflettono ora il consenso formale dell’IETF, sottoposti a revisione da parte della comunità e approvati dall’IESG.

La conseguenza pratica è che i settori regolamentati e i quadri normativi in materia di appalti dispongono ora di un riferimento citabile e stabile per rendere obbligatoria l’adozione del DMARC. Uno standard proposto dall’IETF è il tipo di documento che viene integrato nelle linee guida di sicurezza governative, nelle linee guida del settore finanziario e nei quadri di riferimento aziendali relativi alla gestione dei rischi dei fornitori. La direttiva NIS2 dell’UE e il regolamento DORA impongono già alle organizzazioni di attuare misure di sicurezza per la posta elettronica; la RFC 9989 fornisce a tali quadri normativi un preciso riferimento tecnico.

Alla RFC 9989 si affiancano due standard di riferimento. La RFC 9990 riguarda la segnalazione aggregata, mentre la RFC 9991 riguarda la segnalazione degli errori; entrambe costituiscono ora standard proposti a sé stanti. Separare la funzione di segnalazione dal protocollo di base rende più chiare le aspettative relative all’implementazione sia per i mittenti che per i destinatari e per i fornitori di strumenti.

L’aspetto dell’assicurazione contro i rischi informatici che non dovreste trascurare

Al di là della conformità tecnica, gli assicuratori del settore informatico stanno tenendo conto dello stato di conformità al protocollo DMARC nelle decisioni di sottoscrizione, e la RFC 9989 è destinata a rendere tale valutazione ancora più rigorosa. Il documento “Prospettive sulle condizioni del mercato delle assicurazioni contro i rischi informatici per il 2025” di Gallagher evidenzia che gli assicuratori stanno valutando in modo più approfondito il livello di sicurezza delle organizzazioni, indicando espressamente l’autenticazione delle e-mail, insieme all’autenticazione a più fattori (MFA), all’EDR e alle procedure di backup, come fattori che influenzano la determinazione dei premi e la disponibilità delle coperture.

Nelle richieste di sottoscrizione presentate dai principali operatori viene ormai abitualmente chiesto se le organizzazioni abbiano implementato SPF, DKIM e DMARC. Ma la questione che si cela dietro quella casella di selezione è, sempre più spesso, se la politica venga effettivamente applicata. Un’impostazione p=none, che monitora i flussi di posta elettronica ma non interviene in caso di messaggi non recapitati, rappresenta un segnale meno incisivo per i sottoscrittori rispetto alle impostazioni p=quarantine o p=reject. Le organizzazioni che adottano il livello p=none come impostazione permanente potrebbero essere soggette a un esame più approfondito al momento del rinnovo, a condizioni meno favorevoli o a limiti di copertura ridotti.

Cinque cambiamenti che i team IT devono comprendere

I record esistenti che iniziano con v=DMARC1 rimangono pienamente validi, senza alcuna scadenza per la migrazione. Tuttavia, diversi cambiamenti strutturali incideranno sul comportamento delle ricerche DNS, sulla gestione dei report e sulla strategia di implementazione.

1. Vengono rimossi tre tag: pct=, rf= e ri=

Il tag pct= (implementazione basata sulla percentuale) è stato eliminato; in pratica veniva utilizzato raramente con sfumature specifiche. È stato inoltre rimosso il tag rf= (formato del report): è stato infatti utilizzato un solo formato. Inoltre, ri= (intervallo di segnalazione richiesto) viene eliminato; la RFC 9989 raccomanda ai destinatari di inviare segnalazioni su base giornaliera. Se i Suoi record contengono ancora questi tag, non si verifica alcun problema — i tag sconosciuti vengono ignorati silenziosamente, come previsto dalla RFC 9989 §4.7 — ma è possibile eliminarli.

2. Il tag t= sostituisce pct= con un comportamento prevedibile e graduale

Il tag t= può assumere due valori. La modalità di verifica dei segnali t=y: l'impostazione p=quarantena, se combinata con t=y, considera i messaggi non conformi come se fossero p=nessuno; l'impostazione p=rifiuto, se combinata con t=y, li considera come se fossero p=quarantena — un approccio leggermente più flessibile rispetto alla politica dichiarata. t=n (impostazione predefinita) applica la politica in modo normale. Ciò risolve l'ambiguità che rendeva pct= incoerente tra le diverse implementazioni.

3. Nuovo tag: np= per i sottodomini inesistenti

La RFC 9989 introduce il parametro "np=", che definisce una politica DMARC specifica per i sottodomini inesistenti, ovvero quelli privi di record DNS. In precedenza, questi valori rientravano nella categoria "sp=" oppure assumevano per impostazione predefinita il valore "p=" del dominio organizzativo. A volte gli autori degli attacchi inviano messaggi da sottodomini che non esistono nel sistema DNS, sfruttando tale ambiguità. Il tag "np=" conferisce ai proprietari dei domini un controllo esplicito.

4. Il DNS Tree Walk sostituisce l’elenco dei suffissi pubblici

In precedenza, l’individuazione dei domini organizzativi si basava sulla Public Suffix List (PSL), un database esterno statico e gestito manualmente. L'RFC 9989 sostituisce tale approccio con l'algoritmo DNS Tree Walk, che percorre dinamicamente la gerarchia DNS a partire dal dominio indicato nell'intestazione From: fino a individuare il record TXT _dmarc pertinente, eliminando così una nota fonte di errata attribuzione delle politiche nelle strutture di dominio complesse.

5. Il supporto al formato PSD e il tag "psd=" sono ora integrati nel nucleo del sistema

Il supporto per i domini con suffisso pubblico era in precedenza in fase sperimentale (RFC 9091). L'RFC 9989 rende obsoleta l'RFC 9091 e integra la gestione dei PSD nella specifica di base. Il tag "psd=" è ora uno standard e non più in fase sperimentale — aspetto particolarmente rilevante per le organizzazioni che operano con domini di secondo livello con codice paese, quali .co.uk.

Cosa comporta ciò per il settore

Per le organizzazioni che si trovano ancora al livello p=none, la RFC 9989 inasprisce i requisiti su due fronti contemporaneamente. I quadri di riferimento per gli audit e i requisiti in materia di appalti dispongono ora di uno standard formale e citabile a cui fare riferimento, e i mandati specifici per settore si baseranno sempre più sulla RFC 9989 piuttosto che sul suo predecessore di natura informativa. Allo stesso tempo, la pressione da parte del settore assicurativo affinché si proceda all’applicazione delle norme si sta intensificando indipendentemente dai fattori che determinano la conformità.

Il percorso verso l’applicazione delle misure rimane invariato: priorità alla visibilità, identificazione di ogni fonte di invio e risoluzione di ogni errore SPF e DKIM prima che la politica diventi più rigorosa. È opportuno sottolineare un cambiamento tecnico significativo: la RFC 9989 sconsiglia espressamente l’uso di p=reject per i flussi di posta indiretti, comprese le mailing list e l’inoltro; i destinatari sono invitati a trattare tali casi come p=quarantine anziché respingerli immediatamente.

Nessuna delle soluzioni attualmente implementate presenta malfunzionamenti. Tuttavia, le organizzazioni che adottano l’impostazione “p=none” come politica permanente sono esposte su tre fronti: il rischio di spoofing che già presentavano, uno standard con un peso formale tale da figurare nei criteri normativi di riferimento e nelle valutazioni dei rischi dei fornitori, nonché un mercato delle assicurazioni contro i rischi informatici che distingue sempre più chiaramente tra autenticazione monitorata e autenticazione imposta.

Rimanere all’avanguardia con Mimecast

Mimecast sta monitorando attentamente l'adozione della RFC 9989 e degli standard ad essa correlati. Per le organizzazioni che utilizzano Mimecast DMARC Analyzer, la transizione dovrebbe avvenire senza intoppi. La piattaforma offre una visibilità costante che consente di gestire lo stato di autenticazione dei domini man mano che gli standard e le aspettative in materia di applicazione delle norme si evolvono. Nell’ambito di una piattaforma più ampia che serve oltre 42.000 organizzazioni in tutto il mondo, Mimecast aiuta i team di sicurezza a stare al passo con i requisiti di conformità e assicurativi che ora convergono sull’applicazione dello standard DMARC.

Desidera capire cosa comporta la RFC 9989 per la Sua implementazione di DMARC e in che modo possiamo aiutarLa? Prenoti una dimostrazione e si rivolga a uno dei nostri esperti.

Fonti:

• RFC 9989 (IETF, maggio 2026) — https://www.rfc-editor.org/rfc/rfc9989
• Prospettive relative alle condizioni del mercato delle assicurazioni contro i rischi informatici per il 2025 secondo Gallagher (citato in base all’analisi di AutoSPF, maggio 2026) — https://autospf.com/blog/email-authentication-cyber-insurance-dmarc-pricing-underwriters-2026-insurance-applications/
• BindLedger, DMARC, SPF e DKIM per i rinnovi delle polizze assicurative contro i rischi informatici (marzo 2026) — https://www.bindledger.com/blog/dmarc-spf-dkim-for-cyber-insurance