Analisi e struttura dei record DMARC
Il protocollo DMARC (Domain-based Message Authentication, Reporting, and Conformance) consente ai proprietari di domini di posta elettronica di proteggere la propria identità da usi non autorizzati, definendo come i server riceventi devono gestire i messaggi che non superano i controlli di autenticazione. Un record DMARC è una stringa di testo pubblicata come record DNS TXT.
La corretta configurazione di questo record è essenziale per garantire che le politiche di sicurezza vengano applicate senza interrompere il flusso dei messaggi legittimi. Lo strumento di verifica analizza la sintassi del record fornito, esamina i singoli tag e identifica eventuali discrepanze rispetto agli standard correnti.
Requisiti di sintassi e il tag v=DMARC1
Ogni record DMARC deve rispettare regole sintattiche precise per poter essere interpretato correttamente dai server di posta riceventi.
- Inizio del record: Il record deve tassativamente iniziare con il valore case-sensitive
v=DMARC1. Se questo tag non è presente all'inizio, il record non viene riconosciuto. In caso di errore, lo strumento segnala "Il record deve iniziare con v=DMARC1." o "Termine‹position›: v=DMARC1 deve essere il primo termine.". - Formato dei tag: I parametri all'interno del record devono essere strutturati come coppie nome=valore separate da punti e virgola. Se la struttura non è corretta, viene generato l'errore "name=value ✕ (
‹position›)". - Gestione delle virgolette: Nel DNS, i record TXT lunghi possono essere suddivisi in più segmenti racchiusi tra virgolette. Lo strumento accetta e unisce automaticamente questi segmenti prima di procedere con l'analisi, mostrando la nota "I segmenti TXT DNS tra virgolette sono stati uniti prima dell'analisi.".
- Limiti di dimensione: Il record inserito deve avere una lunghezza inferiore a 20.000 caratteri. Se si supera questa soglia, l'interfaccia mostra l'errore "Questo record è insolitamente grande. Mantienilo sotto i 20.000 caratteri.".
Le politiche DMARC per domini e sottodomini (p, sp, np)
Le direttive di policy indicano ai server riceventi quale azione intraprendere quando un'email fallisce l'autenticazione SPF e DKIM.
Politica del dominio principale (p)
Il tag p definisce la politica per il dominio principale. Se questo tag non è presente nel record, la politica del dominio scende implicitamente a none. Lo strumento segnala questa condizione con la nota "p → none".
La presenza di una politica p=none indica che il dominio è in modalità di solo monitoraggio: i report vengono richiesti, ma non viene applicata alcuna restrizione sui messaggi non autenticati. L'analisi evidenzia questo comportamento con la nota "p=none".
Politiche per i sottodomini (sp e np)
- sp (Subdomain Policy): Specifica la politica da applicare ai sottodomini del dominio principale.
- np (Non-existent Subdomain Policy): Specifica la politica per i sottodomini che non esistono nel DNS.
In assenza di tag specifici per i sottodomini, i sistemi di ricezione applicano un meccanismo di fallback gerarchico: se manca np, si fa riferimento a sp; se manca anche sp, si applica la politica generale p.
Modalità di test (t=y)
Il tag t=y attiva la modalità di test. Questa configurazione riduce la severità delle azioni applicate dai server riceventi per consentire verifiche senza rischi di blocco: la politica quarantine viene declassata a none, mentre la politica reject viene declassata a quarantine. Lo strumento evidenzia questa transizione temporanea con la nota "t=y: reject → quarantine; quarantine → none".
Configurazione dei report (rua e ruf)
DMARC offre visibilità sui flussi di posta inviati a nome del dominio attraverso due canali di reportistica.
Report aggregati (rua)
I report aggregati forniscono dati statistici sui volumi di posta e sullo stato di autenticazione. Vengono inviati agli indirizzi specificati nel tag rua. Se non viene configurato alcun indirizzo valido, i report aggregati non vengono richiesti, generando la nota "rua=∅".
Report di errore o di fallimento (ruf)
I report di fallimento contengono dettagli sui singoli messaggi che non superano i controlli. Vengono inviati agli indirizzi definiti nel tag ruf.
Il tag fo (opzioni di generazione dei report di fallimento) dipende direttamente dalla presenza di una destinazione valida per questi report. Se il tag ruf è vuoto o non valido, il tag fo viene ignorato dai sistemi riceventi. Lo strumento segnala questa ridondanza con la nota "fo → ∅ (ruf=∅)".
Limitazioni obsolete sui report
Nelle vecchie specifiche, era possibile aggiungere un suffisso di dimensione agli URI di report (ad esempio !size). Secondo lo standard corrente, questo suffisso è obsoleto e deve essere ignorato dai server riceventi. Lo strumento rileva questa configurazione mostrando la nota "!size → ∅ (RFC 9989)".
Tag storici e allineamento (pct, adkim, aspf)
L'evoluzione degli standard DMARC ha modificato l'uso e l'interpretazione di alcuni parametri.
+------------------+-------------------+--------------------------------------------------+
| Tag | Stato Standard | Comportamento e Impatto |
+------------------+-------------------+--------------------------------------------------+
| pct | Storico (RFC 7489)| Limita la percentuale di messaggi soggetti alla |
| | | policy solo per i server con vecchi sistemi. |
+------------------+-------------------+--------------------------------------------------+
| adkim / aspf | Attivo | Definisce l'allineamento rigido o rilassato |
| | | per le firme DKIM e i domini SPF. |
+------------------+-------------------+--------------------------------------------------+
Il tag pct definisce la percentuale di messaggi non autenticati a cui applicare la politica di quarantine o reject. Nello standard attuale questo tag è considerato storico. I server moderni ignorano questa limitazione percentuale applicando la policy all'intero flusso di posta, mentre solo i sistemi legacy continuano a seguirla. Lo strumento segnala questa condizione con la nota "pct=‹detail›% (RFC 7489)".
I tag non registrati o non riconosciuti dallo standard corrente vengono identificati come sconosciuti e contrassegnati con lo stato "Sconosciuto". I server di posta riceventi ignorano questi tag durante l'elaborazione del record.
Funzionamento e privacy dello strumento
Questo strumento esegue l'intera analisi del record DMARC direttamente all'interno del browser dell'utente. Il testo incollato non viene caricato su server esterni, non viene salvato in database e non viene memorizzato nello storage locale del browser. Non vengono effettuate chiamate di rete o query DNS esterne per verificare il dominio.
Domande frequenti (FAQ)
Note su sintassi e criterio: p / sp / np?
Il tag p definisce la politica del dominio principale. Se impostato su p=none, il record monitora i flussi senza bloccare i messaggi. Il tag t=y riduce la severità delle policy durante i test (reject diventa quarantine, quarantine diventa none). In assenza di configurazioni specifiche per i sottodomini, i sistemi applicano una gerarchia di ripiego che passa da np (sottodomini inesistenti) a sp (sottodomini esistenti) e infine a p (dominio principale).
RFC 9989: pct / rf / ri?
No. Questa pagina controlla solo il testo incollato. Non interroga DNS, non espande i record del provider, non verifica un IP mittente e non conferma la risposta di un server di posta ricevente. In base allo standard RFC 9989, i tag come pct, rf e ri sono considerati storici (historic), mentre tag come np, psd e t sono attivi (active).
Un risultato senza problemi dimostra che la configurazione DMARC funziona? No. Questa pagina controlla solo il testo incollato. Non interroga DNS, non espande i record del provider, non verifica un IP mittente e non conferma la risposta di un server di posta ricevente. Un'analisi priva di errori indica esclusivamente che la sintassi e la struttura del record inserito sono formalmente corrette e conformi alle specifiche analizzate.