Defaults.Exposed › Correzioni › Guides
DMARC fallisce ma SPF e DKIM passano? La correzione dell'allineamento (2026)
Pubblicato 2026-07-08
Dati aggiornati al 2026-06-29 · metodologia v7. Dati aggregati del censimento su 261 milioni di domini valutati. Veda come assegniamo i voti.
A DMARC non basta un pass — il dominio che ha passato SPF o DKIM deve corrispondere al Suo dominio From. La maggior parte della posta “SPF pass, DMARC fail” ha passato SPF sul dominio di bounce del fornitore, non sul Suo. Solo il 7,4% di 261.086.232 domini valutati passa SPF con allineamento sotto una policy DMARC applicata, secondo il censimento Defaults.Exposed (2026-06-29).
La correzione è più rapida di quanto la confusione lasci pensare. Legga l’intestazione Authentication-Results per vedere quale gamba — SPF o DKIM — sta passando sul dominio sbagliato; poi attivi la firma DKIM con dominio personalizzato del Suo servizio di invio (di solito pochi CNAME, ed è la correzione che sopravvive all’inoltro), oppure ne imposti il return-path personalizzato in modo che SPF passi sul Suo dominio. A DMARC basta una sola gamba allineata.
Come può DMARC fallire quando SPF e DKIM passano entrambi?
Perché DMARC non chiede mai “SPF è passato?” Chiede: SPF o DKIM sono passati per un dominio che corrisponde all’indirizzo From che il destinatario vede? Quella condizione aggiuntiva si chiama allineamento, ed è l’intero scopo di DMARC — senza di essa, chiunque potrebbe passare SPF su un dominio di sua proprietà mostrando il Suo nell’intestazione From.
Ogni controllo autentica un dominio diverso:
| Controllo | Dominio che valuta davvero | Dove vederlo |
|---|---|---|
| SPF | Il Return-Path (RFC5321.MailFrom, l’indirizzo di bounce/envelope-from) — non l’intestazione From | smtp.mailfrom= in Authentication-Results |
| DKIM | Il dominio nel tag d= della firma — quello scelto dal firmatario | header.d= in Authentication-Results |
| DMARC | Il Suo dominio nell’intestazione From — e richiede che il dominio di SPF o il d= di DKIM vi corrispondano | header.from= in Authentication-Results |
Ecco come i pezzi di solito vanno storti: la Sua piattaforma di newsletter o il Suo CRM invia con un Return-Path come [email protected], SPF viene verificato su vendor.com e passa, DKIM passa con d=vendor.com — e DMARC fallisce, perché nessuno dei due domini che passano corrisponde a yourcompany.com. Ogni controllo ha detto la verità; nessuno ha autenticato Lei. Modificare il Suo record SPF non può risolverlo — non è mai stato consultato. È la stessa trappola trattata in SPF che fallisce per i Suoi strumenti SaaS.
Il censimento mostra quanto pochi mittenti completino quest’ultimo passo: 27.640.987 di 261.086.232 domini valutati (il 10,59%) ha una policy DMARC applicata, e solo il 7,4% passa SPF con allineamento sotto una di esse. Tra i 77,5 milioni di domini il cui SPF termina in softfail (~all), appena il 9,2% sta sotto una policy DMARC applicata; tra chi pubblica hardfail (-all), 12.142.351 sono con applicazione mentre 42.514.532 non lo sono. La maggior parte dei domini si ferma a “SPF passa” — il che, senza un DMARC che agisca di conseguenza, non protegge quasi nulla.
Come leggo Authentication-Results per vedere quale gamba non è allineata?
Si invii un messaggio tramite il servizio che fallisce, apra il sorgente raw e trovi l’intestazione Authentication-Results. Un tipico risultato non allineato appare così:
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=bounces.espmail.net;
dkim=pass header.d=espmail.net;
dmarc=fail (p=NONE) header.from=yourcompany.com
Lo legga con tre confronti:
- Gamba SPF:
smtp.mailfrom=termina con il Suo dominio? Qui èbounces.espmail.net— non allineato. - Gamba DKIM:
header.d=termina con il Suo dominio? Qui èespmail.net— non allineato. - Verdetto DMARC:
header.from=è il dominio che DMARC sta difendendo. Nessuna delle due gambe vi ha corrisposto, quindidmarc=fail— anche se entrambi i controlli individuali diconopass.
La gamba che già coinvolge il Suo dominio (o che può arrivare a farlo) è quella da sistemare. Ne serve solo una.
Qual è la differenza tra allineamento rilassato e rigoroso?
DMARC offre due modalità di corrispondenza, impostate con i tag aspf (SPF) e adkim (DKIM) nel Suo record DMARC:
- Rilassato (
r, il default): i due domini devono condividere lo stesso dominio organizzativo — il dominio registrabile secondo la Public Suffix List.bounce.yourcompany.comsi allinea conyourcompany.com; e così anche und=mail.yourcompany.comDKIM. È per questo che i return-path personalizzati dei fornitori e il DKIM personalizzato, che vivono su sottodomini, funzionano. - Rigoroso (
s): i domini devono corrispondere esattamente, carattere per carattere.bounce.yourcompany.comnon si allinea più conyourcompany.com.
Se il Suo record non menziona aspf o adkim, è in modalità rilassata — e quasi certamente vuole restarci. La modalità rigorosa non aggiunge sicurezza significativa per la maggior parte dei mittenti e rompe silenziosamente ogni mittente legittimo su sottodominio che Lei configuri. Se DMARC fallisce e il Suo record contiene aspf=s o adkim=s, già solo quello può essere il bug.
Come sistemo l’allineamento DMARC?
- Esegua la scansione gratuita su defaults.exposed prima di toccare il DNS. Mostra il Suo record DMARC e la policy, se SPF e DKIM sono configurati per allinearsi e cos’altro è rotto — così sistema per prima la gamba giusta.
- Testi ogni servizio di invio e ne legga l’Authentication-Results (come sopra). Elenchi ogni sorgente — provider di posta, strumento per newsletter, CRM, applicazione di fatturazione — e annoti per ciascuna se
smtp.mailfromeheader.dsono il Suo dominio o quello del fornitore. - Attivi la firma DKIM con dominio personalizzato per ogni fornitore — la correzione che dura. Ogni servizio di invio serio offre l‘“autenticazione del dominio”: pochi record CNAME che gli permettono di firmare come
d=yourcompany.com(o un sottodominio, che in modalità rilassata si allinea). Il DKIM allineato è di solito la correzione più facile e l’unica che sopravvive all’inoltro, perché l’inoltro rompe SPF per costruzione. - Per l’allineamento SPF, attivi il return-path personalizzato del fornitore (spesso chiamato dominio di bounce personalizzato) — tipicamente un CNAME come
bounce.yourcompany.compuntato verso il fornitore. SPF passa allora sul Suo dominio organizzativo e si allinea. Lo faccia dove è offerto, ma lo tratti come la seconda gamba, non come sostituto del DKIM allineato. - Lasci l’allineamento in modalità rilassata salvo che non abbia un motivo specifico e ben compreso per
aspf=s/adkim=s. - Riesegua la scansione, confermi entrambe le gambe, poi proceda verso l’applicazione. Una policy DMARC a
p=noneriferisce ma non blocca nulla; una volta che i Suoi mittenti reali si allineano, il percorso completo verso una policy che La protegge è nella pagina sistemare DMARC, e le guide per provider come DMARC su IONOS coprono i clic nel pannello DNS.
Devo sistemare l’allineamento SPF o quello DKIM?
Serve una gamba allineata per ogni sorgente di invio. Se può farne una sola, la scelta non è in bilico:
| Correzione | Cosa comporta | Sopravvive all’inoltro? |
|---|---|---|
| DKIM allineato (firma con dominio personalizzato) | Pochi CNAME nel pannello di “autenticazione del dominio” del fornitore | Sì — la firma viaggia con il messaggio |
| SPF allineato (return-path/dominio di bounce personalizzato) | Un CNAME, dove il fornitore lo offre | No — l’IP di qualsiasi inoltrante sostituisce quello del fornitore |
Il caso particolare che vale la pena conoscere: Google Workspace e Microsoft 365 firmano la Sua posta con DKIM per impostazione predefinita con i propri domini di riserva (gappssmtp.com, onmicrosoft.com) — così DKIM mostra pass mentre DMARC continua a fallire. È il singolo caso specifico più comune di tutto questo problema, e ha una guida dedicata: DKIM passa ma DMARC fallisce comunque: la trappola della firma predefinita.
Domande frequenti
Perché DMARC passi devono allinearsi sia SPF sia DKIM? No — basta un solo pass allineato. La buona pratica è comunque allinearli entrambi, così quando l’inoltro rompe la gamba SPF, la gamba DKIM porta comunque il pass DMARC. Di 261.086.232 domini valutati nel censimento del 2026-06-29, solo il 3,87% completa la triade SPF + DMARC + DKIM.
La dashboard del mio ESP dice che SPF e DKIM sono “verificati” — perché DMARC fallisce ancora? “Verificato” di solito significa che gli invii del fornitore passano sui domini del fornitore. A meno che Lei non abbia completato i loro passaggi di dominio personalizzato (CNAME DKIM, return-path personalizzato), la posta si autentica come il fornitore, non come Lei — e DMARC confronta con il Suo dominio From.
Un record SPF rigoroso -all basta senza allineamento?
No. Un qualificatore rigoroso rafforza il verdetto di SPF sul dominio del Return-Path, ma DMARC richiede comunque che quel dominio sia il Suo. Al censimento del 2026-06-29, solo 12.142.351 dei domini che pubblicano -all stanno sotto una policy DMARC applicata — gli altri 42.514.532 hanno un record rigoroso su cui nessuna policy agisce.
Devo passare all’allineamento rigoroso (aspf=s/adkim=s) per più sicurezza?
Quasi mai. L’allineamento rilassato richiede già lo stesso dominio registrabile, che uno spoofer non controlla. La modalità rigorosa per lo più rompe i Suoi stessi mittenti su sottodominio — la verifichi ogni volta che l’allineamento fallisce inaspettatamente.
DMARC fallisce solo sulla posta che i destinatari inoltrano — stessa correzione? Quella è la gamba SPF che muore in transito: il server dell’inoltrante non è nel record SPF di nessuno per il Suo return-path. Non può sistemare SPF per la posta inoltrata; il DKIM allineato è la risposta, perché la firma sopravvive intatta all’inoltro. Dettagli in l’email inoltrata fallisce SPF.
Invii il report al titolare
Se sta sistemando questo per un cliente o per il Suo datore di lavoro, chiuda il cerchio con le prove. Riesegua la scansione gratuita quando i CNAME sono attivi e inoltri il report con il voto al titolare dell’azienda: datato, in linguaggio semplice, con SPF, DKIM e DMARC allineati e superati. È il documento che gli servirà per il rinnovo della polizza cyber e per il prossimo questionario di sicurezza dei fornitori — la prova di una configurazione funzionante, non solo “ho aggiunto qualche record DNS”.
Verifichi il Suo dominio → · DKIM passa ma DMARC fallisce comunque → · Sistemare DMARC → · Come assegniamo i voti → · Solo dati aggregati. Dati conservati e trattati nell’UE.