DMARC: cos'è, come funziona il record e le policy

La risposta breve: DMARC (Domain-based Message Authentication, Reporting and Conformance) è un record DNS con cui dici ai server di posta cosa fare delle email che usano il tuo dominio come mittente ma non superano i controlli SPF o DKIM, e chiedi loro un report su chi sta spedendo a tuo nome. Si pubblica come record TXT su _dmarc.tuodominio.it, parte in osservazione con p=none e si stringe dopo aver letto i report.

Da maggio 2026 DMARC ha anche una base nuova: la RFC 9989, standard IETF, ha sostituito la RFC 7489 del 2015.

Cos'è DMARC e quale problema risolve

Un'email porta più di un mittente: quello tecnico della busta, usato per la consegna, e quello nell'intestazione From, l'unico che il destinatario vede. SPF e DKIM autenticano un dominio, ma non necessariamente quello del From: un attaccante può configurarli in modo impeccabile su un dominio suo e mettere il tuo nel From.

DMARC chiude il varco con l'allineamento: il dominio autenticato da SPF o DKIM deve corrispondere a quello nel From. La RFC 9989 (sezione 4.2) spiega la scelta: è il campo con cui gli utenti riconoscono la provenienza, e l'unico identificatore che ogni messaggio conforme deve contenere.

Cosa DMARC non fa: la stessa RFC mette fuori perimetro gli attacchi sul nome visualizzato (sezione 11.4), dove il nome del tuo amministratore delegato accompagna un indirizzo qualunque, e l'analisi del contenuto (sezione 2.4). E un dominio somigliante al tuo può pubblicare il suo record DMARC e superarlo. DMARC rende difficile usare il tuo dominio esatto, non ferma il phishing in generale.

Come funziona: SPF, DKIM e allineamento

SPF

SPF elenca nel DNS i server autorizzati a spedire per un dominio. Ai fini di DMARC conta solo la verifica del dominio del MAIL FROM (RFC 9989, sezione 4.4.2). Il suo limite è l'inoltro: quando un alias rigira il messaggio altrove, l'IP di chi consegna non è più tra quelli autorizzati e il controllo fallisce.

DKIM

DKIM firma il messaggio e dichiara nel tag d= il dominio che se ne assume la responsabilità; la chiave pubblica sta nel DNS. La firma di solito sopravvive all'inoltro, ed è per questo che la RFC 9989 la rende obbligatoria a chi pubblica la policy più severa.

Allineamento rilassato e stretto

Con l'allineamento rilassato, il valore predefinito, basta che il dominio autenticato e quello del From condividano lo stesso dominio organizzativo: news.esempio.it è allineato con mail.esempio.it. Con quello stretto devono essere identici. Per un esito pass basta che uno dei due meccanismi produca un risultato allineato. Secondo la RFC, nella pratica quasi tutti trovano sufficiente l'allineamento rilassato.

Il record DMARC, tag per tag

Un record di partenza, ricavato dall'esempio in appendice B.2.1 della RFC 9989 e adattato a un dominio italiano, ha questo aspetto:

_dmarc.esempio.it. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@esempio.it"

I tag che la RFC 9989 riconosce sono questi:

• v: la versione. È obbligatorio, deve essere il primo tag e l'unico valore ammesso è DMARC1. Se manca o non è in prima posizione, il record viene ignorato per intero.
• p: la policy per il dominio e, salvo diversa indicazione, per i sottodomini. Valori none, quarantine, reject.
• sp e np: la policy per i sottodomini esistenti e per quelli che non esistono, come un fatture.esempio.it inventato da chi vuole spedire a tuo nome.
• rua: l'indirizzo che riceve i report aggregati. Se il tag manca, i server riceventi non devono generarli: senza rua hai una policy ma non vedi niente.
• ruf e fo: l'indirizzo per i report sui singoli messaggi falliti e le condizioni che li fanno scattare. Non contarci troppo: la RFC 9989 (sezione 10.2) riconosce che la maggior parte dei server riceventi rifiuta di inviarli, per ragioni di privacy.
• adkim e aspf: allineamento rilassato (r, predefinito) o stretto (s) per DKIM e SPF.
• t: la modalità di test, nuova nella RFC 9989. Con t=y chiedi di applicare la policy di un livello più morbida: reject diventa quarantine, quarantine diventa none.
• psd: un flag per gli operatori dei suffissi pubblici e per le organizzazioni con il DNS delegato per reparti.

Le tre policy: none, quarantine, reject

La RFC 9989 descrive le tre policy come preferenze del titolare del dominio verso i messaggi che non superano DMARC:

• none: nessuna preferenza espressa. I messaggi vengono consegnati come prima, ma tu ricevi i report. La RFC chiama questa fase Monitoring Mode. Se il tag p manca in un record altrimenti valido, il record vale come p=none.
• quarantine: consideri sospetti i messaggi che falliscono, pur ammettendo che qualcuno sia legittimo. La RFC 7489 indicava cosa può voler dire, a seconda del ricevente: cartella spam, controllo più approfondito, contrassegno di messaggio sospetto.
• reject: consideri ogni fallimento un uso non valido del dominio, e chiedi di rifiutare il messaggio.

Su reject la RFC 9989 è prudente. La sezione 7.4 chiede a chi lo pubblica di firmare con DKIM e non affidarsi al solo SPF, sconsiglia di usarlo sui domini i cui utenti scrivono a mailing list, e a chi vuole arrivarci suggerisce almeno un mese su p=none e un periodo altrettanto lungo su p=quarantine. Ai server riceventi chiede di non rifiutare sulla sola base di p=reject e, senza altre analisi, di trattare il messaggio come quarantine: è un segnale forte, non un interruttore.

DMARCbis: cosa cambia con la RFC 9989

La RFC 7489, di marzo 2015, era un documento Informational arrivato come submission indipendente, non da un gruppo di lavoro IETF. Il successore, noto come DMARCbis, è stato pubblicato a maggio 2026 come RFC 9989, nella categoria Standards Track, insieme a due documenti gemelli: la RFC 9990 sui report aggregati e la RFC 9991 sui report dei singoli messaggi. Il RFC Editor registra la RFC 7489 come resa obsoleta da tutte e tre.

Le differenze che toccano chi gestisce un dominio, dall'appendice C della RFC 9989:

• Via il tag pct. Applicava la policy a una percentuale dei messaggi, ma nella pratica era di solito applicato con precisione solo con i valori 0 e 100. Al suo posto c'è t: t=y corrisponde al vecchio pct=0 e t=n al vecchio pct=100. Nel registro IANA dei tag DMARC pct è ora marcato come storico.
• Via anche rf e ri, il formato dei report sui messaggi falliti e l'intervallo richiesto tra i report aggregati. Anche questi sono storici.
• Nuovi tag np e psd, descritti sopra.
• Addio alla Public Suffix List. Il dominio organizzativo si trova risalendo l'albero DNS (il DNS Tree Walk), non più con un elenco esterno. Un ricevente rimasto alla 7489 può arrivare a una conclusione diversa: la RFC indica come rimedio l'allineamento stretto e un record esplicito per ogni dominio usato nel From.

Non serve riscrivere tutto: la versione resta v=DMARC1 e un record con p, rua e allineamento impostati bene resta corretto. Il lavoro è togliere pct dove c'è e valutare np.

Cosa chiedono Google e Yahoo a chi invia

Le linee guida di Google per i mittenti di email distinguono due livelli, in vigore dal 1° febbraio 2024. Tutti i mittenti verso account Gmail personali devono avere almeno SPF o DKIM, record DNS diretti e inversi validi, TLS e un tasso di spam in Postmaster Tools sotto lo 0,3%. Chi invia più di 5.000 messaggi al giorno deve avere SPF e DKIM, DMARC pubblicato, il From allineato con il dominio SPF o DKIM e la disiscrizione con un clic per i messaggi di marketing e di iscrizione. Sul livello di policy la pagina è esplicita: "Il criterio di applicazione DMARC può essere impostato su none". Per DKIM Google richiede una chiave di almeno 1024 bit e consiglia 2048.

Due dettagli delle FAQ di Google contano più della soglia. I 5.000 messaggi si contano su tutto ciò che parte dallo stesso dominio principale, sottodomini compresi. E chi supera la soglia anche una sola volta resta classificato come mittente di email collettive in modo permanente. Le stesse FAQ annunciavano che da novembre 2025 Gmail avrebbe intensificato l'applicazione verso il traffico non conforme, con rifiuti temporanei e permanenti.

Yahoo, nella pagina Sender Requirements & Recommendations, chiede ai mittenti massivi SPF e DKIM, una policy DMARC valida almeno a p=none con esito pass, l'allineamento del From, e raccomanda con forza il tag rua. Non fissa una soglia: le FAQ definiscono massivo chi invia un volume significativo e dichiarano che il numero non verrà specificato. A chi ha un problema di spoofing indicano comunque quarantine o reject.

Per un'azienda del mid-market la domanda non è se manda newsletter, ma quante piattaforme spediscono con il suo dominio: CRM, marketing, fatturazione, helpdesk, e-commerce. Sommate, possono superare la soglia senza che nessuno l'abbia deciso.

Come si porta un dominio a DMARC, in quattro passi

1. Fai l'inventario di chi spedisce a tuo nome. La posta aziendale, ma anche ogni servizio esterno che manda email con il tuo dominio nel From. La RFC 9989 chiede che ogni messaggio produca almeno un identificatore autenticato allineato, e preferibilmente due: SPF e DKIM, entrambi.
2. Pubblica p=none con rua. I report aggregati sono file XML che la RFC raccomanda di far leggere a uno strumento, non a una persona.
3. Leggi i report e correggi. Troverai flussi legittimi che falliscono, spesso un fornitore configurato a metà, e flussi che non conosci. I primi vanno sistemati prima di stringere la policy: per la RFC è un obbligo, e possono servire molti mesi di report.
4. Stringi per gradi. quarantine, eventualmente con t=y per la fase di prova, poi reject dove ha senso. Per i sottodomini che non esistono, np permette una policy severa senza toccare il resto.

Dove si colloca DMARC nel quadro della sicurezza

DMARC lavora sulla posta che esce a tuo nome, non su quella che ti arriva. Riduce la possibilità che un cliente riceva una falsa fattura dal tuo dominio esatto, ma non impedisce a un dipendente di cliccare su un messaggio da un dominio somigliante: per quel lato servono le misure descritte in cos'è il phishing e cosa comporta per un'azienda e la formazione sul social engineering.

I report valgono anche oltre la consegna: un server sconosciuto che spedisce con il tuo dominio è un segnale di sicurezza, e ha senso che arrivi a chi presidia gli eventi, come descritto in cosa fa un SOC. È uno dei tasselli dei nostri servizi di cybersecurity, insieme a identità, endpoint e risposta agli incidenti.

Per sapere a che punto è il tuo dominio adesso, prova il verificatore gratuito SPF, DKIM e DMARC: legge i record pubblicati e ti dice cosa correggere, in pochi secondi.