Perché migrare a DMARCbis?
DMARCbis succede alla RFC 7489 pubblicata nel 2015. La bozza introduce quattro cambiamenti strutturali:
- Rimozione di
pct,rf,ri: la policy si applica ora al 100% del traffico per impostazione predefinita, resta definito un solo formato di report e l'intervallo di invio è imposto per impostazione predefinita. Il tagfoviene mantenuto. - Aggiunta di
np: la policy dei sottodomini inesistenti diventa esplicita, chiudendo una falla sfruttata dagli attaccanti che inventano sottodomini fittizi. - Conversione di
pct<100int=y: la modalità di test sostituisce la percentuale. Più semplice, più prevedibile, più allineata al comportamento reale dei ricevitori. - Tree walk DNS per identificare il dominio organizzativo, in sostituzione della Public Suffix List.
Il suo record DMARC attuale continua a funzionare durante la transizione. Migrare ora significa essere pronti alla pubblicazione ufficiale e beneficiare immediatamente della protezione dei sottodomini inesistenti tramite np.
Come funziona l'analizzatore
Lo strumento analizza il suo record DMARC v1, applica le trasformazioni DMARCbis e calcola un punteggio di compatibilità DMARCbis su 100. Il calcolo è locale, senza risoluzione DNS né chiamata esterna.
I cinque verdetti possibili
| Verdetto | Punteggio | Significato |
|---|---|---|
| Già conforme | da 90 a 100 | Nessun cambiamento necessario o aggiustamento minore. Monitori la pubblicazione ufficiale del RFC. |
| Migrazione parziale | da 75 a 89 | Da una a tre modifiche minori (tipicamente pct=100 ridondante o np assente). |
| Migrazione maggiore | da 50 a 74 | Quattro cambiamenti o più. Diversi tag deprecati presenti e policy debole. |
| Record invalido | da 0 a 49 o stato invalido | Errori di sintassi da correggere prima della migrazione. |
| Nessun record | N/A | Campo vuoto. Incolli prima un record DMARC prima dell'analisi. |
Le sei dimensioni del punteggio
| Dimensione | Ponderazione | Cosa misura la dimensione |
|---|---|---|
| Tag deprecati assenti | 40 punti | Presenza di pct, rf, ri. Più ne sono presenti, maggiore la deduzione. |
Tag np presente | 15 punti | Policy sottodomini inesistenti esplicita. Eredita da sp o p se assente. |
| Forza della policy | 20 punti | reject ottiene il massimo, quarantine una frazione, none un credito minimo. |
| Allineamento DKIM e SPF | 10 punti | adkim=s e aspf=s ottengono il massimo, r ne mantiene una parte. |
Reporting rua configurato | 10 punti | URI mailto valida per l'invio aggregato. |
| Igiene sintattica | 5 punti | Record ben formato e analizzabile. |
Tre fattori prioritari vengono mostrati in cima al risultato per spiegare immediatamente il punteggio, prima del dettaglio dimensione per dimensione.
I cambiamenti chiave DMARC a DMARCbis
Tag rimossi
| Tag | Azione | Perché |
|---|---|---|
pct | Rimuovere | La policy si applica al 100% per impostazione predefinita. Se pct<100, lo strumento converte il valore in t=y. |
rf | Rimuovere | Resta definito un solo formato di report in DMARCbis. |
ri | Rimuovere | I ricevitori impongono un intervallo di report predefinito. |
Tag aggiunto
| Tag | Valore | Perché |
|---|---|---|
np | eredita da sp o p | Policy per i sottodomini inesistenti. Deve essere esplicita in DMARCbis. |
Tag conservati invariati
v=DMARC1, p, sp, adkim, aspf, rua, ruf. La loro semantica resta identica.
Piano di migrazione consigliato
Passo 1: verificare il record attuale. Avvii l'analisi con il suo record DMARC pubblicato. Annoti il punteggio, il verdetto e le raccomandazioni.
Passo 2: applicare le modifiche proposte. Copi il record migrato e lo pubblichi nella sua zona DNS a _dmarc.captaindns.com. Conservi il record precedente per 48 ore con un TTL breve (300 secondi) per consentire un rollback rapido se necessario.
Passo 3: monitorare i report rua. Per due o quattro settimane, verifichi i suoi report DMARC aggregati per confermare l'assenza di impatto sui flussi legittimi. Il passaggio a np può rivelare sottodomini attivi non documentati.
Passo 4: stabilizzare il TTL. Una volta validati i report, riporti il TTL a 3600 o 86400 secondi. La migrazione è completata.
Se passa anche da una policy permissiva a p=reject, usi t=y per alcune settimane. I ricevitori DMARCbis applicano allora una policy di un livello inferiore, che funge da rete di sicurezza durante la fase di validazione.
Errori comuni da evitare
Conservare pct=100. Questo valore è ridondante in DMARCbis. L'intero tag può essere rimosso senza modificare il comportamento.
Confondere np e sp. sp mira ai sottodomini esistenti, np mira esclusivamente ai sottodomini inesistenti. I due tag sono complementari, non intercambiabili.
Combinare pct e t. In DMARCbis, t ha sempre la precedenza. Non ha senso conservare pct quando t=y è presente.
Rimuovere rua durante la pulizia. Il reporting aggregato è l'unica fonte di verità sull'efficacia della sua policy. Conservi rua=mailto:reports@captaindns.com (o il suo indirizzo dedicato) nel record migrato.
Migrare senza rileggere i report esistenti. Prima di irrigidire la policy, verifichi quali mittenti legittimi non sono ancora allineati SPF o DKIM. Migrare a p=reject senza questa verifica può bloccare flussi interni.
Dichiarare psd=y senza essere un registry. Il tag psd=y è riservato agli operatori di suffissi pubblici come .bank o .gov.uk. Per un dominio organizzativo standard, ometta il tag o usi psd=n se desidera renderlo esplicito.
Strumenti correlati
| Strumento | Utilità |
|---|---|
| DMARCbis Checker | Verificare un dominio pubblicato contro DMARCbis con tree walk DNS |
| DMARC Checker | Verificare la pubblicazione e risolvere il record DMARC dal DNS |
| DMARC Validator | Validare la sintassi di un record DMARC v1 prima della pubblicazione |
| Generatore DMARC | Creare un record DMARC o DMARCbis da zero |
| Lettore report DMARC | Decodificare report aggregati XML |
| Monitoring DMARC | Ricevi e analizza automaticamente i tuoi report DMARC aggregati |