DMARC è disponibile da 14 anni, ma il 68% dei domini non blocca nulla

Il dominio aziendale può avere SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) e persino un record DMARC (Domain-based Message Authentication, Reporting & Conformance) pubblicato correttamente nel DNS, ma restare comunque utilizzabile per spedire email contraffatte. Un’analisi condotta da CipherCue su 67.336 domini mostra che il 68,4% non chiede ai server destinatari di bloccare o mettere in quarantena i messaggi che falliscono l’autenticazione. In pratica, quasi sette domini su dieci risultano privi di DMARC oppure usano p=none, una politica che “osserva” gli abusi ma non interviene.

Il caso dell’Italia è ancora più interessante. Su 4.545 domini analizzati, il 40,9% non pubblica DMARC e il 36,8% resta in modalità di solo monitoraggio: la quota d’uso dell’impostazione p=none risulta la più alta tra i Paesi esaminati. Soltanto il 10,5% applica p=reject, cioè la politica che chiede di respingere le email non conformi. Il campione non rappresenta un censimento di tutte le imprese italiane, ma mette a fuoco un problema che gli amministratori conoscono bene: pubblicare il record è facile; capire se si può davvero attivare il blocco senza interrompere newsletter, fatture, notifiche e reset delle password è molto più complicato.

Il record DMARC può esserci e non proteggere il dominio

DMARC non autentica direttamente un’email: usa i risultati di SPF e DKIM e verifica che almeno uno dei due meccanismi risulti allineato con il dominio mostrato al destinatario nel campo From dell’email.

SPF controlla se l’indirizzo IP del server mittente è autorizzato dal dominio usato nella fase di invio tramite SMTP. DKIM aggiunge una firma crittografica alle intestazioni/header e, spesso, al corpo del messaggio. Il destinatario recupera dal DNS la chiave pubblica associata al selettore DKIM e verifica che la firma sia valida.

Un messaggio, tuttavia, può superare il controllo SPF perché proviene da un server autorizzato ma fallire DMARC se il campo From mostra il dominio dell’azienda cliente. Allo stesso modo, DKIM può risultare tecnicamente valido ma firmare con un dominio diverso da quello visibile all’utente.

Prendiamo un esempio concreto. Un’azienda invia una newsletter con From impostato su offerte@example.it. La piattaforma esterna usa come MAIL FROM bounce.provider-mail.com e firma con d=provider-mail.com. SPF passa, DKIM passa, ma nessuno dei due domini è allineato con example.it. Il risultato DMARC è fail, nonostante le due autenticazioni risultino valide prese singolarmente.

La piattaforma dovrebbe offrire almeno uno dei due percorsi corretti: un dominio di ritorno personalizzato, come bounce.example.it, oppure una firma DKIM con d=example.it o con un suo sottodominio compatibile.

p=none osserva gli abusi, ma non chiede di fermarli

Il record DMARC risiede normalmente in un record TXT pubblicato sotto _dmarc.example.it. Una configurazione di monitoraggio può apparire così: "v=DMARC1; p=none; rua=mailto:dmarc@example.it".

La politica p=none chiede ai destinatari di raccogliere informazioni e, quando supportato, inviare report aggregati all’indirizzo indicato nel parametro rua. Non chiede però di modificare la consegna delle email che falliscono DMARC. Il messaggio può quindi raggiungere la posta in arrivo, finire nello spam oppure subire un blocco deciso autonomamente dal provider.

Con p=quarantine il dominio domanda un trattamento prudenziale: tipicamente lo spostamento nello spam o l’applicazione di controlli più severi. Con p=reject chiede invece al destinatario di rifiutare il messaggio non autenticato.

DMARC, tuttavia, non impartisce un ordine inderogabile: Gmail, Outlook, Yahoo e gli altri provider di posta conservano la facoltà di applicare valutazioni proprie, soprattutto in presenza di inoltri, mailing list, reputazione consolidata o altre informazioni. Il passaggio da none a reject resta comunque il cambiamento che trasforma DMARC da strumento di osservazione a difesa concreta contro lo spoofing del dominio.

Perché nessuno vuole premere il pulsante reject

Passare a reject senza aver ricostruito tutti i flussi di posta significa rischiare di bloccare messaggi legittimi.

Un dominio aziendale raramente spedisce soltanto dal server principale: intervengono Microsoft 365 o Google Workspace, piattaforme per newsletter, CRM, software gestionali, servizi di fatturazione, sistemi di ticketing, applicazioni web, dispositivi di rete, strumenti per il monitoraggio, servizi cloud e fornitori esterni.

Alcuni sistemi usano il dominio principale; altri un sottodominio. Alcuni firmano con DKIM personalizzato, altri con il dominio del fornitore. Un vecchio gestionale può collegarsi direttamente a un relay SMTP dimenticato, mentre il reparto marketing attiva una nuova piattaforma senza coinvolgere chi amministra DNS e sicurezza.

L’impostazione p=reject rende visibili tutte queste incoerenze in modo brutale: ciò che non supera DMARC rischia di non arrivare. L’ostacolo non consiste quindi nello scrivere una riga TXT, ma nell’attribuire ogni sorgente a un’applicazione, a un fornitore e a un responsabile interno.

I report RUA mostrano chi usa davvero il dominio

I report RUA costituiscono la base tecnica dell’attività di verifica. I provider che li supportano producono documenti XML aggregati, di solito compressi, nei quali riassumono i messaggi osservati durante un intervallo di tempo.

Per ogni gruppo di messaggi, il report può indicare l’indirizzo IP sorgente, il numero di occorrenze, il dominio From, il dominio usato da SPF, il dominio della firma DKIM, i relativi risultati e l’azione applicata dal destinatario. Non contiene normalmente il testo completo delle email o l’elenco dei destinatari, ma offre materiale sufficiente per ricostruire i sistemi che dichiarano di inviare email per conto del dominio.

CipherCue ha estratto 26.179 indirizzi RUA da 36.974 record DMARC e ha identificato 10.268 domini di destinazione differenti. Ben 8.113, circa il 79%, comparivano una sola volta nel campione.

Accanto a operatori riconoscibili come Proofpoint, Valimail, Cloudflare, dmarcian ed EasyDMARC emerge una lunga coda di caselle personalizzate, indirizzi con identificatori casuali e destinazioni interne alle singole organizzazioni.

Come controllare subito il record DMARC

La prima verifica consiste nell’interrogare direttamente il DNS autorevole. Su Linux e macOS si può usare il comando dig TXT _dmarc.example.it; su Windows nslookup -type=TXT _dmarc.example.it. Il risultato deve contenere un solo record che inizia con v=DMARC1.

Bisogna quindi controllare il valore di p, l’eventuale politica sp dedicata ai sottodomini, gli indirizzi rua e i parametri di allineamento adkim e aspf.

Un record DMARC non va giudicato dal fatto che esista, ma dalla politica applicata e dalla qualità dei flussi che lo alimentano. p=none dice “mostrami che cosa succede“; p=reject dice “ho capito chi può usare il mio dominio e tutto il resto deve fermarsi“. Tra le due frasi c’è il lavoro vero: analizzare intestazioni, DNS e report RUA fino a sapere, senza supposizioni, chi sta spedendo posta a nome dell’organizzazione.

La migrazione dall’impostazione di monitoraggio a p=reject dovrebbe iniziare con alcune settimane di raccolta RUA, includendo periodi nei quali si verificano invii poco frequenti. Ogni sorgente legittima deve ottenere almeno un percorso DMARC valido: SPF allineato oppure DKIM allineato.

Dopo aver corretto i flussi si può adottare p=quarantine e osservare report, bounce, log applicativi e segnalazioni degli utenti.

DMARC protegge il dominio, non risolve tutto il phishing

DMARC contrasta l’uso non autorizzato del dominio reale nel campo From. Non impedisce a un aggressore di registrare un dominio somigliante, sostituire una lettera con un carattere simile (typosquatting), abusare del nome visualizzato oppure spedire da un account aziendale compromesso.

Non interviene neppure sulla cifratura del trasporto. MTA-STS e TLS Reporting affrontano il problema della protezione SMTP tra server; DNSSEC tutela l’autenticità delle risposte DNS; BIMI consente ai provider compatibili di associare un logo al mittente autenticato, con requisiti aggiuntivi che possono includere certificati VMC o CMC.

Nel campione analizzato da CipherCue, SPF risultava presente sul 72,7% dei domini, DMARC sul 54,9%, BIMI sul 2,6% e MTA-STS sull’1,4%.

DMARC non sostituisce filtri antiphishing, protezione degli account, autenticazione a più fattori, analisi degli allegati, rilevamento dei domini imitativi e formazione degli utenti. Riduce però una classe di attacchi molto credibile: messaggi che mostrano esattamente il dominio dell’organizzazione senza provenire dai suoi sistemi autorizzati.

Il dato del 68,4% non racconta il fallimento di uno standard. Mostra una difficoltà oggettiva delle realtà aziendali di integrare una misura di protezione efficace che però, se mal configurata, può impattare negativamente sulla consegna delle email.