DMARC: il guardiano invisibile delle tue email
Perché DMARC è ormai indispensabile
A dieci anni dalla pubblicazione dello standard DMARC (RFC 7489, marzo 2015) e alla vigilia dell’imminente rilascio del nuovo DMARCbis, sorprende constatare che ancora oggi molti domini e sistemi di posta non lo utilizzano — o lo fanno in modo parziale o errato. Anche amministratori di sistema esperti, talvolta, nutrono dubbi o incontrano difficoltà nel comprenderne appieno il funzionamento.
Siamo nel 2025: se non avete ancora implementato DMARC, è davvero il momento di farlo.
Perché? Una risposta breve potrebbe essere:
Perché i grandi player — Google, Microsoft, Yahoo, Apple — lo richiedono (e lo rispettano).
In altre parole:
Volete che le vostre email vengano consegnate?
Allora dovete tenere conto di DMARC.
Ma facciamo un passo indietro.
In principio c’era SPF
Lo Sender Policy Framework (SPF) è stato il primo tentativo di contrastare lo spoofing, dichiarando — tramite un record DNS TXT — quali server o IP sono autorizzati a inviare email per conto di un dominio.
Un esempio tipico:
example.com. IN TXT "v=spf1 mx ip4:203.0.113.10 -all"
Questo meccanismo, pur utile, presenta limiti strutturali:
- La verifica avviene sul Return-Path (Envelope-From), cioè sull’indirizzo tecnico usato nel dialogo SMTP, e non sul campo From: visibile al destinatario. Un attaccante può quindi “camuffare” facilmente l’identità del mittente.
- Gli IP condivisi: molti provider inviano email per migliaia di domini dagli stessi IP. Un singolo account compromesso può quindi consentire lo spoofing di altri domini legittimi.
- Il forward rompe SPF: nei casi di inoltro automatico, la verifica spesso fallisce, generando falsi positivi o altre anomalie.
Senza entrare nei dettagli delle policy SPF, possiamo dire che un risultato SPF valido è un buon segnale, ma non sufficiente per considerare un messaggio autentico.
DKIM: la firma digitale dell’email
DomainKeys Identified Mail (DKIM) è il secondo pilastro dell’autenticazione email, e funziona in modo completamente diverso da SPF.
DKIM firma ogni messaggio con una chiave crittografica, garantendo che il contenuto non sia stato alterato dopo l’invio (integrità).
La chiave pubblica corrispondente viene pubblicata nel DNS del dominio:
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
Se la firma DKIM è valida, siamo certi che il messaggio proviene dal dominio indicato nel parametro d= e che non è stato modificato. Tuttavia, come per SPF, il dominio firmatario può non coincidere con quello visibile nel campo “From:” (RFC 5322). Un attaccante potrebbe quindi sfruttare questa discrepanza per inviare email apparentemente legittime.
DKIM è particolarmente importante anche per garantire la corretta consegna delle email inoltrate.
Come vedremo tra poco, infatti, SPF fallisce inevitabilmente quando un messaggio viene inoltrato: l'IP del server che effettua il forward non coincide più con quelli autorizzati nel record SPF originale.
La firma DKIM, invece, viaggia "a bordo" del messaggio e ne mantiene la validità, consentendo ai server di destinazione di verificarne comunque l’autenticità.
Ecco DMARC: l’idea di allineamento
Nel 2015 nasce l’idea di sfruttare SPF e DKIM in modo più mirato per proteggere il campo From: visibile delle email.
DMARC introduce il concetto di allineamento.
Il suo obiettivo è verificare che il dominio del mittente visibile (From:) sia coerente con quello usato in SPF e/o DKIM.
Il messaggio supera DMARC se almeno uno tra SPF o DKIM risulta allineato e valido.
Il mittente dichiara la propria policy DMARC con un record DNS di questo tipo:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;"
Con questo record può:
- definire una policy (
p=) che indica come i server destinatari devono trattare i messaggi non conformi (ad esempio “none”, “quarantine”, “reject”); - ricevere report aggregati (
rua=) per monitorare i risultati dell’autenticazione dai vari provider.
Analizzando i report DMARC — generalmente in formato XML e spesso molto voluminosi — si possono individuare:
- tentativi di spoofing o phishing;
- sorgenti legittime dimenticate nelle configurazioni SPF o prive di firma DKIM.
È quindi inevitabile — e molto comodo — utilizzare uno dei numerosi servizi di analisi dei report DMARC, che offrono una vista di alto livello (dashboard) dei risultati, disponibili in modalità as a service.
Reputazione e deliverability
Oggi DMARC non è più solo uno strumento anti-abuso. I grandi provider lo usano anche come fattore di reputazione del dominio, influenzando direttamente la deliverability delle email.
Molti domini espongono record DMARC minimi come:
_dmarc.example.com. IN TXT "v=DMARC1; p=none;"
Un record simile “esiste” ma non serve a molto: non impone alcuna policy né fornisce un indirizzo per i report. È quindi una configurazione incompleta e poco utile, soprattutto per domini realmente utilizzati in produzione.
Authorized sources
Mantenere un monitoraggio costante dei report DMARC è fondamentale non solo per individuare eventuali tentativi di spoofing, ma soprattutto per controllare e validare le sorgenti autorizzate di invio delle nostre email.
Ad esempio, può emergere che un sistema di notifica non sia incluso nella dichiarazione SPF, oppure che una piattaforma di newsletter non firmi i messaggi con DKIM. Sono situazioni comuni che possono essere facilmente corrette grazie alle informazioni contenute nei report inviati dai server di destinazione.
Conclusione
DMARC è oggi indispensabile per chiunque gestisca domini che inviano email. Tuttavia, non basta pubblicare un record DNS per essere protetti:
occorre configurare correttamente SPF e DKIM, e soprattutto analizzare regolarmente i report DMARC.
Non è un argomento complesso, ma va affrontato con metodo.
Spero che queste righe vi abbiano offerto qualche spunto utile per migliorare la sicurezza e l’affidabilità delle vostre comunicazioni email.
