Come usare un DMARC checker per verificare il record del tuo dominio

Prima di inviare anche una sola email di prospezione a un decisore, vale la pena passare due minuti su un DMARC checker: il risultato dice se il dominio è protetto o se sta silenziosamente danneggiando la propria reputazione. Un record DMARC assente o mal configurato non blocca l'invio, ma abbassa la fiducia che Gmail, Outlook e gli altri provider assegnano al dominio mittente, con conseguenze dirette sulla percentuale di email che arrivano davvero in inbox. Questa guida spiega quali strumenti usare, come si legge l'output e quali segnali richiedono un intervento prima di lanciare una campagna di outreach B2B mirata.

Perché controllare il DMARC prima di una campagna di outreach

Chi fa outreach B2B mirato invia decine o al massimo qualche centinaio di email al giorno a persone fisiche precise, selezionate per ruolo e azienda. Non è direct marketing di massa, eppure dal punto di vista tecnico dei provider di posta il trattamento è identico a quello riservato a una newsletter: ogni messaggio passa dagli stessi controlli di autenticazione, indipendentemente dal volume.

Se il commerciale di Rossi Impianti Srl scrive un'email perfetta al responsabile acquisti di un cliente potenziale, ma il dominio rossiimpianti.it non ha mai pubblicato un record DMARC, quella email parte comunque, solo che finisce più facilmente in spam o viene silenziosamente filtrata prima ancora di essere valutata dal destinatario. Il DMARC checker serve esattamente a scoprirlo in anticipo, non dopo aver bruciato la prima impressione con un lead qualificato.

Controllare il record prima del lancio di una campagna costa due minuti e permette di correggere il problema quando ancora non ha danneggiato nessun invio reale.

Cosa fa esattamente un DMARC checker

Tecnicamente un DMARC checker esegue una query DNS di tipo TXT sul sottodominio _dmarc del dominio che si vuole verificare, per esempio _dmarc.rossiimpianti.it, e legge il contenuto pubblicato lì. Lo stesso risultato si può ottenere a mano con un comando da terminale, ma un tool dedicato interpreta i singoli tag del record, ne verifica la sintassi e segnala subito eventuali errori che a occhio nudo sono facili da perdere.

I tag principali che un checker estrae sono v (versione del protocollo, sempre DMARC1), p (la policy applicata al dominio), pct (percentuale di messaggi a cui applicare la policy), rua e ruf (indirizzi a cui inviare i report aggregati e forensi) e adkim/aspf (modalità di allineamento, rigida o permissiva, tra il dominio nell'header From e quelli verificati da DKIM e SPF).

Un buon checker distingue anche tra record pubblicato correttamente sul dominio radice e record ereditato o mancante su un sottodominio usato per l'invio, un dettaglio che molte configurazioni fatte in fretta trascurano.

I principali strumenti gratuiti a confronto

dmarcian offre uno dei DMARC checker più usati in assoluto, spesso indicato semplicemente come dmarcian domain checker: interroga il record, lo scompone tag per tag e segnala in modo chiaro se la policy è debole o se mancano gli indirizzi per i report. È lo strumento di riferimento quando si vuole capire non solo se il record esiste, ma se è impostato in modo utile nel tempo.

MXToolbox è la scelta più rapida quando si vuole un quadro d'insieme: nello stesso passaggio restituisce lo stato di SPF, DKIM e DMARC, oltre a MX e blacklist. Utile come primo triage prima di aprire un checker più specifico.

Google Admin Toolbox, nella sezione dedicata al controllo dei record di posta, è comodo per chi amministra un dominio su Google Workspace perché mostra risultati coerenti con quello che vede Gmail lato ricezione. Esistono infine diversi checker minori integrati in piattaforme di monitoraggio della deliverability, utili soprattutto quando serve un controllo ricorrente e non solo puntuale.

• dmarcian — analisi dettagliata dei singoli tag e storico delle modifiche
• MXToolbox — controllo combinato SPF, DKIM, DMARC, MX in un solo report
• Google Admin Toolbox — coerente con la logica di verifica di Gmail
• Checker integrati nelle piattaforme di monitoring — utili per controlli ricorrenti automatizzati

Come leggere il risultato: i campi che contano davvero

Il primo campo da guardare è p, la policy: none significa che il dominio si limita a osservare senza intervenire sui messaggi che falliscono i controlli, quarantine mette in quarantena (di solito in spam) i messaggi non conformi, reject li rifiuta del tutto. Molti domini restano fermi su none per anni, semplicemente perché nessuno ha mai completato il passaggio successivo.

Il secondo campo importante è rua: se manca, il dominio non riceve mai i report aggregati che i provider inviano quotidianamente, e quindi chi lo gestisce vola alla cieca, senza sapere se qualcuno sta tentando di inviare email falsificando il proprio dominio. Il campo pct, quando presente e inferiore a 100, indica che la policy si applica solo a una percentuale dei messaggi: utile in fase di transizione, pericoloso se dimenticato a un valore basso a tempo indeterminato.

Infine adkim e aspf, se impostati su s (strict) invece di r (relaxed), richiedono una corrispondenza esatta tra il dominio del mittente visibile e quello autenticato da DKIM o SPF: una configurazione più severa, che però va introdotta solo dopo aver verificato che tutti i canali di invio legittimi la rispettano.

Errori comuni che il checker segnala

L'errore più frequente è la presenza di due record TXT distinti su _dmarc: il protocollo ne prevede uno solo, e quando ce ne sono due i provider tendono a ignorare entrambi o a comportarsi in modo imprevedibile. Un buon checker segnala subito il conflitto, ma va risolto rimuovendo il record duplicato o obsoleto lasciato da una configurazione precedente.

Un secondo errore comune riguarda i sottodomini: se Bianchi Consulting invia email di prospezione da mail.bianchiconsulting.it invece che dal dominio radice, quel sottodominio deve avere la propria copertura, o attraverso il tag sp del record principale, o con un record dedicato. In assenza di questo, il sottodominio finisce senza alcuna protezione anche se il dominio principale è configurato bene.

Un terzo errore, meno visibile ma frequente, è il disallineamento tra il dominio mostrato nel campo From e quello effettivamente autenticato da SPF o DKIM: capita quando si usa uno strumento di outreach che invia per conto del mittente senza autenticazione corretta, e il messaggio fallisce l'allineamento anche se SPF e DKIM presi singolarmente risultano corretti.

• Due record TXT su _dmarc invece di uno solo
• Sottodominio di invio senza copertura propria
• Disallineamento tra dominio visibile nel From e dominio autenticato
• Campo rua assente, quindi nessuna visibilità sui tentativi di abuso del dominio

Checklist prima di lanciare la campagna

Prima di programmare l'invio a un elenco selezionato di decisori, vale la pena seguire una sequenza semplice: lanciare il checker sul dominio principale, verificare che il campo p non sia vuoto, confermare che rua punti a una casella effettivamente monitorata, e ripetere il controllo 24-48 ore dopo qualsiasi modifica ai DNS, perché la propagazione non è mai istantanea.

Se nel frattempo si aggiunge un nuovo strumento di invio, per esempio una piattaforma di outreach o un CRM che manda email per conto del team commerciale, il controllo va ripetuto: ogni nuovo mittente autorizzato deve comparire correttamente sia in SPF sia in DKIM prima che il DMARC possa validarlo.

Chi gestisce più domini o sottodomini per team commerciali diversi dovrebbe programmare un controllo periodico, non solo al primo setup: i record DNS vengono modificati per tanti motivi diversi nel tempo, e un errore introdotto per sbaglio da un altro reparto può passare inosservato per settimane se nessuno ricontrolla.

Domande frequenti