2,77 miliardi di dollari. È la cifra che il FBI ha registrato come perdite dovute al Business Email Compromise solo per l’anno 2024, secondo il rapporto annuale IC3. Una parte di questi attacchi ha avuto successo nonostante le organizzazioni colpite avessero DMARC in atto. Non è un paradosso: DMARC protegge solo contro una forma specifica di spoofing, e gli aggressori lo sanno. Capire i suoi limiti esatti (quelli che la RFC 7489 documenta essa stessa) è fondamentale per non sopravvalutarne la copertura reale.
Ciò che DMARC fa (e nient’altro)
DMARC (Domain-based Message Authentication, Reporting and Conformance) è un protocollo che si basa su SPF e DKIM per fornire istruzioni ai server di posta destinatari: respingere, mettere in quarantena o consegnare le email la cui identità di dominio non può essere verificata. Con una politica p=reject, ogni messaggio il cui intestazione From non corrisponde a una fonte SPF o DKIM autorizzata viene bloccato. Questa protezione è reale. Ma il suo campo di applicazione è strettamente limitato allo spoofing esatto del dominio. La RFC 7489 lo scrive nero su bianco: «DMARC non affronta l’uso di nomi di domini visivamente simili né l’abuso del display name leggibile dall’essere umano.» Cinque vettori di attacco comuni restano quindi fuori portata.
Il display name spoofing gli sfugge completamente
Un’email la cui intestazione mostra «Servizio Clienti Amazon <phishing@n0treal.com>» passa DMARC senza problemi. DMARC verifica solo il dominio tecnico del mittente, non il nome visualizzato nel client di posta. L’aggressore mantiene un nome del mittente identico a un marchio di fiducia pur utilizzando il proprio dominio, correttamente autenticato. Per l’utente finale, la riga «Da:» mostra esattamente ciò che l’attaccante ha deciso di mettere. Questo vettore non richiede alcuna infrastruttura compromessa e aggira tutti i controlli DMARC per definizione: il dominio tecnico non è falsificato, è semplicemente non correlato al nome visualizzato.
I domini simili non sono interessati
DMARC protegge example.com. Non dice nulla su examp1e.com, example-support.com o example.fr. Questi domini detti «cugini» (typosquatting, lookalike domains) possono pubblicare il proprio record DMARC valido, con SPF e DKIM correttamente configurati, e inviare email perfettamente autenticate da un dominio che assomiglia in modo impressionante a quello di un’organizzazione legittima. Il problema è documentato da PowerDMARC: questi domini «aggirano frequentemente la portata di DMARC» perché il protocollo non ha alcun controllo su ciò che non gestisce. La sorveglianza dei domini simili registrati è di competenza di altre categorie di strumenti: brand monitoring, monitoraggio DNS, analisi dei certificati SSL emessi di recente.
Un account compromesso passa DMARC senza allerta
Se un aggressore accede a una casella email legittima tramite credential stuffing, phishing iniziale o fuga di dati, tutti i suoi messaggi in uscita passano SPF, DKIM e DMARC normalmente. Il messaggio proviene dal dominio corretto, firmato con la chiave DKIM corretta, da un’IP autorizzata. DMARC non distingue un dipendente legittimo da un aggressore che ha rubato le sue credenziali. Questo è precisamente il modus operandi del BEC (Business Email Compromise): i 2,77 miliardi di dollari di perdite registrate dal FBI nel 2024 riguardano attacchi in cui l’infrastruttura email delle vittime era spesso configurata correttamente. DMARC non ha visto nulla perché tecnicamente non c’era nulla da vedere.
Il forwarding degli email può interrompere l’autenticazione
Quando un messaggio attraversa un servizio intermedio (alias di azienda, mailing list come Mailman o Listserv, reindirizzamento automatico), SPF fallisce quasi sistematicamente: l’IP del relay non è elencato nel record SPF del dominio di origine. Se la mailing list modifica il corpo del messaggio (footer aggiunto, disclaimer inserito), DKIM può anche fallire. Email perfettamente legittime vengono respinte o messe in quarantena. Secondo dmarcian, il 21% dei fallimenti di DMARC osservati nei rapporti aggregati provengono da questa rottura del DKIM per modifica del contenuto. La soluzione standard è ARC (Authenticated Received Chain), ma richiede una configurazione esplicita sul lato del relay. La maggior parte delle mailing list non l’ha ancora implementata.
I sottodomini possono rimanere punti ciechi
Un record DMARC pubblicato su example.com non protegge automaticamente tutti i suoi sottodomini. Di default, mail.example.com o newsletter.example.com ereditano la politica del dominio principale, a meno che non esista uno specifico record DMARC per quel sottodominio, nel qual caso prevale quest’ultimo, anche se è configurato in p=none. Un sottodominio dimenticato configurato in monitoraggio annulla la protezione p=reject del dominio principale per quell’area. Valimail indica che oltre l’80% dei domini non ha una politica DMARC vincolante; tra quelli che ne hanno una, la coerenza tra dominio principale e sottodomini è raramente verificata in modo sistematico. I domini «parking» non usati restano anche superfici di spoofing disponibili.
DMARC in una strategia realistica
Questi cinque limiti non rendono DMARC inutile. A novembre 2025, Gmail ha iniziato a respingere le email bulk non conformi, e Valimail stima che l’applicazione di DMARC ha eliminato 265 miliardi di messaggi non autenticati nel 2024. È una base necessaria. Ma è solo una base. Una copertura realistica richiede inoltre: una soluzione in grado di analizzare il display name e di rilevare i domini simili, una protezione contro la compromissione degli account (MFA obbligatorio, rilevamento anomalie comportamentali), una configurazione ARC per i flussi di trasferimento legittimi, e un audit regolare dei sottodomini incluso quelli considerati «inattivi». DMARC chiude una porta. Prima di considerare il lavoro finito, bisogna contare le altre.
