DMARC fallisce anche se SPF e DKIM passano

In breve

• DMARC passa solo se SPF o DKIM passano per il dominio del tuo indirizzo From. Un pass per il dominio del tuo provider non conta.
• Apri in Gmail un messaggio inviato con Show original (Mostra originale) e confronta smtp.mailfrom, header.i e header.from nell’intestazione Authentication-Results.
• Sistema prima DKIM: attiva la firma con il tuo dominio in ogni servizio che invia per te. Una firma DKIM sopravvive all’inoltro, SPF no.
• Per impostazione predefinita un sottodominio è abbastanza vicino. Se il tuo record DMARC contiene adkim=s o aspf=s, non lo è.
• Il riscaldamento non ripara l’allineamento. Le email di riscaldamento partono dalla tua casella e falliscono insieme a lei.

DMARC non chiede se SPF e DKIM sono passati. Chiede se uno dei due è passato per il dominio del tuo indirizzo From. Se SPF è passato per il dominio di bounce del tuo provider e DKIM per il dominio di firma del tuo provider, entrambe le righe dicono «pass» e DMARC dice comunque «fail». La soluzione sta dal lato di chi invia: fai firmare con il tuo dominio oppure usa un indirizzo di bounce sul tuo dominio. Basta una delle due cose.

Questa corrispondenza si chiama allineamento. È la parte di DMARC che un controllo del DNS non può vedere. Se la tua posta è allineata lo si vede solo in un messaggio inviato davvero. Questa pagina mostra come leggerne uno.

Con ogni email viaggiano tre domini

Un’email porta il tuo dominio in un massimo di tre punti. Ogni controllo ne guarda uno diverso.

SPF (RFC 7208) e DKIM (RFC 6376) rispondono ciascuno a una domanda ristretta, e nessuna delle due domande riguarda la tua riga From. Un servizio di newsletter può superare SPF per il proprio dominio di bounce e firmare con la propria chiave, e il messaggio può comunque dichiarare di provenire da te. DMARC chiude questa falla. RFC 9989, lo standard DMARC da maggio 2026, accetta un risultato solo se il dominio a cui si riferisce corrisponde al dominio From, e per DKIM ne spiega il motivo in una frase:

DMARC richiede che l’allineamento dell’identificatore sia applicato all’identificatore autenticato da DKIM, perché un messaggio può portare una firma valida di qualsiasi dominio, anche di uno usato da un malintenzionato.

Lo stesso vale per SPF, dato che chiunque può pubblicare un record SPF per un dominio di sua proprietà. La regola è quindi: DMARC passa se SPF passa e il suo dominio è allineato, oppure se DKIM passa e il suo dominio è allineato.

Trova la mancata corrispondenza in un messaggio reale

Ti servono un’email inviata come viene inviata la tua posta vera e un indirizzo Gmail per riceverla.

1. Invia un messaggio dalla casella o dallo strumento in questione a un indirizzo Gmail che puoi aprire.
2. Aprilo in Gmail da un computer. Accanto a Reply (Rispondi) fai clic su More (Altro) e poi su Show original (Mostra originale). Google descrive gli stessi passaggi in Tracciare un’email tramite l’intestazione completa.
3. Trova l’intestazione Authentication-Results, in cui il server ricevente annota l’esito dei suoi controlli (RFC 8601). Confronta tre valori: il dominio dopo smtp.mailfrom=, il dominio dopo header.i=@ (alcuni server scrivono header.d=) e il dominio dopo header.from=. Come leggere le intestazioni di un’email spiega quella riga passo per passo.

Questo è lo schema di un messaggio che supera SPF e DKIM e fallisce DMARC. L’intestazione è abbreviata e usa domini di esempio:

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

Leggilo dal basso. Il dominio From è example.com. SPF è passato, ma per send.vendor-mail.example. DKIM è passato, ma la firma appartiene a vendor-mail.example. Nessuno dei due è example.com, quindi niente garantisce per il nome nella riga From.

Dopo che il servizio è stato configurato per firmare con il tuo dominio, lo stesso messaggio si presenta così:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF punta ancora al fornitore. Va bene così. Ora DKIM corrisponde, e a DMARC basta un solo pass allineato.

Quanto vicino è abbastanza: allineamento relaxed e strict

I due domini non devono essere identici. Per impostazione predefinita l’allineamento è flessibile (relaxed): basta che entrambi appartengano allo stesso dominio registrato, che lo standard chiama dominio organizzativo. L’allineamento rigoroso (strict) richiede una corrispondenza esatta. Scegli con i tag adkim per DKIM e aspf per SPF nel tuo record DMARC.

Lo standard osserva che «quasi tutti i proprietari di dominio hanno trovato l’allineamento flessibile sufficiente per le proprie esigenze». Controlla comunque il tuo record. Il record di esempio in cima alla pagina Configurare DMARC di Google termina con adkim=s; aspf=s, quindi un record copiato da lì è rigoroso. Se il tuo ha quei due tag e uno strumento invia da un sottodominio, rimuovili. Google stesso avverte in quella pagina che l’allineamento rigoroso «può far sì che i messaggi provenienti dai sottodomini associati vengano rifiutati o inviati nello spam».

Da dove nasce di solito la mancata corrispondenza

Un servizio che invia dai propri server

Piattaforme di newsletter, CRM, strumenti di fatturazione e help desk inviano la tua posta dalla loro infrastruttura. Finché non colleghi il tuo dominio, di norma usano un indirizzo di bounce sul loro dominio e firmano con la propria chiave. La documentazione di Amazon dice chiaramente perché qui l’allineamento SPF è raro: il Return-Path «è usato per i mancati recapiti e le segnalazioni, che il provider (SES) traccia tramite un indirizzo di sua proprietà» (Amazon SES). L’impostazione che risolve il problema ha un nome diverso in ogni servizio e si conclude con qualche record DNS dalla tua parte.

Sono le descrizioni dei fornitori stessi, aggiornate a ottobre 2026. Altri servizi funzionano in modo analogo. Cerca nella loro guida «authenticate domain», «custom DKIM» o «branded sending domain».

Il tuo provider di posta firma con il proprio dominio, o non firma affatto

Con una casella sul tuo dominio, il Return-Path è normalmente il tuo stesso indirizzo, quindi SPF è allineato non appena il tuo record SPF include il provider. Te lo dice il valore dopo smtp.mailfrom=. DKIM è la parte che richiede un’attivazione.

• Google Workspace. Finché non attivi DKIM per il tuo dominio, Google ha finora firmato con uno dei propri domini. Una versione precedente della pagina di aiuto di Google diceva che in quel caso Gmail firma «con questa chiave di dominio DKIM predefinita: d=*.gappssmtp.com». La pagina attuale non nomina più il dominio, quindi controlla la tua intestazione: un header.i che termina con gappssmtp.com significa che la tua chiave non è attiva. Generala nella Console di amministrazione in Apps, Google Workspace, Gmail, Authenticate email (Autentica email), aggiungi il record TXT che ti viene mostrato, poi fai clic su Start authentication (Avvia autenticazione) (Configurare DKIM).
• Microsoft 365. La documentazione di Microsoft, aggiornata ad agosto 2026, afferma: «Attualmente non viene applicata alcuna firma DKIM alla posta in uscita dai domini personalizzati». Pubblichi due record CNAME e abiliti la firma nel portale di Defender (Come usare DKIM per la posta del tuo dominio personalizzato).

Il record che aggiungi per una chiave DKIM si trova sempre sotto _domainkey, con un nome scelto dal provider. Per Google Workspace ha questo aspetto, con la chiave abbreviata:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Uno strumento che si collega alla tua casella e invia attraverso di essa non aggiunge una propria firma. La posta di uno strumento del genere è identica a quella che scrivi a mano, quindi la soluzione sta presso il provider di posta e non nello strumento.

Il messaggio è stato inoltrato

Quando un destinatario inoltra automaticamente la tua email, questa arriva da un server che il tuo record SPF non elenca. SPF fallisce, oppure passa per il dominio di chi inoltra. Una firma DKIM sopravvive al viaggio finché nessuno modifica il messaggio. Le mailing list che aggiungono un piè di pagina o un’etichetta nell’oggetto rompono anche la firma. Non puoi rimediare dalla tua parte. Le FAQ per i mittenti di Google dicono che per Gmail «l’allineamento DMARC non è richiesto per i messaggi inoltrati o delle mailing list». È il motivo per avere DKIM allineato e non affidarsi solo a SPF.

Non è posta tua

Se i tuoi report DMARC mostrano fallimenti da server che non hai mai usato, forse qualcuno sta inviando con il tuo indirizzo. Quei messaggi devono fallire. Non c’è niente da sistemare, e sono l’argomento a favore di una policy più severa in futuro.

Sistema prima DKIM, poi SPF

Con l’uno o con l’altro ottieni un pass. DKIM è quello che conviene avere, perché viaggia con il messaggio. Le best practice di M3AAWG ne fanno una regola: «Firma tutta la posta in uscita con una chiave DKIM allineata al dominio dell’intestazione RFC5322.From». RFC 9989 raccomanda di usarli entrambi.

1. Elenca tutto ciò che invia a nome del tuo dominio. Le caselle, lo strumento di newsletter, il CRM, le fatture, il modulo di contatto del tuo sito. I report DMARC ti indicano quelli che hai dimenticato.
2. Prova ciascuno con il controllo dell’intestazione descritto sopra e annota quale dei due domini non è tuo.
3. Attiva la firma con il tuo dominio ovunque header.i mostri un altro nome e pubblica i record che il servizio ti fornisce. Scegli una chiave a 2048 bit se il provider del tuo DNS la accetta. Gmail richiede almeno 1024 bit e ne raccomanda 2048.
4. Imposta un dominio di bounce personalizzato dove il servizio lo offre, su un sottodominio come bounce.example.com. Così si allinea anche SPF.
5. Invia di nuovo la prova e cerca dmarc=pass. Le modifiche al DNS possono richiedere un po’ di tempo. Google indica fino a 48 ore perché una nuova chiave DKIM inizi a funzionare.

Non funziona, invece, aggiungere il fornitore ai tuoi record. Un include: per il fornitore nel tuo record SPF non cambia nulla se il Return-Path è sul dominio del fornitore, perché SPF consulta il record di quel dominio e non il tuo. Nemmeno un record DMARC può elencare terze parti fidate. Lo standard dice che per questo non esiste «alcun meccanismo generalmente accettato».

Se l’intestazione mostra dmarc=pass e il messaggio finisce comunque nello spam, la causa non è più l’autenticazione. SPF, DKIM e DMARC superati, ma l’email finisce comunque nello spam riprende da lì.

Quanto costa un DMARC che fallisce finché la tua policy è p=none

Con p=none chiedi ai server riceventi di non intervenire in caso di fallimento, quindi nulla viene rifiutato a causa della tua policy. Conta comunque a tuo sfavore in due modi.

• Regole per i grandi mittenti. Gmail, Yahoo e Outlook.com richiedono posta allineata ai grandi mittenti, il che per Gmail e Outlook.com significa da 5.000 messaggi al giorno. Le FAQ per i mittenti di Google riportano l’errore temporaneo 4.7.32 per la posta la cui intestazione From «non è allineata né con il dominio organizzativo SPF autenticato né con quello DKIM», e indicano come conseguenza «codici di errore temporaneo o permanente, oppure lo spostamento nella cartella spam».
• Blocca il passo successivo. Appena passi a p=quarantine o p=reject, ogni tuo messaggio non allineato va trattato come spam o rifiutato. In Gmail il messaggio di mancato recapito recita «Unauthenticated email from domain-name is not accepted due to domain's DMARC policy», errore 5.7.26 (Risolvere i problemi di DMARC).

Se non hai alcun record DMARC, parti dal record da aggiungere. Attiva anche i report che mostrano l’allineamento di tutti i tuoi mittenti in una volta.

Cosa può e cosa non può fare qui il riscaldamento

Un riscaldamento non ripara l’allineamento. WarmupBay si collega alla tua casella e invia da lì, quindi le sue email di riscaldamento vengono inviate e firmate dal tuo provider esattamente come la posta che scrivi tu. Se la tua casella fallisce DMARC, falliscono con lei. Prima sistema i record.

WarmupBay aiuta nella parte che viene prima e in quella che viene dopo. Quando colleghi una casella, controlla SPF, DKIM e DMARC del dominio e ferma il riscaldamento se dopo 72 ore mancano ancora. Quando sono a posto, la tua casella scambia qualche email al giorno con altre caselle di una rete condivisa, e la dashboard mostra dove sono arrivate: posta in arrivo, una scheda Gmail o spam, separatamente per Google e per gli altri provider. Non verifica la posta del tuo strumento di newsletter o del CRM, perché quella non passa mai dalla tua casella, e non può ancora collegare caselle Microsoft 365 o Outlook.com. È gratuito per 10 email di riscaldamento al giorno. Collega la tua casella quando l’intestazione mostra dmarc=pass.

Domande frequenti

SPF passa ed è allineato, DKIM non è allineato. Basta così?

Per DMARC sì. Basta un solo pass allineato. Non basta più quando un destinatario inoltra la tua email, perché a quel punto SPF non corrisponde più. Google scrive inoltre nelle sue FAQ per i mittenti che l’allineamento sia con SPF sia con DKIM diventerà probabilmente un requisito, quindi configura comunque DKIM per il tuo dominio.

Perché DMARC fallisce per alcuni destinatari e passa per altri?

Perché la posta arriva loro per strade diverse o da mittenti diversi. Un destinatario che inoltra a un’altra casella, o una mailing list, cambia ciò che vedono SPF e a volte DKIM. Può anche trattarsi di uno dei tuoi servizi di invio non ancora configurato. I report aggregati elencano i risultati per server di invio e mostrano di quale caso si tratta.

L’indirizzo Reply-To ha un ruolo in DMARC?

No. DMARC usa solo il dominio dell’intestazione From. L’indirizzo Reply-To, il nome visualizzato e l’intestazione Sender non fanno parte del controllo.

Come vedo i problemi di allineamento senza aprire le intestazioni?

Nei report aggregati DMARC. Ogni record ha un blocco policy_evaluated con un risultato dkim e uno spf, che sono i risultati dopo il test di allineamento. Il blocco auth_results subito sotto mostra i risultati grezzi e i domini a cui si riferivano. Un pass grezzo accanto a un fail valutato è esattamente il caso di questa pagina. Ricevi i report aggiungendo un indirizzo rua al tuo record DMARC.

L’intestazione dice dkim=fail o dkim=neutral. È lo stesso problema?

No. In quel caso è la firma stessa a non aver superato la verifica, ed è un guasto diverso. Se il testo riporta body hash did not verify, la pagina di risoluzione dei problemi di Google ne indica la causa: il messaggio è stato modificato dopo la firma, per esempio da un gateway che aggiunge un piè di pagina. L’allineamento riguarda una firma valida che però appartiene a un altro dominio.

Mi serve una chiave DKIM separata per ogni servizio che invia per me?

In pratica sì. Ogni servizio firma con la propria chiave e la pubblica con il proprio nome di selettore sotto _domainkey nel tuo dominio, quindi più chiavi convivono senza conflitti. È diverso da SPF, dove un dominio può avere un solo record.

Fonti

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. RFC 7208: Sender Policy Framework (SPF)
4. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
5. RFC 8601: Message Header Field for Indicating Message Authentication Status
6. Email sender guidelines – Gmail Help
7. Email sender guidelines FAQ – Gmail Help
8. Set up DMARC – Google Workspace Help
9. Set up DKIM – Google Workspace Help
10. Troubleshoot DMARC issues – Google Workspace Help
11. Troubleshoot DKIM issues – Google Workspace Help
12. Trace an email with its full header – Gmail Help
13. Check if your Gmail message is authenticated – Gmail Help
14. Set up DKIM to prevent email spoofing – Google Workspace Admin Help, archived version of 30 June 2021
15. How to use DKIM for email in your custom domain – Microsoft Learn
16. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
17. Sender Best Practices – Yahoo Sender Hub
18. Configure domain authentication – Twilio SendGrid Docs
19. Complying with DMARC authentication protocol in Amazon SES – AWS Documentation
20. Using a custom MAIL FROM domain – Amazon SES, AWS Documentation
21. About Email Domain Authentication – Mailchimp Help
22. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)