Migrazione DMARC a DMARCbis

Guida alla migrazione da DMARC a DMARCbis

Perché migrare?

La migrazione da DMARC a DMARCbis non impone alcuna scadenza. I tuoi record DMARC attuali continuano a funzionare. Tuttavia, usare uno strumento di migrazione consente di:

• Proteggere i sottodomini inesistenti con il tag np, chiudendo una falla sfruttata dagli attaccanti
• Semplificare la gestione rimuovendo i tag ignorati dai ricevitori moderni
• Dichiarare il proprio ambito organizzativo con psd=n, chiarendo la gerarchia DNS per i ricevitori

Passaggi della migrazione

1. Rimuovere i tag obsoleti

2. Aggiungere il tag np

Scegli una policy per i sottodomini inesistenti:

• np=reject: raccomandato se p=reject (protezione massima)
• np=quarantine: approccio intermedio
• np=none: solo monitoraggio

Se np è assente, si applica la policy di sp (poi quella di p).

3. Valutare il tag t

• Se attualmente usi pct=0 per la modalità di test, passa a t=y
• Se la tua policy è pienamente applicata, nessuna azione necessaria (il valore predefinito t=n è equivalente)
• Non combinare pct e t: t ha sempre la precedenza

4. Dichiarare psd se pertinente

• Dominio organizzativo (captaindns.com): psd=n dichiara che non sei un suffisso pubblico
• Registry (.bank, .gov.uk): psd=y consente la pubblicazione di una policy per tutti i registranti
• Predefinito: psd=u (indeterminato), il tree walk DNS determina il dominio organizzativo

Esempio di migrazione

Prima:

v=DMARC1; p=reject; sp=quarantine; pct=100; ri=86400; rua=mailto:dmarc@captaindns.com

Dopo:

v=DMARC1; p=reject; sp=quarantine; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

Modifiche:

• pct=100 rimosso (equivalente al valore predefinito t=n)
• ri=86400 rimosso (ignorato dai ricevitori)
• np=reject aggiunto (protezione dei sottodomini inesistenti)
• psd=n aggiunto (dichiarazione dell'ambito organizzativo)

Esempi concreti di migrazione

Ecco tre scenari rappresentativi che puoi incontrare durante la migrazione del tuo record DMARC a DMARCbis.

Scenario 1: record con pct parziale

Prima:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@captaindns.com

Dopo:

v=DMARC1; p=quarantine; t=y; np=quarantine; rua=mailto:dmarc@captaindns.com

Il valore pct=50 significa che la policy veniva applicata solo alla metà dei messaggi. In DMARCbis, questo approccio granulare viene sostituito da una modalità binaria. Il tag t=y attiva la modalità di test: i ricevitori DMARCbis applicano la policy di un livello inferiore (quarantine diventa none). Il tag np=quarantine eredita dalla policy p per proteggere i sottodomini inesistenti.

Scenario 2: record rigoroso senza tag obsoleti

Prima:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@captaindns.com

Dopo:

v=DMARC1; p=reject; sp=reject; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

Questo record è già pulito: nessun tag obsoleto da rimuovere. Basta aggiungere np=reject per coprire i sottodomini inesistenti e psd=n per dichiarare che il dominio non è un suffisso pubblico. La migrazione consiste nell'aggiungere due tag senza modificare la policy esistente.

Scenario 3: record con tutti i tag obsoleti

Prima:

v=DMARC1; p=reject; pct=100; ri=86400; rf=afrf; rua=mailto:dmarc@captaindns.com

Dopo:

v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@captaindns.com

Qui vengono rimossi tre tag obsoleti contemporaneamente. pct=100 corrisponde al comportamento predefinito (applicazione completa), quindi non è necessario il tag t. ri=86400 non ha mai influenzato realmente la frequenza dei report. rf=afrf era l'unico valore possibile, ora implicito. Il tag np=reject viene aggiunto per una protezione completa.

Cosa succede durante la transizione?

Il periodo di transizione tra DMARC e DMARCbis non presenta alcun rischio per la consegna delle tue email. Ecco perché:

• I tag sconosciuti vengono ignorati: i ricevitori che non supportano ancora DMARCbis ignorano semplicemente i tag np, t e psd. Continuano ad applicare p, sp e rua come prima.
• La versione resta v=DMARC1: DMARCbis non modifica l'identificatore di versione. Nessun ricevitore rifiuterà il tuo record a causa dell'aggiornamento.
• Il tag t nella pratica: un ricevitore DMARCbis applica la modalità di test se t=y è presente. Un ricevitore DMARC v1 non riconosce t e applica direttamente la policy p al 100%. Questo significa che durante la transizione, le tue email beneficiano del livello di protezione più elevato tra i due standard.
• Adozione progressiva: i grandi provider (Google, Microsoft, Yahoo) adottano le nuove specifiche in modo graduale. La coesistenza dei due comportamenti è prevista per durare diversi anni.
• Nessuna azione urgente necessaria: i tuoi record DMARC attuali restano funzionali. La migrazione può procedere al tuo ritmo, senza finestra di manutenzione né interruzione di servizio.

Strategia di rollout raccomandata

Per migrare in sicurezza, segui questi quattro passaggi nell'ordine:

Passaggio 1: Verificare il record attuale. Usa il nostro DMARCbis Checker per analizzare il tuo record DMARC pubblicato. Lo strumento identifica i tag obsoleti e valuta la conformità DMARCbis.

Passaggio 2: Rimuovere i tag obsoleti. Elimina pct, rf e ri dal tuo record. Questi tag non hanno più effetto in DMARCbis e la loro presenza appesantisce inutilmente la tua configurazione DNS.

Passaggio 3: Aggiungere i nuovi tag. Aggiungi np=reject (o la policy di tua scelta) per proteggere i sottodomini inesistenti. Aggiungi psd=n per dichiarare esplicitamente il tuo ambito organizzativo. Entrambe le aggiunte rafforzano la tua postura di sicurezza email senza modificare la policy principale.

Passaggio 4: Testare prima di applicare. Se stai passando da una policy permissiva (none o quarantine) a una policy rigorosa (reject), usa t=y per alcune settimane. Monitora i tuoi report aggregati DMARC per verificare che nessun flusso legittimo sia impattato. Una volta validati i report, rimuovi il tag t (il valore predefinito t=n applica la policy integralmente).

Errori comuni da evitare

Dimenticare di disattivare la modalità di test. Il tag t=y è utile durante la fase di validazione, ma riduce intenzionalmente il livello di protezione. Imposta un promemoria per passare a t=n (o rimuovere il tag) dopo il tuo periodo di test.

Confondere np con sp. Il tag sp definisce la policy per i sottodomini esistenti. Il tag np si rivolge esclusivamente ai sottodomini inesistenti, quelli che gli attaccanti fabbricano per aggirare le protezioni. Entrambi i tag svolgono ruoli distinti e complementari.

Rimuovere accidentalmente il tag rua. Durante la pulizia del tuo record, assicurati di mantenere il tag rua che punta al tuo indirizzo per i report aggregati. Senza reporting, perdi ogni visibilità sui tentativi di spoofing e i problemi di allineamento.

Dichiarare psd=y senza essere un registry. Il tag psd=y è riservato ai registry di suffissi pubblici (come .bank o .gov.uk). Se sei proprietario di un dominio organizzativo standard, usa psd=n. Una dichiarazione errata potrebbe inviare un segnale sbagliato ai ricevitori e complicare il tree walk DNS.

Migrare senza consultare i report esistenti. Prima di modificare il tuo record, analizza i tuoi report aggregati DMARC recenti. Rivelano quali mittenti legittimi non sono ancora allineati SPF o DKIM. Migrare senza questa verifica rischia di bloccare flussi email legittimi durante il passaggio a una policy più rigorosa.

Strumenti correlati

Prima di migrare, verifica la compatibilità DMARCbis attuale del tuo dominio con il DMARCbis Checker. Il checker esegue un'analisi tree walk DNS completa e rileva tutti i tag obsoleti.

Per un audit DMARC completo, esplora questi strumenti:

• Validatore DMARC per validare la sintassi del tuo record DMARC
• Ispettore DMARC per consultare e analizzare il record DMARC pubblicato sul tuo dominio
• Generatore DMARC per creare un nuovo record DMARC
• Lettore report DMARC per decodificare i report aggregati XML

Scopri di più sui cambiamenti del protocollo: DMARCbis: tutti i cambiamenti e come prepararsi.