DMARCbis Checker

DMARCbis: cosa cambia per il tuo dominio

DMARCbis (chiamato anche DMARC v2) non è un semplice aggiornamento. È una riscrittura completa del protocollo DMARC, suddivisa in tre RFC distinti. Un DMARCbis checker rivela esattamente quali modifiche sono necessarie:

1. Meccanismo principale (RFC 9989): scoperta della policy, alignment, valutazione
2. Report aggregati (RFC 9990): formato XML, schema, distribuzione
3. Report di errore (RFC 9991): report ARF, privacy, rate limiting

Nuovi tag

Tag rimossi

Tree walk DNS

Il cambiamento più significativo di DMARCbis è la sostituzione della Public Suffix List (PSL) con un algoritmo di percorso DNS nativo.

Perché? La PSL è una lista comunitaria mantenuta da volontari Mozilla. Soffre di ritardi negli aggiornamenti, incoerenze tra implementazioni e l'assenza di una specifica IETF sulla versione da utilizzare. Il tree walk DNS risolve questi problemi basandosi esclusivamente sui dati DNS reali.

Come funziona: il server ricevente interroga _dmarc.<dominio>, poi risale di un label per ogni passaggio. Se un record contiene psd=n, quello è il dominio organizzativo. Se viene trovato psd=y, il dominio un livello sotto è il dominio organizzativo.

Chi adotta DMARCbis oggi?

Preparati fin da ora

Anche se la migrazione non è urgente, preparare il tuo dominio fin da ora permette di:

• Identificare i tag obsoleti da rimuovere prima che generino avvisi
• Aggiungere il tag np per proteggere i sottodomini inesistenti
• Comprendere il tree walk e verificare che il dominio organizzativo sia determinato correttamente
• Anticipare i cambiamenti nel reporting nei tuoi strumenti di analisi DMARC

DMARC vs DMARCbis: tabella comparativa

Questa tabella riassume le differenze strutturali tra le due versioni del protocollo. Se il tuo record contiene tag della colonna DMARC che non esistono più in DMARCbis, il checker li segnala automaticamente.

Come funziona il tree walk DNS?

Il tree walk DNS è l'innovazione principale di DMARCbis. Sostituisce le ricerche nella Public Suffix List con un percorso gerarchico nel DNS. Ecco un esempio dettagliato per comprendere ogni passaggio.

Esempio: un'email ricevuta da user@sub.mail.captaindns.com

Il server ricevente deve trovare la policy DMARC applicabile. Con DMARCbis, esegue le seguenti query in ordine:

1. Query _dmarc.sub.mail.captaindns.com: il server DNS risponde NXDOMAIN (nessun record trovato). Il server ricevente sale di un label.
2. Query _dmarc.mail.captaindns.com: il server DNS risponde NXDOMAIN. Il server ricevente sale ancora.
3. Query _dmarc.captaindns.com: viene trovato un record TXT, ad esempio v=DMARC1; p=reject; psd=n.

Il tag psd=n indica che captaindns.com è un dominio organizzativo (non un public suffix). Il tree walk si ferma. Risultato: dominio organizzativo = captaindns.com, metodo di scoperta = tree walk.

Cosa succede con psd=y? Se _dmarc.captaindns.com contenesse psd=y, significherebbe che captaindns.com è un public suffix (come .co.uk). In tal caso, il dominio organizzativo sarebbe mail.captaindns.com, il dominio un livello sotto il suffix.

Limite di sicurezza: il tree walk esegue un massimo di 8 query DNS per prevenire l'amplificazione. Oltre 8 livelli senza risultato, la scoperta fallisce e il dominio viene trattato come se non avesse una policy DMARC pubblicata.

Vantaggio chiave: a differenza della PSL, che richiede aggiornamenti manuali e varia tra le implementazioni, il tree walk si basa sui dati DNS in tempo reale. Gli amministratori DNS mantengono il pieno controllo sui confini della propria organizzazione.

Perché il tag np è essenziale

Il tag np (non-existent subdomain policy) colma una lacuna di sicurezza che DMARC v1 non poteva risolvere: lo spoofing di sottodomini inesistenti.

Il vettore di attacco: un aggressore invia un'email da fake123.captaindns.com. Questo sottodominio non esiste nella tua zona DNS. Con DMARC v1, il server ricevente applica la policy sp (se presente) o ricade su p. Se la tua configurazione è p=reject; sp=none (una configurazione comune per consentire sottodomini legittimi), l'aggressore aggira la tua protezione.

La soluzione DMARCbis: il tag np=reject si applica esclusivamente ai sottodomini per i quali il DNS risponde NXDOMAIN. Puoi mantenere una policy flessibile sui tuoi sottodomini esistenti (sp=none o sp=quarantine per i sottodomini con flussi email legittimi) bloccando al contempo i sottodomini inventati dagli aggressori.

Configurazione raccomandata:

• Se p=reject: aggiungi np=reject per la massima copertura
• Se p=quarantine: aggiungi np=reject (i sottodomini fittizi meritano un blocco rigoroso)
• Se p=none: aggiungi np=quarantine come primo passo verso il rafforzamento

Il tag np è particolarmente efficace contro gli attacchi di CEO fraud, in cui gli aggressori inventano sottodomini credibili come secure-payment.captaindns.com o internal-hr.captaindns.com per ingannare i destinatari.

Cronologia di adozione di DMARCbis

La transizione verso DMARCbis segue una cronologia graduale guidata dall'IETF e dai principali provider email.

Le RFC 9989, 9990 e 9991 sono state pubblicate a maggio 2026. La migrazione ora consiste nel rimuovere i tag storici e verificare np e il tree walk DNS.

Strumenti complementari

Risorse utili

• RFC 7489 - DMARC
• RFC 9989 - DMARC
• RFC 9091 - PSD DMARC
• DMARCbis: tutti i cambiamenti e come prepararsi

FAQ - Domande frequenti

D: Cos'è DMARCbis?

R: DMARCbis è la revisione pubblicata a maggio 2026 come RFC 9989, RFC 9990 e RFC 9991. La RFC 9989 rende obsoleta la RFC 7489 senza modificare v=DMARC1; standardizza il tree walk DNS e np, mentre pct, rf e ri diventano tag storici.

D: Quali sono le differenze tra DMARC e DMARCbis?

R: DMARCbis aggiunge tre nuovi tag (np, t, psd), rimuove tre tag (pct, rf, ri), sostituisce la scoperta tramite Public Suffix List con un algoritmo tree walk DNS e limita la validazione SPF esclusivamente al MAIL FROM.

D: Devo migrare subito a DMARCbis?

R: Non c'è urgenza. I record DMARC attuali continuano a funzionare perché la versione resta v=DMARC1. Tuttavia, si consiglia di verificare i propri record fin da ora per rimuovere i tag obsoleti e aggiungere i nuovi tag np e psd.

D: Il tag pct viene davvero rimosso?

R: Sì. L'esperienza operativa ha dimostrato che il tag pct veniva applicato in modo incoerente dai server riceventi. Solo i valori 0 e 100 erano affidabili. Viene sostituito dal tag binario t (t=y per la modalità test, t=n per l'applicazione completa).

D: Cos'è il tree walk DNS?

R: Il tree walk DNS è l'algoritmo di scoperta della policy DMARC in DMARCbis. Invece di consultare una Public Suffix List esterna, il server ricevente risale la gerarchia DNS interrogando _dmarc a ogni livello fino a trovare un record valido. Questo elimina la dipendenza dalla PSL.

D: Il tag fo viene rimosso in DMARCbis?

R: No. Il tag fo (failure reporting options) viene mantenuto in DMARCbis. Solo i tag pct, rf e ri vengono rimossi.

D: Come faccio a sapere se il mio dominio è pronto per DMARCbis?

R: Esegui un'analisi con il nostro DMARCbis checker. Lo strumento esegue un tree walk DNS completo, rileva i tag obsoleti (pct, rf, ri), verifica la presenza del tag np e mostra il dominio organizzativo scoperto. Il risultato indica uno stato chiaro: conforme, compatibile o non conforme a DMARCbis.

D: Il tree walk DNS rallenta la consegna delle email?

R: No. Il tree walk esegue un massimo di 8 query DNS e i server riceventi memorizzano i risultati nella cache in base al TTL di ogni record. Nella pratica, per la maggior parte dei domini, il tree walk si risolve in 2 o 3 query. L'impatto sui tempi di consegna è trascurabile.