Defaults.Exposed › Correzioni › Guides

Le email inoltrate falliscono SPF — perché non può risolverlo e cosa funziona davvero (2026)

Pubblicato 2026-07-08

Dati aggiornati al 2026-06-29 · metodologia v7. Dati censuari aggregati su 261 milioni di domini valutati. Veda come assegniamo i voti.

Non può far superare SPF alle email inoltrate: l’inoltro rompe SPF per costruzione, e la soluzione onesta è un DKIM allineato, che all’inoltro sopravvive. La scala del fenomeno è censuaria: 7.355.985 dei 138.927.207 domini che pubblicano SPF autorizzano il solo include di inoltro di Namecheap, con una quota di SPF strict del <0.1%, secondo il censimento Defaults.Exposed su 261 milioni di domini.

Qui sotto: perché nessun record SPF che Lei possa scrivere sopravvive all’inoltro, perché SRS e ARC non sono strumenti sotto il Suo controllo, e la soluzione che regge — la firma DKIM con il Suo dominio come pass DMARC — più l’unico caso che rompe anche DKIM (le mailing list che riscrivono i messaggi) e cosa fare con quel residuo.

Perché l’inoltro rompe SPF?

I sistemi riceventi valutano SPF rispetto al dominio del Return-Path (RFC5321.MailFrom), non all’header From. Quando invia direttamente, l’IP del Suo server è nel Suo record SPF e il controllo passa. Quando il Suo destinatario inoltra automaticamente il messaggio — verso un Gmail personale, tramite un alias universitario, con il prodotto di inoltro di un registrar — è il server dell’inoltratore a ritrasmetterlo, di norma mantenendo il Suo dominio sul Return-Path. Il ricevente finale ora si chiede: questo server di inoltro è autorizzato nel Suo record SPF?

Non lo è, e non lo sarà mai: non ha scelto Lei l’inoltratore, non sa nemmeno che esiste, e lo stesso messaggio inoltrato domani da un servizio diverso fallirebbe da un IP diverso. SPF risponde a una sola domanda — “questo IP proviene da un server autorizzato dal dominio del Return-Path?” — e per la posta inoltrata la risposta vera è no. Il fallimento è SPF che funziona come da specifica, non un errore nel Suo record.

Il censimento mostra quanto sia diffuso questo percorso: 7.355.985 domini autorizzano l’include di inoltro email di Namecheap (spf.efwd.registrar-servers.com) — il prodotto di inoltro di un singolo provider, sui 139 milioni di publisher SPF — con una quota di SPF strict del <0.1% e solo il 0,2% che applica DMARC in modo vincolante. Quel modello “morbido” non è trascuratezza: l’inoltro è esattamente il caso in cui un -all rigido fa cilecca, e il provider il cui prodotto è l’inoltro configura di conseguenza. La storia completa dei qualificatori è nel nostro report ~all vs -all, e il quadro provider per provider in quale provider email offre l’SPF più solido.

Non posso semplicemente aggiungere il server dell’inoltratore al mio record SPF?

No — e il perché è l’intero articolo:

1. Non può enumerare gli inoltratori. Qualunque destinatario, ovunque, può inoltrare la Sua posta tramite qualunque servizio. Il Suo record SPF dovrebbe elencare server che non può conoscere in anticipo.
2. Elencarli vanificherebbe lo scopo. I grandi servizi di inoltro veicolano posta per milioni di clienti. Metta i loro intervalli di IP nel Suo record e ogni messaggio che un loro utente qualsiasi inoltra — compreso quello di uno spoofer — supera SPF a Suo nome.

La stessa logica esclude di ammorbidire il qualificatore per “far funzionare l’inoltro”: il qualificatore non è il motivo per cui la posta inoltrata fallisce, e una volta che DMARC è in gioco cambia meno di quanto molte guide sostengano — veda i dati sui qualificatori. Il record non è la leva giusta. Smetta di tirarla.

E SRS e ARC? Non risolvono l’inoltro?

Lo affrontano — ma nessuno dei due è nelle Sue mani:

Dati e stato dei meccanismi aggiornati al 2026-06-29.

SRS fa sparire il problema SPF dell’inoltratore, non il Suo: riscrivere il Return-Path cambia di chi viene verificato l’SPF, mentre il Suo header From — il dominio che DMARC difende — resta intatto. ARC è una decisione di fiducia tra operatori di infrastruttura. Se una guida Le dice di “implementare SRS” come titolare del dominio, La ha scambiata per il provider di inoltro.

Come faccio a far sopravvivere le mie email all’inoltro?

Faccia di DKIM, allineato al Suo dominio, il Suo pass DMARC. Una firma DKIM è crittografia trasportata negli header del messaggio: si verifica ovunque il messaggio finisca, per quanti server lo abbiano ritrasmesso, purché il contenuto firmato non sia stato modificato. A DMARC basta un solo pass allineato — SPF o DKIM — quindi quando l’inoltro uccide la gamba SPF, il DKIM allineato tiene il messaggio autenticato.

1. Esegua la scansione gratuita su defaults.exposed prima di toccare il DNS. Mostra se ha DKIM, se la firma usa il Suo dominio e a che punto si trova il Suo DMARC — così ripara il vero divario invece di combattere con il record SPF.
2. Confermi che il problema sia davvero l’inoltro. Nell’header Authentication-Results di un messaggio coinvolto, la posta diretta supera SPF mentre la copia inoltrata fallisce dall’IP del servizio di inoltro. Se SPF e DKIM passano ma DMARC fallisce comunque, ha invece un problema di allineamento — veda DMARC fallisce ma SPF e DKIM passano.
3. Attivi la firma DKIM con il Suo dominio presso ogni servizio di invio — prima il provider delle caselle, poi gli ESP e i mittenti transazionali. Le impostazioni predefinite dei provider spesso firmano con il dominio del provider, che non si allinea; Lei vuole d=yourdomain. Parta da come sistemare DKIM, con i percorsi passo-passo per Google Workspace e Microsoft 365.
4. Verifichi l’allineamento, non solo il pass. Il dominio d= nella firma deve corrispondere al Suo dominio From; un dkim=pass sul dominio di qualcun altro non fa nulla per il Suo DMARC.
5. Lasci in pace il Suo record SPF. Lo mantenga accurato per la Sua posta diretta — autentica ancora la maggior parte del Suo traffico e resta la Sua seconda gamba DMARC. Smetta solo di cercare di fargli coprire gli inoltratori.
6. Riesegua la scansione, poi applichi DMARC per gradi e in modo deliberato — sezione seguente, e la guida al passaggio da p=none a p=reject.

Questa combinazione — SPF più un DMARC vincolante che poggia su DKIM allineato — è lo schema a prova di inoltro, ed è rara: dei 77,5 milioni di domini che pubblicano ~all, solo il 9,2% (7.116.774) lo accompagna con una policy DMARC vincolante, e appena il 3,87% dei 261 milioni di domini valutati (10.092.481) completa l’intera triade SPF + DKIM + DMARC applicato, secondo il censimento (2026-06-29).

E le mailing list che riscrivono i messaggi?

L’unico percorso di inoltro a cui il DKIM allineato non sopravvive: le mailing list che modificano il messaggio — un tag [list-name] nell’oggetto, un piè di pagina di disiscrizione, un allegato rimosso. Cambi il contenuto firmato e l’hash del corpo non corrisponde più, quindi fallisce anche DKIM (dkim=fail: body hash did not verify è la guida dedicata a quel fallimento). Ora entrambe le gambe DMARC sono morte, e solo la lista può mitigarlo (riscrittura del From, sigillo ARC).

Questo residuo è esattamente ciò per cui esiste l’applicazione DMARC per fasi. Passare per p=quarantine con una rampa pct, osservando i report aggregati, mostra quanta della Sua posta reale attraversa liste che riscrivono i messaggi prima che una policy p=reject inizi a respingerla. Non salti a reject su un dominio i cui utenti vivono di mailing list; ma non ristagni nemmeno per sempre su p=none. La guida al rollout per fasi accompagna la rampa.

Domande frequenti

L’inoltro rompe anche DKIM? L’inoltro semplice, no: la firma viaggia con il messaggio e si verifica presso il ricevente finale. DKIM si rompe solo quando il contenuto firmato viene modificato in transito — i tag nell’oggetto e i piè di pagina delle mailing list sono il caso classico — ed è per questo che il residuo delle liste si gestisce con la progressione della policy DMARC, non con qualcosa nel DNS.

Devo passare da -all a ~all perché l’inoltro smetta di fallire? Cambiare il qualificatore non farà passare gli inoltratori: non è quello il motivo per cui falliscono. È significativo che l’include di inoltro di Namecheap, 7.355.985 domini e la più grande popolazione censuaria dedicata all’inoltro (2026-06-29), abbia una quota di SPF strict del <0.1%: l’SPF morbido è probabilmente il modello corretto per un prodotto di inoltro. Veda il report ~all vs -all per ciò che il qualificatore cambia davvero.

Perché la mia posta supera SPF quando la invio direttamente ma fallisce quando qualcuno la inoltra? Il ricevente verifica se l’IP dell’ultimo server trasmittente è autorizzato dal record SPF del Suo dominio Return-Path. Diretta: il Suo server, nel Suo record, pass. Inoltrata: il server dell’inoltratore, non nel Suo record, fail. Il Suo record non è cambiato — è cambiato l’IP trasmittente.

Posso configurare SRS per risolvere? Solo se l’inoltratore è Lei. SRS gira sul server che effettua l’inoltro, e anche dove gira, il pass SPF risultante appartiene al dominio dell’inoltratore e non si allinea con il Suo From — il Suo DMARC ha comunque bisogno della gamba DKIM.

SPF è inutile se tanto l’inoltro lo rompe? No. La maggior parte della posta viene consegnata direttamente, dove SPF funziona esattamente come previsto, e resta una delle Sue due gambe DMARC. Dei 261.086.232 domini nel censimento (2026-06-29), 138.927.207 pubblicano SPF — mantenga il Suo accurato tramite la pagina di correzione SPF, e lasci che DKIM porti la parte inoltrata.

Invii il report al titolare

Se sta sistemando tutto questo per un cliente o per il Suo datore di lavoro, chiuda il cerchio con delle prove. Una volta attivo il DKIM con dominio personalizzato e avviato DMARC per fasi, riesegua la scansione gratuita e inoltri il report con il voto al titolare dell’azienda: datato, in linguaggio semplice, a dimostrazione che il dominio resta autenticato anche quando la sua posta viene inoltrata. È il documento per il rinnovo della polizza cyber e per il prossimo questionario dei fornitori — un prima-e-dopo documentato, non “ho attivato qualcosa”.

Controlli il Suo dominio → · DMARC fallisce ma SPF e DKIM passano → · Sistemare DKIM → · Come assegniamo i voti → · Solo dati aggregati. Dati conservati ed elaborati nell’UE.