DMARC è il meccanismo che collega l’autenticazione tecnica di un’email al dominio che il destinatario vede nel campo From. Il suo nome completo è Domain-based Message Authentication, Reporting, and Conformance e il punto più importante da capire è proprio questo: non basta che SPF o DKIM risultino validi; almeno uno dei due deve anche essere allineato al dominio del mittente visibile.
Questa differenza spiega molti casi apparentemente strani. Un servizio di invio può superare SPF, firmare correttamente con DKIM e produrre comunque dmarc=fail se utilizza domini che non sono allineati con quello mostrato nel From.
DMARC aggiunge poi altre due funzioni: permette al proprietario del dominio di esprimere una policy per i messaggi che non superano il controllo e può richiedere report che mostrano chi sta utilizzando quel dominio per inviare posta.
Non è però un filtro antispam universale e non garantisce che un’email finisca nella posta in arrivo. Serve soprattutto a rendere verificabile l’uso del dominio e a ridurre l’efficacia dello spoofing diretto.
In questa guida vediamo il meccanismo, la struttura di un record DMARC, come affrontare una configurazione DMARC senza passare prematuramente all’enforcement e cosa è cambiato con lo standard corrente RFC 9989.
DMARC: cos’è e quale problema risolve
Quando ricevi un’email, l’indirizzo mostrato nel campo From è uno degli elementi che utilizzi per capire chi sta scrivendo. Il problema è che il protocollo email, da solo, non rende quel dominio automaticamente affidabile.
Un attaccante può tentare di inviare un messaggio che appare come:
From: [email protected]
anche se non controlla realmente example.com.
SPF e DKIM aiutano ad autenticare la posta, ma lavorano su identificatori differenti. DMARC mette questi controlli in relazione con il dominio che compare nel From e permette quindi di verificare se l’uso di quel dominio è autorizzato.
Lo standard corrente è RFC 9989, pubblicato nel maggio 2026 e sostitutivo della precedente RFC 7489.
Perché SPF e DKIM da soli non risolvono lo stesso problema
SPF controlla se il server che sta inviando il messaggio è autorizzato per il dominio utilizzato nell’identità SMTP, normalmente quella associata al MAIL FROM.
DKIM funziona diversamente: il server applica una firma crittografica al messaggio e indica nel parametro d= il dominio responsabile della firma.
Entrambi possono quindi produrre un risultato valido senza utilizzare lo stesso dominio che compare nel From.
Immagina una newsletter inviata tramite un servizio esterno:
From: [email protected] Return-Path: [email protected] DKIM-Signature: ... d=provider-invio.example
Il provider potrebbe essere perfettamente autorizzato e SPF e DKIM potrebbero superare i rispettivi controlli. Ma se nessuna identità autenticata è allineata con example.com, DMARC non ottiene un pass.
Il valore di DMARC è proprio questo collegamento.
Se vuoi capire prima dove vengono pubblicate queste informazioni, nella guida su cos’è il DNS e come funziona trovi il contesto su record TXT, MX e struttura della zona DNS.
Cosa protegge DMARC e cosa non può proteggere
DMARC è particolarmente utile contro l’uso non autorizzato del dominio esatto nel campo From.
Se possiedi example.com, puoi dichiarare attraverso il DNS come deve essere autenticata la posta che utilizza quel dominio e puoi ricevere informazioni sui flussi che lo stanno usando.
Non significa però che chi riceve un’email da un dominio apparentemente simile sia automaticamente protetto.
Un aggressore potrebbe registrare:
examp1e.com example-clienti.com example-support.com
autenticare perfettamente quei domini e utilizzarli in una campagna fraudolenta.
Allo stesso modo, DMARC non impedisce l’invio da un account realmente compromesso e non stabilisce se il contenuto di un messaggio sia vero, sicuro o desiderato.
Per questo va considerato una parte della difesa contro il phishing, non un sostituto dei controlli sul contenuto, dell’antispam, della protezione degli account e delle procedure aziendali.
Come funziona DMARC: autenticazione, allineamento e dominio From
Il modo più semplice per comprendere DMARC è separare autenticazione e allineamento.
SPF e DKIM rispondono alla domanda:
questa specifica identità tecnica ha superato il proprio controllo?
DMARC aggiunge una seconda domanda:
l’identità autenticata appartiene allo stesso dominio, o allo stesso dominio organizzativo quando è ammesso l’allineamento relaxed, del dominio mostrato nel From?
RFC 9989 definisce infatti il dominio del campo RFC5322.From come Author Domain. Per ottenere dmarc=pass deve esistere almeno un identificatore SPF o DKIM che abbia superato il proprio controllo e sia allineato con l’Author Domain.
Come funziona l’allineamento SPF
Per SPF, DMARC confronta il dominio autenticato associato al RFC5321.MailFrom con quello del campo From.
Un caso semplice:
MAIL FROM: [email protected] From: [email protected]
Se SPF passa, i due domini sono identici e l’allineamento è anche strict.
Un altro scenario:
MAIL FROM: [email protected] From: [email protected]
Con l’allineamento relaxed, normalmente predefinito, i due identificatori possono risultare allineati perché appartengono allo stesso Organizational Domain.
Se invece abbiamo:
MAIL FROM: [email protected] From: [email protected]
SPF può tranquillamente risultare pass, ma quell’SPF non è allineato con il dominio visibile example.com.
È una distinzione importante: SPF pass non significa automaticamente DMARC pass.
Come funziona l’allineamento DKIM
Per DKIM il confronto avviene con il dominio indicato dal parametro d= della firma.
Per esempio:
From: [email protected] DKIM-Signature: ... d=example.com; ...
Una firma DKIM valida con d=example.com è allineata anche in modalità strict.
Con:
From: [email protected] DKIM-Signature: ... d=mail.example.com; ...
può invece esserci allineamento relaxed.
Se il provider firma esclusivamente con:
d=provider.example
la firma può essere crittograficamente valida, ma non fornisce un DKIM allineato con example.com.
I tag adkim e aspf permettono di chiedere rispettivamente allineamento DKIM e SPF relaxed (r) o strict (s). RFC 9989 indica r come default per entrambi e osserva che, nella pratica, l’allineamento relaxed è sufficiente per la maggior parte dei domini.
Perché SPF o DKIM possono passare mentre DMARC fallisce
Il comportamento diventa più chiaro mettendo insieme i risultati.
| SPF | SPF allineato | DKIM | DKIM allineato | DMARC |
|---|---|---|---|---|
| Pass | Sì | Fail | — | Pass |
| Fail | — | Pass | Sì | Pass |
| Pass | No | Pass | No | Fail |
| Pass | No | Fail | — | Fail |
| Fail | — | Pass | No | Fail |
DMARC non richiede quindi che entrambi i meccanismi producano necessariamente un pass allineato. Ne basta almeno uno.
Questo non significa che convenga progettare deliberatamente un’infrastruttura fragile basata su un solo meccanismo. RFC 9989 raccomanda di usare sia DKIM sia SPF e i principali mailbox provider impongono requisiti ancora più stringenti ai mittenti ad alto volume.
La distinzione diventa particolarmente utile quando devi diagnosticare un servizio esterno. Se SPF passa ma il Return-Path appartiene al provider, devi controllare se il provider permette un dominio di bounce personalizzato. Se DKIM passa ma d= appartiene al provider, devi verificare se puoi configurare una firma DKIM sul tuo dominio.
Record DMARC: sintassi, tag ed esempi
Il record DMARC è pubblicato nel DNS come record TXT sotto il label _dmarc.
Per il dominio:
example.com
il nome interrogato sarà:
_dmarc.example.com
Non stai quindi creando un record TXT generico alla radice del dominio: stai pubblicando la policy su un nome DNS preciso.
Un record iniziale molto semplice può essere:
v=DMARC1; p=none; rua=mailto:[email protected]
Questo dichiara DMARC, mantiene il dominio in modalità di monitoraggio e richiede l’invio dei report aggregati all’indirizzo indicato.
Dove pubblicare il record TXT _dmarc
Il record va inserito nel servizio che gestisce i nameserver autorevoli del dominio.
Potrebbe essere il registrar, il provider hosting, Cloudflare, un servizio DNS separato o l’infrastruttura aziendale. Non conta dove hai comprato il dominio: conta quale sistema è realmente autorevole per la zona DNS.
Prima di aggiungere il record controlla quindi dove sono delegati i nameserver.
A seconda del pannello, il campo nome potrebbe richiedere:
_dmarc
oppure:
_dmarc.example.com
Non copiare automaticamente l’intero hostname senza verificare il comportamento del pannello, perché alcuni provider aggiungono il dominio in modo automatico.
Un altro errore serio è creare più record DMARC distinti per lo stesso nome. RFC 9989 specifica che, se una query restituisce più DMARC Policy Record validi per lo stesso target, vengono scartati tutti.
Se devi aggiungere una nuova opzione, in genere devi modificare l’unico record esistente, non crearne un secondo.
I tag che servono davvero per un dominio normale
RFC 9989 usa una sintassi tag=value separata da punti e virgola.
| Tag | Funzione | Nota pratica |
|---|---|---|
v | versione DMARC | v=DMARC1; deve essere il primo tag |
p | policy principale | none, quarantine, reject |
rua | destinazione dei report aggregati | molto utile durante rollout e monitoraggio |
ruf | destinazione dei failure report | opzionale e non supportato uniformemente |
adkim | alignment DKIM | r relaxed, s strict |
aspf | alignment SPF | r relaxed, s strict |
sp | policy per sottodomini esistenti | opzionale |
np | policy per sottodomini inesistenti | opzionale |
fo | condizioni richieste per failure report | rilevante solo con ruf |
t | test mode | introdotto nello standard corrente |
Il valore DMARC1 è case-sensitive e v deve comparire per primo; in caso contrario il record non viene considerato un DMARC Policy Record valido.
Per una configurazione iniziale non è necessario riempire il record di tag. Un record più complesso non è automaticamente più sicuro.
Una base ragionevole per il monitoraggio è:
v=DMARC1; p=none; rua=mailto:[email protected]
Poi le scelte successive vanno fatte sulla base dei flussi reali e dei report.
RFC 9989: cosa cambia rispetto alle vecchie guide basate su RFC 7489
Qui esiste una differenza importante rispetto a molte guide ancora online.
Nel maggio 2026 RFC 9989 ha sostituito RFC 7489 e il registro IANA dei parametri DMARC classifica oggi questi tag come historic:
pct rf ri
pct veniva utilizzato per chiedere l’applicazione della policy soltanto a una percentuale dei messaggi che fallivano DMARC. L’esperienza operativa ha però mostrato comportamenti poco uniformi tra implementazioni, soprattutto per valori diversi da 0 e 100.
RFC 9989 ha quindi rimosso pct e introdotto t per conservare una parte della funzione di testing in forma più esplicita.
Questo significa che esempi come:
v=DMARC1; p=reject; pct=25
appartengono al modello della specifica precedente e non dovrebbero essere il punto di partenza per una nuova configurazione basata sullo standard corrente.
Potresti comunque incontrare pct, ri o rf in pannelli, generatori e documentazione non ancora aggiornata. La loro presenza nel mercato non cambia però lo stato registrato oggi da IANA.
Policy DMARC: none, quarantine e reject
La policy DMARC descrive la preferenza del proprietario del dominio per i messaggi che non superano la valutazione.
Le tre possibilità principali sono:
| Policy | Significato operativo |
|---|---|
p=none | nessuna preferenza di trattamento basata sulla policy DMARC |
p=quarantine | il messaggio fallito viene considerato sospetto |
p=reject | il proprietario considera il fallimento una chiara indicazione di uso non valido del dominio |
La tabella può dare l’impressione di una scala lineare nella quale reject sia sempre il livello finale e migliore.
Non è così semplice.
La policy corretta dipende dal modo in cui il dominio viene realmente usato, dai flussi indiretti, dai servizi esterni e dal rischio di interrompere posta legittima.
p=none: monitoraggio senza enforcement
Con:
v=DMARC1; p=none; rua=mailto:[email protected]
il dominio può entrare in Monitoring Mode.
Il receiver continua a calcolare DMARC, quindi i messaggi possono risultare pass o fail, ma il proprietario non esprime attraverso p una preferenza di trattamento per i fallimenti.
Non è quindi corretto dire che con p=none “DMARC è disattivato”.
La validazione esiste e i report possono essere raccolti.
RFC 9989 suggerisce proprio di partire normalmente da p=none, perché anche un’infrastruttura che sembra semplice può nascondere un gestionale, un CRM, una piattaforma newsletter, un sistema di ticket, un ecommerce o un’applicazione che invia email senza essere stata inclusa nell’inventario.
p=quarantine: quando ha senso passare alla quarantena
Con:
v=DMARC1; p=quarantine; rua=mailto:[email protected]
stai indicando che i messaggi che falliscono DMARC devono essere considerati sospetti.
La decisione concreta resta al receiver: “quarantine” non significa che ogni provider utilizzerà esattamente la stessa cartella o lo stesso trattamento.
Il passaggio ha senso quando i report mostrano che i flussi legittimi sono conosciuti e l’autenticazione è stata corretta.
Cambiare policy prima di aver sistemato i mittenti autorizzati può invece trasformare un errore di configurazione in un problema di recapito.
p=reject: perché non è automaticamente la scelta migliore
Con:
v=DMARC1; p=reject; rua=mailto:[email protected]
il proprietario del dominio esprime la posizione più severa rispetto ai fallimenti DMARC.
Ma RFC 9989 introduce una qualificazione molto importante: i domini utilizzati da utenti generici che partecipano, per esempio, a mailing list possono incontrare problemi con flussi indiretti, forwarding e sistemi che modificano i messaggi durante il percorso.
Lo standard corrente afferma esplicitamente che i domini di posta general-purpose non dovrebbero passare automaticamente a p=reject e raccomanda di valutare i report e l’impatto sull’interoperabilità prima di farlo.
C’è anche un secondo punto spesso trascurato: p=reject esprime una policy del proprietario del dominio, ma non è un comando assoluto che obbliga il receiver a rifiutare meccanicamente ogni messaggio fallito. RFC 9989 richiede ai receiver di considerare anche altri segnali e di non rifiutare esclusivamente sulla base della policy pubblicata.
Nella pratica, però, non puoi basare una strategia sul presupposto che ogni provider applichi mitigazioni identiche. Per il proprietario del dominio la regola prudente resta: non arrivare all’enforcement finché non hai compreso i flussi legittimi.
t=y e il nuovo test mode al posto del vecchio approccio basato su pct
RFC 9989 introduce:
t=y
come segnale di test della policy.
Il comportamento previsto è un livello inferiore rispetto alla policy dichiarata:
p=quarantine; t=y
indica un test nel quale i fallimenti vengono trattati come none.
Con:
p=reject; t=y
il livello atteso diventa invece quarantine.
t=y non modifica la generazione dei report e non ha alcun effetto quando p=none.
Non va quindi letto come il nuovo equivalente di:
pct=25
Non definisce una percentuale di messaggi. Serve a testare la policy dichiarata riducendo di un livello il trattamento previsto.
Per una prima implementazione, partire da p=none e analizzare i report resta comunque il percorso più semplice da comprendere e da controllare.
Configurazione DMARC: come procedere senza bloccare la posta legittima
Una buona configurazione DMARC non comincia dal generatore del record.
Comincia dall’inventario.
Il rischio maggiore non è sbagliare un punto e virgola: è dimenticare un sistema che usa legittimamente il tuo dominio per inviare posta.
Il percorso operativo più robusto è:
inventario mittenti
↓
SPF e DKIM
↓
alignment
↓
p=none + report
↓
correzione dei flussi
↓
decisione sull'enforcement
1. Individua tutti i servizi che inviano email per il dominio
Prima di modificare DMARC, elenca ogni sorgente autorizzata.
Per esempio:
- server di posta aziendale;
- Google Workspace o Microsoft 365;
- piattaforma newsletter;
- CRM;
- help desk;
- ecommerce;
- sito WordPress;
- sistemi per fatture e notifiche;
- applicazioni gestionali;
- servizi transazionali;
- piattaforme di recruiting;
- servizi utilizzati da reparti o sedi diverse.
Qui emerge uno dei problemi tipici delle organizzazioni più grandi: il team che gestisce il DNS spesso non conosce tutti i sistemi dai quali parte posta con il dominio aziendale.
I report DMARC servono anche a far emergere proprio queste sorgenti dimenticate.
2. Verifica SPF e DKIM su ogni sorgente legittima
Non basta controllare che il dominio abbia “un SPF” e “un DKIM”.
Devi verificare il comportamento delle singole sorgenti.
Per SPF chiediti:
SPF passa? Qual è il dominio RFC5321.MailFrom? È allineato con il dominio nel From?
Per DKIM:
La firma è valida? Qual è il valore d=? È allineato con il dominio nel From?
Una sorgente potrebbe avere SPF perfettamente configurato per il proprio dominio tecnico e continuare a non contribuire al pass DMARC.
Lo stesso vale per DKIM.
Quando usi piattaforme terze cerca quindi funzioni come custom Return-Path, branded sending domain, custom bounce domain o DKIM personalizzato. I nomi cambiano da provider a provider, ma il problema sottostante è sempre l’allineamento.
3. Pubblica DMARC e attiva il reporting
Quando SPF e DKIM sono ragionevolmente sotto controllo, puoi pubblicare una prima configurazione di monitoraggio:
v=DMARC1; p=none; rua=mailto:[email protected]
L’indirizzo utilizzato per i report deve esistere e devi avere un modo sostenibile per elaborarne il contenuto.
I report aggregati non sono normali messaggi da leggere uno alla volta. RFC 9989 raccomanda l’elaborazione automatizzata perché il formato è pensato per essere interpretato dalle macchine.
Puoi sviluppare un tuo processo oppure utilizzare un servizio di analisi dei report. Se rua punta a un dominio esterno, DMARC prevede inoltre un meccanismo di autorizzazione della destinazione: non puoi semplicemente ordinare ai receiver di inviare report a un dominio terzo che non ha accettato di riceverli.
4. Correggi i problemi di allineamento prima di aumentare l’enforcement
A questo punto il lavoro non consiste nel guardare quante righe sono verdi o rosse.
Devi classificare le sorgenti.
Per ogni flusso che fallisce chiediti:
è posta legittima? è una configurazione sbagliata? è un servizio che non conoscevo? è forwarding o un flusso indiretto? è spoofing?
Se una sorgente è legittima, correggi SPF, DKIM o l’allineamento.
Se è sconosciuta, non significa automaticamente che sia malevola: potrebbe appartenere a un servizio dimenticato da un reparto.
Solo dopo aver ridotto questa incertezza ha senso valutare quarantine, reject o il test mode previsto dallo standard corrente.
Report DMARC: cosa mostrano e come usarli
Uno dei motivi per cui DMARC è più utile di un semplice “se fallisce, blocca” è il reporting.
I report permettono al proprietario del dominio di osservare come il dominio viene utilizzato e quali sorgenti producono risultati coerenti o incoerenti con la configurazione prevista.
Esistono due famiglie da distinguere: report aggregati e failure report.
Report aggregati rua: cosa puoi realmente ricavare
Il tag:
rua=mailto:[email protected]
richiede report aggregati.
Questi dati aiutano a capire, tra le altre cose:
- quali sorgenti inviano messaggi usando il dominio;
- quanti messaggi vengono osservati;
- quali risultati producono SPF e DKIM;
- quali sorgenti risultano allineate;
- quali falliscono DMARC;
- quale policy è stata valutata.
Il loro valore non è soltanto individuare abusi.
Durante il rollout servono soprattutto a scoprire posta legittima configurata male.
Se compare una sorgente sconosciuta con migliaia di messaggi, la domanda non dovrebbe essere subito “come la blocco?”, ma “chi sta usando questo IP o questo provider e perché?”.
Un CRM dimenticato può apparire inizialmente nello stesso insieme di dati di un tentativo di spoofing.
La differenza emerge dall’indagine.
Report di failure ruf: disponibilità, privacy e limiti
Il tag ruf richiede invece informazioni specifiche sui singoli fallimenti.
In teoria può offrire dettagli diagnostici molto più ricchi:
ruf=mailto:[email protected]
Nella pratica va usato con maggiore cautela.
La nuova RFC 9991, dedicata ai failure report DMARC, sottolinea che questi report possono includere header e perfino contenuto del messaggio, con possibili dati personali o informazioni riservate. Per questo molti grandi receiver ne limitano o disabilitano la generazione.
ruf non è quindi qualcosa da aggiungere automaticamente perché “più report sono meglio”.
Per il monitoraggio ordinario, i report aggregati rappresentano normalmente la base più utile e meno problematica.
Come riconoscere mittenti sconosciuti, servizi terzi e problemi di alignment
Quando analizzi i report, separa almeno quattro casi.
Sorgente conosciuta e DMARC pass
È il caso atteso. Verifica comunque che la configurazione corrisponda al servizio che pensi di utilizzare.
Sorgente conosciuta ma DMARC fail
È probabilmente il caso più urgente prima di cambiare policy. Controlla Return-Path, DKIM d=, eventuali sottodomini e configurazioni del provider.
Sorgente sconosciuta ma plausibile
Potrebbe essere un servizio dimenticato. Prima di considerarla abusiva, verifica internamente.
Sorgente sconosciuta e non autorizzata
Può essere traffico spoofed o comunque un uso non previsto del dominio. È uno dei segnali che DMARC permette di rendere visibili.
Il report non sostituisce quindi la conoscenza dell’infrastruttura. La completa.
Come testare e verificare DMARC dopo la configurazione
Pubblicare il record senza verificarlo lascia il lavoro a metà.
Conviene controllare almeno tre livelli:
DNS → messaggio reale → report
Il primo conferma che il record sia effettivamente pubblicato. Il secondo mostra cosa succede all’autenticazione di una vera email. Il terzo consente di capire se il comportamento resta coerente nel tempo e tra sorgenti differenti.
Controllare il record DNS non basta
Da un terminale puoi verificare il TXT con:
dig TXT _dmarc.example.com
oppure:
nslookup -type=TXT _dmarc.example.com
Il risultato dovrebbe contenere il record previsto.
Questa verifica trova diversi errori:
- record pubblicato nel DNS sbagliato;
- hostname errato;
- valore non aggiornato;
- record mancante;
- più record DMARC distinti;
- problemi di sintassi evidenti.
Ma una query DNS non ti dice se una campagna inviata da un certo servizio supera realmente l’allineamento.
Per quello serve un messaggio vero.
Verificare Authentication-Results su un messaggio reale
Invia un messaggio di test attraverso lo stesso servizio che vuoi validare e osserva gli header ricevuti.
In un header potresti trovare, in forma diversa a seconda del receiver, informazioni simili a:
spf=pass dkim=pass dmarc=pass
oppure:
spf=pass dkim=pass dmarc=fail
Il secondo caso non è contraddittorio.
Devi verificare quali domini sono stati autenticati e se almeno uno è allineato con quello del From.
Per esempio:
From: [email protected] SPF: pass per provider.example DKIM: pass con d=provider.example
può produrre un fallimento DMARC perché entrambi i meccanismi hanno autenticato un dominio diverso.
Un altro messaggio potrebbe invece avere:
From: [email protected] DKIM: pass con d=mail.example.com
e ottenere DMARC pass in modalità relaxed.
Gli errori più comuni quando un record sembra corretto ma DMARC fallisce
Quando il TXT è presente ma i messaggi continuano a fallire, controllerei in questo ordine:
- SPF passa ma non è allineato. Il Return-Path utilizza il dominio del provider.
- DKIM passa ma non è allineato. La firma utilizza un
d=esterno. - Una sorgente non firma DKIM. Può diventare fragile soprattutto in presenza di forwarding.
- Il servizio usa un dominio o sottodominio inatteso.
- Sono presenti più record DMARC per lo stesso target.
- La modifica DNS non è ancora visibile attraverso i resolver che stai interrogando.
- Il messaggio passa attraverso sistemi intermedi che alterano il flusso.
- Stai testando un servizio diverso da quello che produce il problema reale.
L’ultimo caso capita più spesso di quanto sembri: verificare una normale email inviata dalla casella aziendale non dimostra che la piattaforma newsletter, il CRM o WordPress siano configurati nello stesso modo.
Se il dominio viene utilizzato per campagne, automazioni o messaggi transazionali, DMARC va quindi considerato dentro l’intero sistema di email marketing, non come un TXT isolato.
DMARC è obbligatorio? Requisiti attuali di Gmail, Yahoo e Outlook.com
Non esiste una regola universale di Internet che obblighi qualsiasi dominio, in qualsiasi situazione, a pubblicare DMARC.
Esistono però requisiti dei mailbox provider che rendono l’autenticazione obbligatoria per determinate categorie di mittenti.
Per chi utilizza email commerciali, newsletter o grandi volumi, questa distinzione ormai è operativa, non teorica.
| Provider | Ambito rilevante | SPF/DKIM | DMARC |
|---|---|---|---|
| Gmail | circa 5.000+ messaggi/giorno verso account Gmail personali | SPF e DKIM | richiesto, p=none ammesso |
| Yahoo | bulk sender; Yahoo non pubblica una soglia numerica fissa | SPF e DKIM | valido, almeno p=none, DMARC deve passare |
| Outlook.com | domini oltre 5.000 email/giorno nel servizio consumer | SPF e DKIM richiesti/pass | almeno p=none + alignment |
Questi requisiti possono cambiare. Per questo vanno verificati sulle fonti del provider prima di un intervento operativo.
Gmail e la soglia dei bulk sender
Le linee guida Gmail per i mittenti distinguono i requisiti generali da quelli per chi invia circa 5.000 o più messaggi al giorno verso account Gmail personali.
Per i mittenti ad alto volume Google richiede SPF e DKIM, un record DMARC e l’allineamento del dominio nel From con SPF oppure DKIM. La policy DMARC può essere impostata su none.
Questo è un buon esempio del perché p=none non significhi “DMARC assente”.
Google richiede che il meccanismo sia configurato anche se non obbliga il mittente a partire da una policy di enforcement.
Yahoo e i requisiti per i mittenti bulk
Yahoo utilizza una definizione di bulk sender basata sul volume significativo, ma nella propria FAQ dichiara esplicitamente di non pubblicare una soglia numerica. Non va quindi copiata automaticamente la soglia Gmail dei 5.000 messaggi e attribuita anche a Yahoo.
Le Sender Best Practices di Yahoo richiedono ai bulk sender SPF e DKIM, una policy DMARC valida almeno p=none e l’allineamento del From con SPF oppure DKIM. Yahoo indica inoltre che l’allineamento relaxed è accettabile.
Se stai progettando una newsletter, questo significa che autenticazione, gestione della lista, disiscrizione e reputazione vanno pensate insieme.
Outlook.com e i requisiti per i mittenti ad alto volume
Microsoft ha introdotto requisiti più severi per i domini che inviano oltre 5.000 email al giorno verso il proprio ecosistema consumer Outlook.com, che comprende indirizzi outlook.com, hotmail.com e live.com.
Secondo i requisiti pubblicati da Microsoft, SPF e DKIM devono superare i controlli e DMARC deve essere presente almeno con p=none, con alignment attraverso SPF o DKIM. Microsoft ha indicato l’avvio dell’enforcement con rifiuto dei messaggi non conformi dal 5 maggio 2025.
L’ambito dichiarato da Microsoft in quella comunicazione è Outlook.com consumer. Non va quindi trasformato automaticamente in una regola identica per ogni ambiente Microsoft 365 o per ogni scenario di posta aziendale.
Il punto comune tra i tre ecosistemi è però ormai evidente: l’autenticazione del dominio non è più un dettaglio opzionale per chi invia grandi volumi.
Conclusione
DMARC funziona bene quando viene trattato come un processo, non come una stringa da copiare nel DNS.
Il percorso corretto è:
conosci i mittenti → configura SPF e DKIM → verifica l'allineamento → pubblica DMARC → raccogli i report → correggi i flussi legittimi → valuta l'enforcement
La distinzione decisiva è l’allineamento. SPF e DKIM possono risultare validi e DMARC può continuare a fallire se i domini autenticati non corrispondono, secondo le regole relaxed o strict, al dominio che il destinatario vede nel From.
Per questo partire immediatamente da p=reject raramente è la parte intelligente della configurazione. Prima devi sapere chi invia davvero posta per il dominio e quali sistemi dipendono da quell’identità.
C’è poi un cambiamento da non ignorare nelle configurazioni nuove: lo standard corrente è RFC 9989. pct, ri e rf sono oggi classificati come historic e il test mode utilizza il nuovo tag t.
Se devi configurare DMARC su un dominio reale, la prima domanda quindi non è “quale record devo copiare?”. È molto più utile chiederti:
quali sistemi usano oggi il mio dominio nel From, e quanti di questi producono realmente un SPF o un DKIM allineato?
Quando hai questa risposta, il record diventa la parte facile.