Panoramica di DMARCbis

Benvenuto nella sezione di documentazione di DMARCbis. Qui troverai una panoramica di DMARCbis, l'aggiornamento più significativo dello standard DMARC da quando è stato pubblicato per la prima volta.

Cos'è DMARCbis?

DMARCbis è una revisione di DMARC (Domain-based Message Authentication, Reporting, and Conformance). La designazione "bis" segue le convenzioni di denominazione standard per le revisioni dei protocolli.

La specifica DMARC originale (RFC 7489) è stata pubblicata nel 2015 come documento "Informational", mentre DMARCbis è stata rilasciata come "Proposed Standard". Questo eleva lo status formale di DMARC a quello di un protocollo di autenticazione email collaudato e ampiamente adottato, basato su oltre un decennio di esperienza di implementazione.

DMARCbis rafforza lo standard originale in questo modo:

• Suddividendo la specifica in bozze più chiare e dettagliate, con esempi aggiuntivi
• Migliorando il modo in cui vengono determinati i confini del dominio organizzativo, utilizzando ricerche native DNS invece di un elenco gestito manualmente
• Semplificando i tag di policy, eliminando elementi legacy incoerenti
• Aumentando i requisiti di reporting per una migliore visibilità e sicurezza

È fondamentale sottolineare che DMARCbis mantiene la compatibilità con le versioni precedenti. Continua a utilizzare v=DMARC1 come identificatore di versione, quindi i record DMARC esistenti rimangono validi senza alcuna modifica immediata: le organizzazioni possono adottare le nuove funzionalità in modo progressivo.

Modifiche principali in DMARCbis

Specifica ristrutturata

Lo standard aggiornato è suddiviso in tre bozze separate:

• Protocollo principale — definisce i fondamenti di DMARC
• Report aggregati — descrive come vengono generati e formattati i report giornalieri
• Report forensi — descrive in dettaglio come vengono segnalate le informazioni sui fallimenti di autenticazione

Questa suddivisione rende lo standard più facile da comprendere, implementare e mantenere nel tempo.

Algoritmo DNS Tree Walk

La modifica tecnica più significativa sostituisce la Public Suffix List (PSL) con un algoritmo di DNS Tree Walk per individuare il confine organizzativo di un dominio.

Invece di affidarsi a un elenco pubblico gestito manualmente, un destinatario interroga livelli successivi della gerarchia del dominio, risalendo un'etichetta alla volta, finché non trova un record DNS contrassegnato come psd=y (un dominio a suffisso pubblico) o psd=n (un confine organizzativo).

• La ricerca è limitata a otto livelli per evitare un numero eccessivo di interrogazioni DNS.
• Per i domini con otto o più etichette, le etichette più a sinistra vengono rimosse finché non ne rimangono sette, prima che la ricerca abbia inizio.
• La ricerca si interrompe non appena viene trovato un record DMARC valido con un valore psd esplicito.

Questo approccio nativo DNS elimina la dipendenza da un elenco di terze parti, rendendo più probabile che le modifiche ai confini vengano rilevate in modo coerente e migliorando complessivamente l'accuratezza del rilevamento dei confini di dominio.

Nota: durante la fase di transizione, alcuni destinatari potrebbero ancora utilizzare la PSL mentre altri utilizzano il Tree Walk, il che può occasionalmente produrre risultati diversi per lo stesso dominio. Pubblicare un record DMARC esplicito su ogni dominio e sottodominio, includendo un tag psd dove rilevante, evita ambiguità.

Nuovi tag di policy

DMARCbis introduce tre nuovi tag per un controllo più granulare:

Tag	Scopo
psd (Public Suffix Domain)	y indica che il dominio è un dominio a suffisso pubblico, n indica che è un dominio organizzativo. Il valore predefinito, u, lascia che sia il Tree Walk a determinarlo.
np (Non-Existent Subdomain Policy)	Imposta la policy applicata alle email che dichiarano di provenire da un sottodominio che non esiste nel DNS, chiudendo una lacuna di spoofing in cui gli attaccanti utilizzano sottodomini fittizi come ceo.example.com.
t (Testing Mode)	Segnala che una policy è in fase di prova e non ancora applicata (y), oppure applicata normalmente (n, il valore predefinito).

Tag legacy deprecati

Tre tag sono stati dismessi perché producevano risultati incoerenti tra i vari destinatari:

• pct (percentuale) — sostituito dal più chiaro tag t (Testing Mode)
• rf (formato del report)
• ri (intervallo del report) — la cadenza dei report è ora definita in modo uniforme anziché essere configurabile

Questi tag vengono ancora pubblicati laddove impostati, per compatibilità con le versioni precedenti, ma i destinatari compatibili con DMARCbis faranno sempre più affidamento sui loro sostituti.

Reporting migliorato

I report aggregati e forensi hanno ora ciascuno una propria bozza di specifica, con requisiti più rigorosi in termini di coerenza e sicurezza:

• Convalida obbligatoria degli indirizzi di reporting esterni (il destinatario rua=/ruf= deve autorizzare i report inviati al di fuori del dominio mittente)
• Formattazione e convenzioni di denominazione degli allegati standardizzate
• Applicazione più rigorosa della struttura XML e della compressione gzip

Linee guida sulle mailing list

DMARCbis fornisce indicazioni esplicite su mailing list ed email inoltrate. Sconsiglia di pubblicare una policy p=reject nei casi in cui le mailing list fanno parte del normale flusso di posta, poiché il software delle mailing list spesso interrompe sia l'allineamento SPF che quello DKIM, il che può causare il rifiuto di messaggi legittimi.

Allo stesso tempo, DMARCbis continua a incoraggiare i proprietari di dominio a lavorare verso una policy p=reject ovunque sia fattibile, poiché è l'unica policy che protegge completamente un dominio da usi non autorizzati. Il consiglio è di valutare il proprio ecosistema di posta, incluse eventuali mailing list, prima di passare a un'applicazione rigorosa.

Vantaggi principali

• Rilevamento più accurato del dominio organizzativo tramite l'algoritmo DNS Tree Walk
• Tag di policy più semplici e chiari, con segnali di test inequivocabili
• Protezione più solida contro lo spoofing di sottodomini inesistenti
• Miglior supporto per strutture di dominio complesse e domini a suffisso pubblico
• Maggiore coerenza e sicurezza nel reporting
• Nessuna migrazione forzata: i record esistenti restano validi mentre adotti le nuove funzionalità ai tuoi tempi

Domande frequenti

Devo modificare il mio attuale record DMARC per DMARCbis?

Non sono richieste modifiche immediate. DMARCbis mantiene lo stesso identificatore di versione (v=DMARC1), quindi i record esistenti rimangono validi. Puoi adottare i nuovi tag in modo progressivo per rafforzare nel tempo l'autenticazione delle tue email.

In che modo il DNS Tree Walk migliora rispetto alla Public Suffix List?

Invece di affidarsi a un elenco gestito manualmente di suffissi pubblici, il Tree Walk interroga direttamente il DNS, risalendo la gerarchia del dominio per identificare il corretto confine organizzativo. Questo approccio è più coerente, poiché non dipende da una terza parte che mantiene aggiornato un elenco.

Dovrei impostare una policy p=reject ora che DMARCbis la sconsiglia per le mailing list?

DMARCbis non sconsiglia del tutto p=reject: invita alla cautela specificamente nei casi in cui le mailing list fanno parte del tuo flusso di posta, poiché possono interrompere l'allineamento SPF/DKIM. Verifica come vengono effettivamente inviate e inoltrate le email del tuo dominio prima di passare a un'applicazione rigorosa.

Argomenti correlati

• Panoramica DMARC — Introduzione a DMARC e al suo scopo
• Sintassi DMARC — Informazioni dettagliate sui campi del record DNS DMARC
• Impostazioni DMARC — Configura i tag DMARCbis come Testing Mode e Non-Existent Subdomain Policy