DMARCbis è ora un Proposed Standard dell’IETF. Sostituirà RFC 7489 e RFC 9091. I tuoi record esistenti continuano a usare v=DMARC1.
Inizia ora a pianificare così sarai pronto ad adottarlo quando verrà pubblicato.
Cos'è DMARCbis: un breve riepilogo
DMARCbis mantiene lo stesso obiettivo. Ti permette di specificare quali fonti mittenti che usano il tuo dominio sono legittime e come i destinatari dovrebbero gestire le email che non superano questi controlli. L’aggiornamento chiarisce la specifica, formalizza la conformità e cambia il modo in cui viene individuato il dominio organizzativo, utilizzando un Tree Walk DNS invece della Public Suffix List.
Cosa cambia concretamente e perché aiuta con domini complessi:
- Scoperta e allineamento sono più chiari: I destinatari cercano un record DMARC nell’Author Domain, poi nell’Organisation Domain e infine nel Public Suffix Domain. DMARCbis definisce il Tree Walk sia per la scoperta della policy sia per l’allineamento.
- Public Suffix List (PSL) fuori; Tree Walk dentro: Il Tree Walk sostituirà le ricerche PSL, permettendo di avere confini consistenti anche con sottodomini annidati e record PSD.
- Conformità esplicita: La partecipazione piena a DMARC prevede la pubblicazione di record per ogni Author e Organisational Domain, l’invio di email che si allineano tramite SPF e DKIM, e la ricezione di report aggregati.
- Migliore per DNS decentralizzati: I record possono essere pubblicati su più livelli. Per nomi host molto profondi, aggiungi un record nel Author Domain così sarà trovato prima del walk.
Le tue modifiche sono nei tag
Usa la tabella qui sotto per passare dai vecchi ai nuovi tag: imposta [t] per i test, usa [np] se vuoi una regola per nomi inesistenti, imposta [psd] solo se gestisci un public suffix, rimuovi [pct], [rf], [ri] e mantieni [v=DMARC1].
Panoramica dei tag
Tag | Significato semplice | Quando usarlo | Opzioni | Esempio |
[t] | Segnale di test per la policy che imposti in p, sp o np | Attivalo quando testi; disattivalo nel funzionamento normale | [y] test abilitato, non applicare la policy specificata ma applicare eventuali regole speciali | v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com |
[psd] | Indica che il record è pubblicato da un gestore di Public Suffix e guida il Tree Walk | Imposta solo se gestisci effettivamente un dominio public suffix (registro o simile). La maggior parte dei domini non dovrà dichiarare esplicitamente questo tag | [y] = il dominio è un PSD [n] = il dominio non è un PSD | v=DMARC1; p=quarantine; psd=y; rua=mailto:dmarc@example.com |
[np] | Policy per le email spedite usando nomi che non esistono sotto il tuo dominio | Usa se vuoi una regola esplicita per sottodomini falsi o con refusi | [none], [quarantine], [reject] | v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc@example.com |
[rf], [ri] | Vecchi suggerimenti per formato report di errore e intervallo report aggregato | Rimuovi dai record legacy | - | - |
[pct] | Vecchio controllo sul rollout percentuale | Sostituisci con [t] testing, non usare nei nuovi record | - | Vedi sotto |
Preparati a DMARCbis con Red Sift OnDMARC
Mapping [Pct] -> [t]
- [pct=0] -> usa [t=y]
- [pct=100] -> ometti il tag, non serve dichiarare esplicitamente t=n
- [pct=1-99] -> nessun equivalente diretto; usa [t=y] e gestisci il rischio in fase di test (ad esempio su domini a basso impatto).
Aggiornamento record DMARCbis: 5 rapide verifiche
1. Trova i tuoi record
Elenca il record DMARC nel tuo Organisation Domain e qualsiasi record sui principali sottodomini. Prendi nota di eventuali tag legacy pct, rf o ri, ora deprecati in DMARCbis.
2. Aggiorna la sintassi dei tag
Se non sei ancora a pct=100, sostituisci pct con il nuovo flag di test t. pct pari a zero corrisponde a t uguale a y. Se sei già a pct=100 puoi rimuovere il tag pct. Rimuovi rf e ri. Lascia fuori psd a meno che non gestisca effettivamente un public suffix domain. Mantieni v uguale a DMARC1.
3. Imposta l’ambito delle policy
Definisci p per il dominio base e sp per gli eventuali sottodomini. Aggiungi np se vuoi una regola per le email inviate a nomi inesistenti, ad esempio np uguale a reject. Se np manca, i destinatari ricadono su sp poi su p.
4. Scegli le modalità di allineamento
Usa adkim e aspf. (r indica relaxed e s indica strict). Scegli strict se desideri corrispondenza esatta tra il dominio autenticante e quello nel From.
5. Rivedi i report
Mantieni rua per i report aggregati. Usa ruf con fo solo se ti servono i dettagli dei fallimenti sui singoli messaggi. Molti destinatari non inviano report di errore e alcuni li rifiutano per motivi di privacy. Pianifica anche questo.
Perché scegliere Red Sift OnDMARC?
DMARCbis cambia il modo in cui viene trovata la policy e quali tag si utilizzano. Red Sift OnDMARC supporta nativamente queste novità, integrando DMARC, SPF e DKIM così puoi applicare l’aggiornamento rapidamente.
- Un unico posto per DMARC, SPF e DKIM - Modifica i record in parallelo, vedi i risultati degli allineamenti [adkim/aspf] e correggi i gap che impediscono l’enforcement.
- Progettato per il Tree Walk - Visualizza il nodo che il walk raggiungerà (Author -> Org -> PSD) e dove pubblicare per sottodomini profondi.
- Aggiornamento dei tag passo a passo - Usa [t], [np], [psd]; rimuovi [pct], [rf], [ri]; mantieni [v=DMARC1]. Il builder ti guida durante la procedura.
- SPF scalabile - SPF dinamico gestisce il limite di 10 lookup con un unico include che si espande al momento della query.
- Rollout più sicuro - Modella non [t=y] (un livello più morbido) prima di andare live, poi applica le modifiche in massa su più brand e regioni.
- Reporting chiaro - Le viste aggregate mettono in evidenza i disallineamenti per sorgente così sai subito cosa correggere.
Parla con il nostro team per una rapida revisione dei tuoi record ed esegui un controllo Investigate gratuito per vedere cosa segnalano i destinatari per il tuo dominio.