DMARC fallisce ma SPF e DKIM passano: come trovare la causa

Apri un report DMARC o l'header di un messaggio e vedi spf=pass e dkim=pass accanto a dmarc=fail. Non c'è niente di rotto nel modo in cui sembra: entrambi i controlli sono passati, ma non per il dominio che interessa a DMARC. Questa guida è un percorso di risoluzione per esattamente questa situazione. Presuppone che tu sappia già cos'è l'allineamento e voglia capire quale delle cause più comuni hai, nell'ordine in cui sono più probabili.

In breve#

DMARC passa quando SPF o DKIM passa ed è allineato con il dominio dell'indirizzo From visibile. "Pass" e "allineato" sono due domande distinte. SPF viene confrontato con il dominio del Return-Path (mittente della busta), e DKIM con il dominio d= della firma. Se il tuo servizio di posta firma con il proprio dominio e gestisce i bounce con il proprio dominio, entrambi i controlli passano e nessuno dei due si allinea. La soluzione è quasi sempre la stessa: configura un dominio di firma DKIM personalizzato sul tuo dominio, e un dominio return-path personalizzato se vuoi che si allinei anche SPF. Controlla i tag in modalità strict, gli inoltri e i sottodomini solo dopo. Per il concetto in sé, vedi la guida a SPF, DKIM e DMARC.

Con cosa viene confrontato ogni controllo#

Ogni messaggio porta tre domini che contano, e DMARC li mette in relazione a coppie. Gran parte della confusione sparisce quando sai dire quale dominio usa ciascun controllo.

Ecco che aspetto ha il classico errore in un messaggio ricevuto. Il From è tuo, entrambi i controlli passano, e gli altri due domini appartengono al mittente:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.mail.vendor.example;
  dkim=pass header.d=mail.vendor.example;
  dmarc=fail header.from=yourdomain.com

L'analizzatore di header email mostra i verdetti di SPF, DKIM e DMARC e i campi From e Return-Path. Il valore d= di DKIM lo leggi tu dalla riga DKIM-Signature. Se hai solo un report aggregato, le stesse informazioni stanno in auth_results (risultati grezzi e domini) rispetto a policy_evaluated (il verdetto allineato). La guida alla lettura dei report spiega questa distinzione.

Il percorso decisionale#

Scorri questo elenco e fermati al primo passaggio che corrisponde. Ogni passaggio è una causa diversa con una soluzione diversa.

1. DKIM passa, ma d= è il dominio del mittente. È la causa più comune e la soluzione migliore. Attiva la firma DKIM personalizzata (a volte chiamata dominio brandizzato o autenticato) nel servizio di invio, in modo che firmi con d=yourdomain.com o con un suo sottodominio. DKIM viaggia con il messaggio, quindi continua ad allinearsi anche dopo un inoltro.
2. SPF passa, ma il Return-Path è il dominio del mittente. SPF può allinearsi solo se il mittente della busta è il tuo dominio. Configura nel servizio un dominio return-path (bounce) personalizzato, di solito un sottodominio come bounce.yourdomain.com indirizzato al provider tramite CNAME oppure tramite i record MX e TXT che ti fornisce. Aggiungere il provider al tuo record SPF non risolve il problema: SPF viene verificato sul dominio del Return-Path, che è quello del provider, quindi il tuo record non viene mai consultato per quel messaggio.
3. Entrambi sono personalizzati ma DMARC fallisce ancora. Guarda adkim e aspf nel tuo record DMARC. Se uno dei due è s (strict), la corrispondenza deve essere esatta, quindi una firma da mail.yourdomain.com non si allinea con un From yourdomain.com. Firma con il dominio From esatto oppure rimuovi il tag strict.
4. Fallisce solo per alcune sorgenti o solo presso alcuni riceventi. Sospetta un inoltro, una mailing list o un gateway di sicurezza che riscrive la posta. Vedi la sezione sull'inoltro più sotto.
5. Fallisce solo su un sottodominio. Verifica se il sottodominio ha propri SPF e DKIM e quale record DMARC vale per esso. Vedi la sezione sui sottodomini.
6. Non passa proprio nulla. Non è un problema di allineamento. SPF o DKIM mancano o sono rotti per quella sorgente, un problema diverso e più semplice.

Relaxed contro strict, in pratica#

Il valore predefinito è relaxed per entrambi. Con l'allineamento relaxed i due domini devono solo condividere un Organizational Domain, quindi un Return-Path bounce.yourdomain.com si allinea con un From news.yourdomain.com. Con strict devono essere identici.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Lascia entrambi a r a meno che tu non abbia un motivo scritto. La modalità strict raramente ferma un vero attacco che la modalità relaxed permetterebbe, ed è una causa frequente di posta legittima dei sottodomini che fallisce. Un dettaglio è cambiato nello standard attuale: l'RFC 9989 (maggio 2026) rende obsoleta l'RFC 7489 e definisce l'Organizational Domain tramite una visita dell'albero DNS invece che con una public suffix list. Se usi domini insoliti con più etichette, verifica come lo applicano i tuoi riceventi.

Perché l'inoltro rompe un controllo ma non l'altro#

Quando un messaggio viene inoltrato, il server che lo inoltra lo invia a sua volta dal proprio IP. SPF viene valutato sull'IP che si connette, quindi SPF fallisce o non è più allineato. Per questo una sorgente può mostrare un DMARC sano presso un ricevente e errori presso un altro: gli errori sono le copie inoltrate.

DKIM di solito sopravvive all'inoltro, perché la firma viaggia dentro il messaggio. Si rompe quando il server che inoltra o una mailing list cambia ciò che era firmato, per esempio aggiungendo un piè di pagina o modificando l'oggetto. Per questo il consiglio è sempre lo stesso: allinea DKIM per ogni sorgente, così DMARC può passare anche quando SPF non può.

Non puoi risolvere del tutto l'inoltro dal tuo lato. Piccoli errori residui riconducibili a server di inoltro e liste sono normali, e questo è uno dei motivi per giudicare i progressi in base all'andamento e alla sorgente, non a una singola giornata storta.

Disallineamenti sui sottodomini#

Un sottodominio non eredita il record SPF del dominio padre, e le chiavi DKIM vengono cercate sotto ogni selector e dominio, quindi un sottodominio che invia posta ha bisogno di una propria autenticazione. La policy DMARC è diversa: se il sottodominio non pubblica un proprio record DMARC, i riceventi trovano quello del dominio padre, e il tag sp= del padre (se presente) stabilisce la policy del sottodominio.

Due controlli risolvono la maggior parte dei problemi dei sottodomini. Primo, verifica che il servizio di invio firmi con un dominio che corrisponde al sottodominio From, o al dominio padre in modalità relaxed. Secondo, se hai impostato sp=reject sul dominio padre, verifica che ogni sottodominio di invio passi prima di affidarti a quella impostazione. La guida al sottodominio di invio spiega come strutturare tutto in modo che ogni flusso di posta resti isolato.

Trovare in fretta la sorgente che fallisce#

La parte costosa di un errore di allineamento non è la soluzione, è capire quale sorgente ne ha bisogno. I tuoi report raggruppano la posta per IP di invio, quindi una sorgente che firma con il proprio dominio compare come una riga con una bassa percentuale DMARC.

I report DMARC di Qualisend mostrano ogni sorgente con percentuali separate di DMARC, DKIM e SPF e segnalano le righe sotto il 100%. Una sorgente che firma e fa rimbalzare la posta tramite i domini del fornitore mostra insieme percentuali basse di DMARC, DKIM e SPF, ed è lo schema del passaggio 1 o 2 sopra. La pagina non mostra il dominio d= né il Return-Path di ogni riga, quindi devi comunque prendere un messaggio di quella sorgente e leggerne gli header per capire quale dei due domini è sbagliato. Inoltre riporta solo ciò che i riceventi restituiscono, quindi un ricevente che non invia report aggregati è invisibile.

Per un primo sguardo senza account, l' analizzatore di report DMARC gratuito legge un file di report nel tuo browser. Per provare un mittente da capo a fondo, invia un messaggio al test di deliverability email gratuito e leggi i suoi risultati di autenticazione.

Una checklist per servizio#

Ogni servizio di invio usa parole proprie per le impostazioni, ma il lavoro è sempre in quattro punti. Controlla ciascuno nella documentazione del servizio invece di fidarti di un promemoria, perché menu e impostazioni predefinite cambiano.

• Dominio DKIM personalizzato. Cerca "autentica il tuo dominio", "dominio di invio brandizzato" o "DKIM". Pubblica le chiavi che ti fornisce. Il nome di un nuovo selector non è in conflitto con quelli esistenti.
• Dominio return-path personalizzato. Cerca "dominio bounce personalizzato", "return-path" o "link branding". Spesso è un'impostazione separata da DKIM.
• Indirizzo From. Verifica che il From usi il tuo dominio. Un From su un dominio di posta gratuito, inviato tramite terzi, non può allinearsi con nulla di tuo.
• Una modifica alla volta. Fai la modifica, invia un test, leggi l'header, poi controlla il report successivo. Più modifiche insieme rendono impossibile capire quale ha funzionato.

Quando fermarsi e quando preoccuparsi#

Sei pronto a pensare all'applicazione della policy quando ogni sorgente legittima supera DMARC con almeno un controllo allineato, e gli errori rimasti appartengono a server di inoltro o a posta che non riconosci. Se stai ancora cercando di arrivarci, la guida alla configurazione di DMARC contiene l'ordine di rollout, e la guida ai requisiti dei mittenti spiega perché oggi DMARC allineato conta per la posta massiva.

L'allineamento dice ai riceventi che la posta è davvero tua, ma non dice nulla sulla lista che c'è dietro. Quando tutte le tue sorgenti passano, controlla qualche indirizzo con il verificatore email gratuito, che testa sintassi, record MX ed errori di battitura un indirizzo alla volta. Per un'intera lista, il piano gratuito nella pagina dei prezzi ti dà 100 crediti che eseguono la verifica completa, perché un dominio perfettamente allineato ha comunque bisogno di una lista sana per meritarsi la inbox.