Perché una riga del tuo report DMARC mostra spf=fail anche se il dominio resta protetto e il messaggio è comunque arrivato nella casella di posta? Per ogni sorgente di invio, un report DMARC aggregato elenca il risultato SPF. Aggiunge il risultato DKIM e la decisione effettivamente applicata dal server ricevente. Un SPF fallito abbinato a un DKIM allineato con esito positivo non compromette nulla: la specifica DMARC considera valido il messaggio non appena uno dei due meccanismi si allinea con il dominio visibile nell’header From.
È esattamente il tipo di riga che preoccupa a torto quando le campagne finiscono in spam e lo strumento di email marketing mostra comunque un tasso di deliverability tutto verde. Se le basi dell’autenticazione email (SPF, DKIM, DMARC) non sono ancora chiare, il protocollo DMARC spiegato pone le fondamenta prima di andare oltre. Questa guida resta concentrata su un solo punto: leggere un report aggregato campo per campo e distinguere una riga normale da un vero allarme.
Dove arriva il report e in quale formato
Il report aggregato viene inviato all’indirizzo dichiarato nel tag rua= del record DNS _dmarc, generalmente una volta al giorno per ogni provider ricevente (Google, Microsoft, Yahoo). I dettagli dei tag DNS che governano questo invio sono trattati in l’articolo sui tag DMARCbis da correggere prima del passaggio del 2026; questo articolo parte dal presupposto che il DNS sia già configurato. Ogni messaggio arriva come allegato compresso, un file XML dentro un archivio .zip o .gz. Va decompresso prima della lettura, oppure si può usare un analizzatore che lo fa automaticamente.
MailerCheck distingue nel 2024 i report aggregati dai report forensi: i primi riassumono l’attività di autenticazione in un determinato periodo, i secondi dettagliano un fallimento specifico e restano raramente implementati dai provider di posta (MailerCheck, 2024). Non transita nulla di sensibile. Quasi tutto il monitoraggio DMARC si basa quindi sull’aggregato. È anche la policy DMARC che Gmail e Yahoo richiedono dal 2024 per i domini che inviano più di 5.000 messaggi al giorno. L’aggregato resta il principale strumento per verificarne l’applicazione.
La struttura dell’XML, campo per campo
Il file XML si organizza in tre blocchi. report_metadata identifica il mittente del report (org_name, email, periodo coperto). policy_published riprende la policy DMARC pubblicata dal tuo dominio al momento dell’analisi. Il blocco record contiene una o più righe row, ciascuna corrispondente a una combinazione unica di sorgente e risultati.
Per interpretare una riga senza perdersi, l’ordine di lettura conta.
- Identificare la sorgente: source_ip indica l’indirizzo IP che ha effettivamente inviato il messaggio, da incrociare con un reverse DNS per capire se si tratta del tuo ESP, di un relay di terze parti o di un IP sconosciuto.
- Osservare il volume: count indica il numero di messaggi associati a questa combinazione esatta nell’intero periodo del report.
- Leggere la decisione applicata: disposition (none, quarantine o reject) nel blocco policy_evaluated, quella effettivamente presa dal server ricevente.
- Confrontare dkim e spf in policy_evaluated: questi due valori indicano il risultato di allineamento, distinto dal risultato grezzo del protocollo.
- Verificare auth_results per il risultato grezzo di ciascun meccanismo e il dominio effettivamente firmatario o dichiarato.
Questa distinzione tra allineamento (policy_evaluated) e risultato grezzo (auth_results) è all’origine della maggior parte delle confusioni. Un SPF tecnicamente valido sul dominio di envelope può mostrare fail in policy_evaluated perché quel dominio non corrisponde al dominio visibile nell’header From. È esattamente il meccanismo che spiega il caso seguente.
Le 4 combinazioni DKIM x SPF e il loro verdetto DMARC
Un report aggregato mostra 4 configurazioni ricorrenti, ciascuna corrispondente a uno scenario diverso tra il tuo server di invio e la casella del destinatario.
| DKIM | SPF | Risultato DMARC | Causa più frequente |
|---|---|---|---|
| Pass, allineato | Pass, allineato | Pass | Invio diretto dall’infrastruttura dichiarata nel DNS |
| Pass, allineato | Fail | Pass, tramite DKIM | Forwarding, mailing list, inoltro della casella di posta |
| Fail | Pass, allineato | Pass, tramite SPF | Relay che non firma il messaggio o firma compromessa lungo il percorso |
| Fail | Fail | Fail | Spoofing del dominio o sorgente di invio dichiarata male nel DNS |
Solo la 4ª riga richiede una correzione immediata. Le prime 3 rientrano in un funzionamento previsto dalla specifica, ciascuna con la propria lettura.
SPF fallito, DKIM riuscito: c’è da preoccuparsi?
No, nella maggior parte dei casi. L’SPF verifica l’indirizzo MAIL FROM, trasmesso tramite il comando omonimo nel dialogo SMTP subito dopo lo scambio EHLO iniziale, cioè l’indirizzo di envelope. Il DKIM firma il contenuto del messaggio con una chiave privata legata al dominio mittente, una firma che viaggia con il messaggio indipendentemente dal server che lo inoltra in seguito. Quando un destinatario inoltra un’email verso un’altra casella o quando una mailing list ridistribuisce un messaggio ai suoi iscritti, il server relay diventa il nuovo IP di invio. L’SPF, che verifica l’IP rispetto al record del dominio di origine, fallisce meccanicamente. La firma DKIM, invece, resta intatta finché il corpo e gli header firmati non vengono modificati lungo il percorso.
Spamresource documenta nel novembre 2025 un rifiuto Microsoft che illustra bene questo meccanismo, nella direzione opposta: un messaggio con DKIM pass e DMARC pass è stato bloccato perché l’SPF, invece, falliva.
550 5.7.515 Access denied, sending domain doesn’t meet the required authentication level. Spf= Fail, Dkim= Pass, DMARC= Pass
Il codice di stato esteso 5.7.515 segnala qui un requisito specifico di Microsoft, un livello aggiunto sopra il risultato DMARC stesso. Da maggio 2025, Microsoft impone ai mittenti ad alto volume di superare simultaneamente i 3 meccanismi (SPF, DKIM, DMARC), anche quando la specifica DMARC stessa si accontenta di un solo allineamento riuscito (spamresource.com, 2025). L’SPF fail identificato in questo caso specifico derivava, secondo lo stesso articolo, da un inoltro verso una casella ospitata fuori dai server Microsoft. È un punto da conoscere prima di spiegare a un CMO che l’open rate scende: DMARC può mostrare pass nel tuo report pur lasciando alcuni messaggi bloccati da una regola specifica del provider ricevente.
Due elementi distinguono questo caso da un vero problema di configurazione da correggere. Prima di tutto il volume: poche righe isolate con un count basso, distribuite su IP diversi, corrispondono più a forwarding individuale che a un’intera campagna. Poi la sorgente: un reverse DNS su questi source_ip punta generalmente a un provider di posta consumer o a un server di mailing list, mai alla tua infrastruttura di invio. Un SPF fail ripetuto sui tuoi stessi IP di invio, escluso qualsiasi forwarding identificabile, indica un’altra causa: il limite delle 10 ricerche DNS del record SPF, da verificare prima di concludere troppo in fretta che si tratti di un semplice inoltro.
Errori comuni nella lettura di un report aggregato
Primo errore: confondere il risultato grezzo di auth_results con il risultato di allineamento di policy_evaluated. Un SPF può riuscire tecnicamente sul dominio di envelope pur fallendo in allineamento perché quel dominio differisce dal From visibile, uno scenario frequente tra i mittenti che passano attraverso un IP pool condiviso presso un provider terzo.
Secondo errore: trattare un solo report come prova definitiva. I grandi provider (Google, Microsoft, Yahoo) inviano report quotidiani. Un incidente isolato può comparire in un solo giorno e sparire il giorno dopo. Verifica count e disposition su almeno una settimana prima di trarre conclusioni.
Terzo errore: ignorare il campo org_name del blocco report_metadata. Identifica chi ha prodotto il report, utile per individuare un provider secondario che applica una propria policy di filtraggio oltre alla tua, indipendentemente dai feedback loop degli ISP a cui sei già iscritto dal tuo lato.
Cosa cambia per la tua deliverability
Un report pulito, con un disposition a none o quarantine coerente sulle righe non di terze parti, conferma una sender reputation stabile lato autenticazione. È un segnale diverso dal monitoraggio post-invio abituale: l’open rate o il bounce rate mostra l’effetto lato destinatario, il report DMARC mostra la causa lato server ricevente, ancora prima che il messaggio raggiunga una casella. I due si completano senza sostituirsi. Postmaster Gmail e l’equivalente Microsoft, il SNDS (Smart Network Data Services), offrono una vista simile lato reputazione IP, da incrociare con gli stessi source_ip individuati nel report.
Una volta confermata l’autenticazione pulita per più giorni, la variabile successiva che pesa sulla reputazione resta la pulizia della lista inviata. Un tasso di hard bounce elevato danneggia la sender reputation con la stessa sicurezza di un SPF mal allineato, e nessuna riga del report DMARC lo rivela. Far passare un campione della prossima lista attraverso una verifica prima dell’invio permette di capire se il freno viene dall’autenticazione o dalla list hygiene.
Cosa non copre il report aggregato
Un report DMARC non dice nulla sul contenuto del messaggio, sul tasso di reclami reale lato casella di posta, né sui domini simili (typosquatting) che non hanno mai pubblicato un record DMARC e sfuggono quindi completamente a questo meccanismo di reporting. Passare a p=reject blocca lo spoofing diretto del tuo dominio, un prerequisito tecnico per attivare in seguito BIMI. Resta però senza effetto su un dominio visivamente simile registrato da terzi. Le 5 cose che DMARC non può fare dettagliano questi punti ciechi oltre il reporting.
Conserva i tuoi report per diverse settimane prima di modificare la policy. È l’unico modo per distinguere un segnale reale da un rumore passeggero. Un report DMARC aggregato racconta il percorso reale di un messaggio, riga dopo riga, fino alla casella di posta.
