Vai al contenuto principale

DMARC Validator

Valida la sintassi DMARC prima della pubblicazione e correggi gli errori in pochi secondi

Come correggere gli errori di sintassi DMARC? Incolla il tuo record DMARC qui sotto e valida la sintassi istantaneamente. Un errore di sintassi DMARC significa che la tua policy viene ignorata silenziosamente da Gmail, Outlook e tutti i server destinatari.

Cosa verifichiamo

  • Sintassi e conformità a RFC 7489
  • Policy (p, sp) e livello di protezione
  • Allineamento DKIM e SPF
  • Copertura (pct) e reporting (rua, ruf)

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 la RFC 7489

La RFC 7489 definisce ogni tag ammesso in un record DMARC. Il validatore verifica nome, posizione e valore di ogni tag.

TagRuoloEsempio
vVersione del protocollo, sempre in prima posizionev=DMARC1
pPolicy applicata al dominio principalep=quarantine
spPolicy applicata ai sottodominisp=reject
adkimModalità di allineamento DKIM, r (rilassato) o s (stretto)adkim=s
aspfModalità di allineamento SPF, r o saspf=r
pctPercentuale di messaggi soggetti alla policy, da 1 a 100pct=50
ruaDestinazioni dei report aggregati (URI mailto)rua=mailto:dmarc@captaindns.com
rufDestinazioni dei report forensi (URI mailto)ruf=mailto:forensic@captaindns.com
foOpzioni di generazione dei report forensifo=1

I tag v e p sono obbligatori. Gli altri tag ricadono su valori predefiniti se omessi (adkim=r, aspf=r, pct=100).

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 la RFC 7489.

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; pct=100; rua=mailto:dmarc@captaindns.com

Il valore pct deve essere un intero tra 1 e 100.

Diagnosi comuni del validatore

Il validatore restituisce un codice breve per ogni anomalia rilevata. I codici seguenti sono i più frequenti.

CodiceCausaAzione
missing_version_tagTag v=DMARC1 assenteAggiungere v=DMARC1 in prima posizione
unsupported_versionValore di v= diverso da DMARC1Sostituire con v=DMARC1
missing_policyTag p= assenteAggiungere p=none, p=quarantine o p=reject
invalid_policyValore di p= fuori da none/quarantine/rejectCorreggere il valore
invalid_subdomain_policyValore di sp= non validoUsare none, quarantine o reject
invalid_alignmentValore di adkim= o aspf= diverso da r/sImpostare su r o s
invalid_percentpct= fuori dall'intervallo 1-100Usare un intero tra 1 e 100
invalid_rua_uriURI rua mal formatoUsare mailto:indirizzo@dominio
invalid_ruf_uriURI ruf mal formatoUsare mailto:indirizzo@dominio
invalid_failure_optionValore fo= non riconosciutoUsare 0, 1, d o s
duplicate_tagTag dichiarato due volteConservare una sola occorrenza
unknown_tagNome del tag non riconosciutoVerificare l'ortografia con la RFC 7489
record_trailing_quoteStringa TXT che termina con una virgolettaRimuovere la virgoletta finale

I codici di avviso (policy_none, pct_less_than_100, subdomain_policy_none) segnalano una configurazione valida ma parziale: la protezione rimane incompleta finché la policy resta su none o pct è inferiore a 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?

Questa versione applica le regole della RFC 7489. Per anticipare la transizione a DMARCbis (rimozione di pct, ri, rf, aggiunta di np, psd, t), usa il DMARCbis Checker o lo strumento di migrazione DMARCbis.


Strumenti complementari

StrumentoUtilità
DMARC CheckerVerificare la pubblicazione e risolvere il record DMARC dal DNS
Generatore DMARCCreare un record DMARC conforme alle specifiche
Validatore SPFValidare la sintassi SPF del tuo dominio
Validatore DKIMValidare la sintassi di una chiave DKIM
Migrazione DMARCbisMigrare un record DMARC verso il nuovo standard
Monitoring DMARCRicevi e analizza automaticamente i tuoi report DMARC aggregati

Letture consigliate

Riferimento: RFC 7489 - Domain-based Message Authentication, Reporting and Conformance.