Perché validare la sintassi DMARC prima della pubblicazione?
Un record DMARC mal formattato viene ignorato silenziosamente da Gmail, Outlook, Yahoo e da tutti i server destinatari. Non viene emesso alcun avviso. Le tue email restano senza protezione contro spoofing e phishing.
Il validatore legge il tuo record prima della pubblicazione DNS, controlla ogni tag e verifica gli URI di report. Correggi gli errori subito, senza aspettare 24-48 ore di propagazione per scoprire che un dettaglio impedisce l'applicazione della policy.
Tag DMARC secondo l'RFC 9989
La RFC 9989 definisce ogni tag ammesso in un record DMARC. Il validatore verifica nome, posizione e valore di ogni tag.
| Tag | Ruolo | Esempio |
|---|---|---|
| v | Versione del protocollo, sempre in prima posizione | v=DMARC1 |
| p | Policy applicata al dominio principale | p=quarantine |
| sp | Policy applicata ai sottodomini | sp=reject |
| np | Policy per sottodomini inesistenti | none / quarantine / reject |
| t | Modalità di test RFC 9989 | y / n |
| adkim | Modalità di allineamento DKIM, r (rilassato) o s (stretto) | adkim=s |
| aspf | Modalità di allineamento SPF, r o s | aspf=r |
| pct | Tag storico / deprecato, intervallo 0-100 | Omettere |
| rua | Destinazioni dei report aggregati (URI mailto) | rua=mailto:dmarc@captaindns.com |
| ruf | Destinazioni dei report forensi (URI mailto) | ruf=mailto:forensic@captaindns.com |
| fo | Opzioni di generazione dei report forensi | fo=1 |
I tag v e p sono obbligatori. Se omessi, adkim e aspf assumono il valore r. È consigliato omettere pct, ormai un tag storico.
Esempi di correzione prima e dopo
Il validatore segnala ogni errore di sintassi con la sua posizione. Di seguito tre casi frequenti rilevati su record pubblicati.
URI rua mal formato:
- v=DMARC1; p=reject; rua=reports@captaindns.com
+ v=DMARC1; p=reject; rua=mailto:reports@captaindns.com
Il prefisso mailto: è obbligatorio secondo l'RFC 9989.
Policy p non valida:
- v=DMARC1; p=monitor; rua=mailto:dmarc@captaindns.com
+ v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com
Sono accettati solo i valori none, quarantine e reject.
pct fuori intervallo:
- v=DMARC1; p=quarantine; pct=150; rua=mailto:dmarc@captaindns.com
+ v=DMARC1; p=quarantine; rua=mailto:dmarc@captaindns.com
Il valore pct è fuori dall'intervallo 0-100; la correzione consiste nell'omettere pct.
Diagnosi comuni del validatore
Il validatore restituisce un codice breve per ogni anomalia rilevata. I codici seguenti sono i più frequenti.
| Codice | Causa | Azione |
|---|---|---|
| missing_version_tag | Tag v=DMARC1 assente | Aggiungere v=DMARC1 in prima posizione |
| unsupported_version | Valore di v= diverso da DMARC1 | Sostituire con v=DMARC1 |
| missing_policy | Tag p= assente | Aggiungere p=none, p=quarantine o p=reject |
| invalid_policy | Valore di p= fuori da none/quarantine/reject | Correggere il valore |
| invalid_subdomain_policy | Valore di sp= non valido | Usare none, quarantine o reject |
| invalid_alignment | Valore di adkim= o aspf= diverso da r/s | Impostare su r o s |
| invalid_percent | pct= fuori dall'intervallo 0-100 | Usare un intero tra 0 e 100 |
| invalid_rua_uri | URI rua mal formato | Usare mailto:indirizzo@dominio |
| invalid_ruf_uri | URI ruf mal formato | Usare mailto:indirizzo@dominio |
| invalid_failure_option | Valore fo= non riconosciuto | Usare 0, 1, d o s |
| duplicate_tag | Tag dichiarato due volte | Conservare una sola occorrenza |
| unknown_tag | Nome del tag non riconosciuto | Verificare l'ortografia con l'RFC 9989 |
| np_absent | np assente | Verificare l'ereditarietà da sp o p |
| deprecated_pct | pct storico presente | Rimuovere pct |
| testing_mode_active | t=y attivo | Il punteggio riflette l'applicazione effettiva della policy |
| migrate_to_dmarcbis | Tag storici rilevati | Usare lo strumento di migrazione per ripulire il record |
| record_trailing_quote | Stringa TXT che termina con una virgoletta | Rimuovere la virgoletta finale |
I codici di avviso (policy_none, pct_less_than_100, subdomain_policy_none) indicano una configurazione valida da verificare. pct_less_than_100 riguarda un tag storico: con la RFC 9989 bisogna omettere pct, non impostare pct=100.
FAQ - Domande frequenti
Quale progressione adottare per la policy p=?
Inizia sempre con p=none per osservare il traffico tramite report aggregati (rua). Una volta che SPF e DKIM sono allineati su tutte le tue fonti legittime, passa a p=quarantine e poi a p=reject. Evita di saltare direttamente a p=reject: i report rua della fase di osservazione rivelano quasi sempre flussi legittimi dimenticati.
Devo configurare ruf oltre a rua?
Non all'inizio. I report rua aggregati (giornalieri) sono essenziali per guidare il tuo rollout. I report forensi ruf (per messaggio fallito) generano un volume importante e possono contenere dati personali. Attivali solo se disponi di una pipeline di analisi e di un parere legale sulla raccolta di questi dati.
Devo configurare il tag sp= sui sottodomini?
Per impostazione predefinita, i sottodomini ereditano la policy p. Configura sp= solo se la policy dei sottodomini deve differire dal dominio principale. Verifica che SPF e DKIM siano allineati su ogni sottodominio mittente prima di irrigidire sp=.
Il validatore applica le regole DMARCbis?
DMARCbis è stato pubblicato a maggio 2026 come RFC 9989, RFC 9990 e RFC 9991. La RFC 9989 rende obsoleta la RFC 7489; v=DMARC1 non cambia. DMARCbis Checker spiega il tree walk DNS e lo strumento di migrazione rimuove i tag storici.
Strumenti complementari
| Strumento | Utilità |
|---|---|
| DMARC Checker | Verificare la pubblicazione e risolvere il record DMARC dal DNS |
| Generatore DMARC | Creare un record DMARC conforme alle specifiche |
| Validatore SPF | Validare la sintassi SPF del tuo dominio |
| Validatore DKIM | Validare la sintassi di una chiave DKIM |
| Migrazione DMARCbis | Migrare un record DMARC verso il nuovo standard |
| Monitoring DMARC | Ricevi e analizza automaticamente i tuoi report DMARC aggregati |