Un record DMARC blocca davvero lo spoofing, o solo le campagne che il team marketing continua a inviare da un router mal allineato? DMARC (Domain-based Message Authentication, Reporting and Conformance) è un record DNS che indica ai server riceventi, Gmail, Outlook, Yahoo, quale politica applicare a un’email che fallisce l’allineamento SPF o DKIM. Pubblicato da solo, senza i due protocolli che supervisiona, non blocca nulla. Alla fine del 2025, l’83,9% dei domini analizzati da Red Sift non aveva alcun record DMARC pubblicato, su un campione di 73,3 milioni di domini. Di seguito la sintassi esatta del record, le tre politiche disponibili e la lettura dei report rua.
Cos’è DMARC?
Un dominio che pubblica SPF e DKIM senza _dmarc lascia che ogni server ricevente decida da solo come comportarsi di fronte a un errore di autenticazione. Alcuni rifiutano il messaggio, altri lo consegnano comunque segnalandolo come sospetto, altri ancora non cambiano nulla. DMARC chiude questa ambiguità: il proprietario del dominio fissa lui stesso la politica, in un record TXT pubblicato sull’host _dmarc.tuodominio.com. Lo standard è documentato nella RFC 7489 dal 2015, ma la sua adozione resta disomogenea. Le grandi aziende quotate superano l’85% di copertura nelle analisi per paese, mentre la media mondiale resta sotto il 15% (Red Sift, 2025). Il divario dipende soprattutto dalla complessità percepita della sintassi, raramente dalla sua reale difficoltà.
Perché DMARC è importante
Un dominio senza politica DMARC lascia che chiunque invii un’email firmata con il suo nome, senza che alcun meccanismo avverta il destinatario. È il vettore principale del phishing da usurpazione di marchio, quello che fa cliccare a un contabile una fattura falsa apparentemente inviata dal proprio fornitore. La dashboard di un SaaS di email marketing può mostrare una buona deliverability senza dire nulla su ciò che un terzo invia al di fuori di quella piattaforma: la deliverability misurata internamente e la superficie di esposizione allo spoofing esterno restano due misure diverse. Un dominio colpito da una campagna di spoofing vede anche degradarsi la propria sender reputation presso i filtri di Gmail e Outlook, un segnale che poi emerge nelle metriche di Google Postmaster Tools, anche quando nessuna email fraudolenta parte realmente dall’infrastruttura dell’azienda. I filtri si basano sul nome di dominio visibile, non sull’IP di invio.
Come DMARC si appoggia su SPF e DKIM
DMARC non sostituisce né SPF né DKIM. Li supervisiona, basandosi sui loro risultati. SPF verifica che il server mittente sia autorizzato a inviare per conto del dominio indicato nella busta MAIL FROM. DKIM firma il contenuto del messaggio con una chiave crittografica, il che permette di rilevare qualsiasi modifica in transito. Un’email può fallire l’uno e superare l’altro: DMARC richiede che almeno uno dei due abbia successo, e soprattutto che il dominio verificato da quel protocollo corrisponda al dominio mostrato nell’intestazione From, quello che vede il destinatario. Questa corrispondenza ha un nome, l’allineamento.
L’allineamento può essere rigido o permissivo, regolato dai tag aspf e adkim del record DMARC. In modalità permissiva, il valore predefinito, un sottodominio come newsletter.azienda.com si allinea con azienda.com. In modalità rigida, viene accettata solo una corrispondenza esatta. La maggior parte delle piattaforme di invio terze pubblica i propri record SPF e firma con le proprie chiavi DKIM, che si tratti di un router transazionale o di un CRM esterno. Senza una configurazione esplicita del sottodominio di invio nel DNS, queste email falliscono l’allineamento anche quando sono perfettamente legittime. È la causa più frequente di un tasso di rifiuto DMARC che sale subito dopo l’aggiunta di un nuovo strumento di marketing, senza che nessuna campagna di phishing c’entri qualcosa.
Creare un record DMARC: sintassi ed esempio
Configurare un record DMARC inizia sempre con la scelta dell’host DNS giusto. Il record si pubblica come un normale TXT, sull’host _dmarc della zona DNS del dominio, mai sul dominio principale. Ecco un esempio commentato, pensato per un rollout progressivo:
v=DMARC1; p=quarantine; pct=50; rua=mailto:rua@azienda.com; ruf=mailto:ruf@azienda.com; aspf=r; adkim=r; sp=none
Ogni tag ha un ruolo preciso. v fissa la versione del protocollo, sempre DMARC1. p definisce la politica applicata al dominio. pct fissa la percentuale di messaggi non conformi coinvolti da quella politica. rua indica l’indirizzo che riceve i report aggregati giornalieri. ruf indica l’indirizzo dei report forensi, raramente rispettato dai grandi provider di posta. sp fissa la politica applicata ai sottodomini che non hanno un proprio record.
Per creare e verificare il record:
- Identificare tutti i mittenti legittimi del dominio (ESP, CRM, fatturazione, helpdesk) e confermare che ognuno pubblichi SPF o firmi con DKIM.
- Creare un indirizzo dedicato ai report rua.
- Pubblicare il record TXT su _dmarc con p=none per almeno due o quattro settimane, limitandosi a osservare.
- Leggere i primi report aggregati per individuare le fonti che falliscono l’allineamento e correggerle una per una.
- Alzare la politica per gradi, pct=25 poi pct=50 poi pct=100, prima di passare a quarantine e poi a reject.
Un record malformato, un tag duplicato o un indirizzo rua non valido, in genere non impedisce la pubblicazione sul DNS. Blocca invece silenziosamente la ricezione dei report, il che rende impossibile il monitoraggio senza che alcun avviso raggiunga l’amministratore.
Le tre politiche DMARC e il rollout progressivo
Per il tag p sono possibili tre valori. none non cambia nulla nella consegna, solo il report rua registra l’errore. quarantine invia l’email non conforme nello spam del destinatario. reject blocca l’invio con un rifiuto SMTP rinviato al mittente, prima ancora che raggiunga la casella di posta.
Passare subito a p=reject senza una fase di osservazione blocca anche email legittime non allineate, mailing list che riscrivono il From, router CRM esterni mal configurati, fatturazione esternalizzata. Il rollout consigliato parte da none, sale verso quarantine e chiude sul rifiuto completo. Una politica reject al 100% apre anche la strada a BIMI, il logo di marchio mostrato da Gmail e Yahoo.
Leggere i report DMARC: rua e ruf
I report rua arrivano in XML compresso. Ogni provider di posta che ha ricevuto messaggi dal dominio ne invia in genere uno al giorno, con l’elenco degli IP mittenti, il volume elaborato, il risultato dell’allineamento SPF e DKIM e la politica applicata. La lettura manuale resta praticabile per un dominio con due o tre mittenti. Oltre una decina di sottodomini attivi e diverse piattaforme di invio, il volume di righe XML rende poco realistica una lettura riga per riga senza uno strumento di parsing dedicato. In pratica, un dominio con più fornitori di invio riceve ogni giorno report distinti da Google, Microsoft e Yahoo, ciascuno con la propria struttura XML pur rispettando lo schema descritto dalla RFC 7489. Un report tipico elenca, riga per riga, la source IP, il conteggio dei messaggi, il risultato disposition e i risultati grezzi di SPF e DKIM, prima ancora di qualsiasi interpretazione umana.
I report ruf, invece, dettagliano un’email precisa che è fallita, intestazioni complete incluse. Gmail e Yahoo non li inviano, per motivi legati alla riservatezza dei dati personali contenuti in quelle intestazioni. Solo una minoranza di provider di posta più piccoli li rispetta ancora. La guida completa per leggere un report DMARC aggregato senza sbagliare spiega il parsing XML campo per campo.
Cosa DMARC non copre
DMARC protegge esattamente il dominio pubblicato nel record, nulla di più. Un’email inviata da azienda-supporto.com invece di azienda.com, un dominio visivamente simile registrato da un attaccante, passa completamente inosservata rispetto a tutto il dispositivo: nessun SPF, DKIM o DMARC copre un dominio che l’azienda non possiede. Questo typosquatting resta il punto cieco più frequente dei deployment DMARC, inclusi quelli già configurati su p=reject. L’elenco completo dei limiti, dal contenuto del messaggio alla protezione dei domini non registrati, merita di essere conosciuto prima di annunciare internamente che un dominio è ormai protetto.
Chi deve pubblicare un record DMARC nel 2026
Dal 1° febbraio 2024, Google richiede un’autenticazione SPF e DKIM allineata, più un record DMARC almeno in p=none, per ogni mittente che invii 5.000 o più messaggi in 24 ore verso account Gmail personali. Microsoft ha seguito a partire dal 5 maggio 2025 su Outlook.com, Hotmail e Live.com: superata la stessa soglia, le email non autenticate vengono rifiutate a livello SMTP con l’Enhanced Status Code 550 5.7.15, anziché reindirizzate nella cartella spam. Il complaint rate segnalato tramite i feedback loop dei provider di posta deve restare sotto lo 0,3%, con una soglia consigliata sotto lo 0,1% per evitare un filtraggio più severo.
Google precisa che la soglia di 5.000 messaggi viene valutata su una finestra mobile di 24 ore: un mittente che la supera anche una sola volta resta soggetto agli stessi requisiti come se la raggiungesse ogni giorno.
Sotto questa soglia, nulla obbliga legalmente a pubblicare DMARC. Ma un dominio B2B attivo, anche a basso volume, resta un bersaglio privilegiato per l’usurpazione: la fattura fraudolenta rivolta a un fornitore non si preoccupa del volume di invio della vittima. Un altro strumento in più nello stack, diranno alcuni scoprendo che bisogna sorvegliare anche il tasso di hard bounce e la sender reputation associati al dominio. DMARC non sostituisce nulla di ciò che esiste già. Consuma soprattutto i dati già presenti in Google Postmaster Tools. Ripulire la mailing list, una pratica elementare di list hygiene, prima di irrigidire la politica verso DMARC reject evita di confondere un indirizzo che rimbalza con un errore di allineamento mal diagnosticato, una confusione che ritarda il rollout di diverse settimane nella maggior parte dei casi osservati.
Da quanto tempo non viene letto il report rua di questo dominio?
