DMARC è un record che pubblichi nel DNS del tuo dominio e che dice ai server di posta di tutto il mondo cosa fare quando arriva un messaggio che dichiara di venire da te ma non supera i controlli di autenticazione: lasciarlo passare, metterlo in quarantena o rifiutarlo. Insieme alla policy chiede ai riceventi di inviarti report su chi sta usando il tuo dominio. È l'unico controllo che chiude lo spoofing sul tuo dominio esatto, e va attivato in sequenza per non bloccare la posta legittima.
DMARC sta per Domain-based Message Authentication, Reporting and Conformance. È uno standard aperto, descritto dalla RFC 7489, che si appoggia a due meccanismi più vecchi, SPF e DKIM, e aggiunge le due cose che a quelli mancavano: una decisione e una visibilità.
Il problema che risolve nasce dal protocollo della posta elettronica. Chi invia un messaggio può scrivere nel campo mittente qualunque indirizzo: non c'è nulla, nel protocollo di base, che lo impedisca. Chiunque, da qualunque server, può scrivere ai tuoi clienti mettendo il tuo dominio nel mittente. Questo è lo spoofing del dominio, ed è il meccanismo dietro la maggior parte delle frodi sulle fatture.
SPF e DKIM permettono al ricevente di accorgersi che qualcosa non torna, ma non gli dicono cosa farne. In assenza di DMARC ogni ricevente decide per conto suo, e quasi sempre consegna comunque. DMARC colma il vuoto: pubblichi la tua istruzione e i riceventi la applicano.
La seconda metà è spesso sottovalutata e vale quanto la prima: DMARC chiede ai riceventi di mandarti un rapporto periodico su tutti i messaggi che dichiarano il tuo dominio, autenticati e non. È l'unico modo per sapere chi invia posta a nome della tua azienda, compresi i sistemi interni che nessuno ricordava.
I tre standard sono complementari e nessuno sostituisce gli altri.
| Standard | Cosa pubblica | Cosa verifica il ricevente | Limite |
|---|---|---|---|
| SPF | Un record TXT con l'elenco dei server autorizzati a inviare posta per il dominio | Che l'indirizzo IP del server mittente sia nell'elenco | Si rompe quando un messaggio viene inoltrato, e non guarda il mittente che l'utente vede |
| DKIM | Una chiave pubblica in un record TXT su un selettore | La firma crittografica applicata al messaggio in uscita, che prova che contenuto e intestazioni non sono stati alterati | Sopravvive all'inoltro ma non dice nulla su cosa fare se manca |
| DMARC | La policy da applicare e gli indirizzi a cui mandare i report | Che almeno uno fra SPF e DKIM passi e sia allineato con il dominio che l'utente vede | Copre solo il tuo dominio esatto, non le imitazioni |
La parola chiave è allineamento. Un messaggio può superare SPF e restare spoofing: basta che l'attaccante invii da un proprio dominio, regolarmente autorizzato nel proprio SPF, e scriva il tuo nel campo che l'utente legge. DMARC richiede che il dominio autenticato coincida con quello visibile, ed è questo che chiude la porta.
Il record è un TXT pubblicato sul sottodominio _dmarc del tuo dominio. Nella forma minima di partenza:
_dmarc.esempio.it. IN TXT "v=DMARC1; p=none; rua=mailto:report@esempio.it"
I campi che contano:
none, quarantine o reject. È il campo che decide tutto.mailto:. Può contenere più indirizzi separati da virgola.r rilassato, che accetta i sottodomini, oppure s stretto, che richiede corrispondenza esatta. Il default è rilassato.p=quarantine; pct=25.Un record in enforcement completo somiglia a questo:
"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:report@esempio.it; fo=1"
Il dominio che non invia posta merita un record altrettanto esplicito: pubblicare p=reject su un dominio parcheggiato, insieme a un SPF vuoto, è la misura più economica che esista per impedire che venga usato nelle frodi.
Le tre policy non sono livelli di sicurezza crescenti da scegliere: sono le tappe di un percorso, e restare fermi alla prima significa non aver risolto nulla.
La distinzione pratica da tenere a mente è che la policy è un'istruzione, non un'imposizione: i grandi riceventi la rispettano, un server mal configurato può ignorarla. Questo non toglie valore al reject, perché la posta della tua azienda arriva in grandissima parte a caselle gestite da operatori che DMARC lo applicano.
I report aggregati sono file XML compressi che i riceventi inviano di norma una volta al giorno all'indirizzo indicato in rua. Ogni report copre un ricevente e un periodo, e per ogni indirizzo IP che ha inviato posta a nome tuo elenca il volume, l'esito di SPF e DKIM, l'allineamento e la disposizione applicata.
Letti a mano sono praticamente inutilizzabili: un dominio anche piccolo riceve decine di file al giorno da operatori diversi, e la risposta alla domanda che conta, quali miei mittenti legittimi stanno fallendo, si ottiene solo aggregando i file fra loro. Per questo il monitoraggio DMARC non è un lusso ma la parte che rende utilizzabile lo standard.
Quello che cerchi nei report, in ordine:
La protezione dell'identità email con Defensio Identity Shield trasforma i report grezzi in questo elenco leggibile, con l'andamento nel tempo e lo stato del percorso verso l'enforcement.
Questa è la sequenza che evita l'unico errore davvero costoso, cioè bloccare la posta della propria azienda.
+all, chiudi con -all o ~all.pct= per procedere in modo graduale, e osserva ancora.sp=reject per i sottodomini.Il tempo tipico per una PMI con pochi mittenti è di quattro-sei settimane. Non è il lavoro tecnico a richiederlo, ma l'osservazione: serve un ciclo completo di invii per essere sicuri di non aver dimenticato nessuno.
Le cause ricorrenti sono poche e riconoscibili nei report.
include: consuma interrogazioni. Con tre o quattro fornitori si sfora senza accorgersene e SPF inizia a fallire per tutti.aspf=s un mittente che usa un sottodominio smette di allinearsi._dmarc equivalgono a nessun record.Nessuno di questi casi è un motivo per tornare indietro: sono i mittenti da sistemare, e il report dice esattamente quali sono.
Vale la pena essere espliciti sui limiti, perché è dove si concentrano le sorprese.
DMARC in reject ha smesso di essere una raffinatezza tecnica ed è diventato una domanda ricorrente nei questionari di sicurezza dei clienti e nei questionari delle polizze cyber. La ragione è pratica: è verificabile dall'esterno in pochi secondi, a differenza di quasi tutto il resto di un programma di sicurezza.
Per la NIS2 rientra fra le misure tecniche dell'articolo 21 sulla sicurezza delle comunicazioni, e per il GDPR è una misura che riduce il rischio di frode e di divulgazione a danno degli interessati. In entrambi i casi conta non solo il record pubblicato ma la cronologia: da quando è in reject, chi invia a nome del dominio, cosa è stato corretto e quando.
È un'istruzione che pubblichi nel DNS del tuo dominio e che i server di posta di tutto il mondo leggono prima di consegnare un messaggio che dichiara di venire da te. Dice loro cosa fare se il messaggio non supera i controlli di autenticazione: consegnarlo comunque, metterlo in quarantena o rifiutarlo. In più chiede ai riceventi di mandarti un rapporto periodico su chi sta inviando posta a nome tuo, che è l'unico modo per scoprire sia gli abusi sia i tuoi stessi sistemi non censiti.
Si pubblica un record TXT sul nome _dmarc del dominio. La forma di partenza è v=DMARC1; p=none; rua=mailto:indirizzo, dove p è la policy e rua l'indirizzo che riceve i report aggregati. Si comincia sempre da p=none per accendere i report senza cambiare nulla nella consegna, si correggono i mittenti legittimi che falliscono e solo dopo si passa a p=quarantine e infine a p=reject, aggiungendo sp=reject per i sottodomini. Deve esistere un solo record DMARC: due record equivalgono a nessuno.
SPF elenca i server autorizzati a inviare posta per il tuo dominio e il ricevente controlla che il server mittente sia nella lista. DKIM firma crittograficamente i messaggi in uscita, così il ricevente verifica che non siano stati alterati. Nessuno dei due dice cosa fare quando il controllo fallisce, e nessuno dei due guarda il mittente che l'utente vede. DMARC aggiunge la decisione e il requisito di allineamento fra il dominio autenticato e quello visibile, più i report. Servono tutti e tre.
Per una PMI con pochi sistemi di invio, tipicamente da quattro a sei settimane. Il lavoro tecnico è di poche ore; il tempo serve all'osservazione. Bisogna attendere almeno un ciclo completo di invii, incluse le comunicazioni mensili come fatture o buste paga, perché un mittente che manda una volta al mese non compare nei report della prima settimana ed è esattamente quello che si rischia di bloccare passando troppo presto all'enforcement.
No. p=none non chiede al ricevente di comportarsi diversamente da come si comporterebbe senza DMARC: serve unicamente ad accendere i report. Un dominio fermo a p=none è spoofabile esattamente come uno senza alcun record. È una fase di passaggio utile e necessaria, ma restarci è la situazione più comune e più fraintesa: molte aziende sono convinte di aver messo in sicurezza la posta perché il record esiste.
Sono file XML compressi che i riceventi inviano di norma una volta al giorno all'indirizzo indicato in rua. Ogni file elenca, per ciascun indirizzo IP che ha inviato posta a nome del tuo dominio, il volume dei messaggi, l'esito di SPF e DKIM, l'allineamento e la disposizione applicata. A mano sono impraticabili, perché arrivano da decine di operatori diversi e la risposta utile si ottiene solo aggregandoli. Serve un monitoraggio che li unisca e mostri quali mittenti legittimi stanno fallendo.
No. Un dominio registrato da un attaccante con una lettera in meno, due lettere invertite o una parola aggiunta è un dominio diverso, con un proprio DNS: la tua policy DMARC non lo riguarda in alcun modo. Contro queste imitazioni servono la sorveglianza dei domini simili al tuo, per sapere quali esistono e quali sono già attrezzati per inviare posta, e la formazione di chi riceve. DMARC chiude soltanto, ma in modo definitivo, l'uso del tuo dominio esatto.
Non esiste una legge italiana che lo imponga con quel nome. È però richiesto di fatto in tre modi: i grandi operatori di posta lo pretendono da chi invia volumi significativi, pena il recapito in posta indesiderata; compare regolarmente nei questionari di sicurezza dei clienti e nelle domande delle polizze cyber; e rientra fra le misure tecniche che NIS2 e GDPR chiedono di adottare in modo proporzionato al rischio, dove la sicurezza delle comunicazioni è esplicitamente citata.
Un record DNS, nessuna email che passa attraverso di noi, e in pochi giorni l'elenco leggibile di ogni mittente che usa il tuo dominio, con il percorso verso il reject. Attiva la protezione dell'identità email.