Defaults.Exposed › Correzioni › Guides

SPF che fallisce per i suoi strumenti SaaS? Perché succede e in che ordine intervenire — Edizione Europa (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.

Quando uno strumento SaaS “fallisce SPF”, di solito il problema non è il suo record: la posta sta fallendo l’allineamento DMARC, oppure la sua catena di include ha sforato il limite SPF dei 10 lookup DNS. 2.119.539 dei 138.927.207 domini che pubblicano SPF si trovano a 9–10 lookup — a un solo include SaaS dal baratro — secondo il censimento Defaults.Exposed di 261.086.232 domini.

Qui sotto: come capire quale dei due problemi ha, poi l’ordine degli interventi — prima la scansione, poi individuare il dominio da cui lo strumento invia davvero, passare il fornitore al DKIM con dominio personalizzato e aggiungere un include SPF solo dove serve davvero — più le indicazioni specifiche per HubSpot, Salesforce, Mailchimp e SendGrid.

Perché la posta di uno strumento SaaS fallisce SPF?

Tre casi coprono quasi tutte le situazioni:

Dati aggiornati al 2026-06-29.

La riga in grassetto è quella in cui si trova la maggior parte delle persone. Aggiungere righe include: per ogni strumento non la tocca — e ogni riga la avvicina alla seconda: almeno 797.263 domini hanno già superato il limite dei 10 lookup, e il loro SPF ora restituisce un PermError che non protegge nulla. I numeri completi nel report sul PermError SPF.

Quale dominio verifica davvero l’SPF?

Non quello nella sua intestazione From. I server riceventi valutano l’SPF rispetto al dominio del Return-Path (l’RFC5321.MailFrom, detto anche indirizzo di bounce o envelope-from) — l’intestazione From che il destinatario vede non ha alcun ruolo nella verifica SPF in sé.

Questo singolo fatto spiega la maggior parte dei “fallimenti SPF dei SaaS”. La sua piattaforma di marketing invia con un Return-Path come [email protected]; l’SPF viene verificato su vendor.com e passa senza problemi. Poi il DMARC chiede se quel dominio verificato via SPF coincide con il suo dominio From. Non coincide, quindi la gamba SPF del DMARC fallisce e la sua dashboard dice “SPF failing”. Modificare il proprio record SPF non può risolverlo — il suo record non è mai stato consultato.

Qual è l’ordine degli interventi?

1. Esegua prima la scansione gratuita. Le dice in un solo passaggio se il suo SPF è mancante, duplicato, oltre il limite di lookup o a posto, e a che punto è il DMARC — prima di toccare il DNS.
2. Individui il Return-Path che lo strumento usa davvero. Si invii un messaggio di prova dallo strumento e legga l’intestazione Return-Path (e Authentication-Results) nel messaggio grezzo. Così saprà in quale riga della tabella qui sopra si trova.
3. Attivi il DKIM con dominio personalizzato del fornitore. Ogni strumento SaaS serio offre la “domain authentication”: pochi record CNAME che gli permettono di firmare DKIM a nome del suo dominio. Quella firma si allinea con il suo dominio From, quindi il DMARC passa via DKIM — in modo duraturo, e anche quando la posta viene inoltrata. Questa è la soluzione che dura.
4. Aggiunga l’include SPF del fornitore solo se usa il suo return-path — perché ha attivato il suo dominio di bounce personalizzato, o perché invia davvero con il suo dominio nell’envelope. Un include per un fornitore che gestisce i bounce tramite il proprio dominio non porta nulla e consuma il suo budget di lookup.
5. Conti i lookup DNS prima di salvare. Il limite è di 10 lookup risolti, gli include contano in modo ricorsivo, e 2.119.539 domini sono già a 9–10 — il p99 del censimento è 9. È vicino al limite? Rimuova prima gli include degli strumenti che non usa più. Ha appena cambiato provider di posta? Controlli che non sia rimasto un secondo record — due record SPF equivalgono a un PermError.
6. Ripeta la scansione e confermi. SPF che passa sul dominio giusto, DKIM allineato, DMARC che passa. Il riferimento completo è in come sistemare l’SPF; le guide passo-passo per provider come SPF su GoDaddy e DMARC su IONOS coprono i clic nel pannello DNS.

Cosa fare per HubSpot, Salesforce, Mailchimp e SendGrid?

HubSpot. Colleghi il suo dominio di invio nelle impostazioni di HubSpot e pubblichi i due CNAME DKIM che le fornisce (hs1-… / hs2-…). Questo allinea il DKIM con il suo dominio From. Non le serve un include SPF di HubSpot, a meno che non abbia configurato HubSpot per usare il suo dominio di bounce.

Salesforce. Crei una chiave DKIM nel Setup di Salesforce e pubblichi la coppia di CNAME che genera. Se Salesforce invia con il return-path della sua organizzazione, aggiunga include:_spf.salesforce.com e configuri il dominio di bounce — questo è l’unico grande CRM in cui l’include SPF è spesso davvero necessario.

Mailchimp. Autentichi il suo dominio e pubblichi i CNAME DKIM k2 / k3. L’allineamento di Mailchimp è solo DKIM — non esiste più alcun include SPF da aggiungere, e aggiungerne uno preso da un vecchio tutorial spreca soltanto lookup.

SendGrid. Completi la domain authentication (“automated security”): tre CNAME che gestiscono sia il DKIM sia il return-path su un suo sottodominio. Nessun include SPF necessario. Dei 740.321 domini il cui SPF autorizza sendgrid.net, solo il 18,0% ha un DMARC in modalità di applicazione (dati aggiornati al 2026-06-29) — la maggior parte di chi invia con SendGrid si ferma a un passo dal traguardo.

Zendesk e tutto il resto: stesso schema. Trovi la pagina di “domain authentication” dello strumento, pubblichi i suoi CNAME DKIM, e tocchi l’SPF solo se lo strumento documenta di usare il suo return-path.

L’SPF è diverso per le aziende europee?

No — SPF, DKIM e DMARC funzionano allo stesso modo ovunque. Ciò che cambia in Europa è il contesto: chi glielo chiede, e cosa hanno già fatto i suoi vicini.

Il suo ccTLD fissa l’asticella locale. I ccTLD europei pubblicano SPF a tassi ben superiori ai .com, ma i domini che completano il lavoro — con in cima una policy DMARC in modalità di applicazione — sono la minoranza ovunque:

Dati aggiornati al 2026-06-29. Francia: 13,65% con DMARC in applicazione; Italia: 5,24%.

I valori predefiniti del suo hosting europeo contano. 4.346.526 domini autorizzano i server di posta EU di IONOS (_spf-eu.ionos.com) nel loro SPF — e solo il 0,3% termina con il rigoroso -all, con il 1,0% che applica il DMARC. I 2.132.049 di OVH fanno meglio sul rigore (43,7%) ma solo il 2,2% applica il DMARC (dati aggiornati al 2026-06-29). Se non ha mai toccato il suo record, sta poggiando su quei valori predefiniti.

Ora anche i regolatori lo nominano. L’articolo 21(2)(j) della NIS2 impone alle entità in ambito di proteggere le proprie comunicazioni, e il Regolamento di esecuzione (UE) 2024/2690 della Commissione dettaglia le misure di sicurezza per email e DNS. L’autenticazione email è la parte concreta e verificabile — e, cosa insolita per la compliance, gratuita da sistemare.

Sulla residenza dei dati: lo scanner e il censimento di Defaults.Exposed girano in AWS eu-west-1, pubblichiamo solo cifre aggregate, e una scansione controlla soltanto il dominio che lei richiede.

Domande frequenti

Il mio checker SPF dice “pass” ma la dashboard dello strumento dice che l’SPF fallisce — perché? Il checker ha testato il suo record; il ricevente ha testato il dominio del Return-Path che lo strumento ha effettivamente usato, e poi il DMARC lo ha confrontato con il suo dominio From. È un fallimento di allineamento, non un difetto del record — si risolve con il DKIM a dominio personalizzato del fornitore, non modificando l’SPF.

Dovrei semplicemente aggiungere l’include SPF di ogni strumento che usiamo? No. Ogni include consuma parte del budget SPF di 10 lookup, in modo ricorsivo: 2.119.539 dei 138.927.207 domini che pubblicano SPF sono a 9–10 lookup, e almeno 797.263 sono oltre — il loro SPF restituisce PermError e non protegge nulla (dati aggiornati al 2026-06-29).

L’include sistema anche il DMARC? Solo se lo strumento invia con il suo return-path, così che l’SPF passi e sia allineato. Per la maggior parte degli strumenti SaaS non è così — ed è per questo che è il DKIM allineato, non l’SPF, la gamba che fa passare il DMARC per la posta SaaS.

È un obbligo di legge nell’UE? Per le entità in ambito NIS2, l’articolo 21(2)(j) e il Regolamento di esecuzione (UE) 2024/2690 rendono la sicurezza email un obbligo. Anche fuori ambito, assicuratori e questionari dei clienti lo chiedono sempre più spesso — e al 2026-06-29, nessun ccTLD dell’UE porta nemmeno un terzo dei propri domini a una policy DMARC in applicazione (29,43% in .nl nel migliore dei casi; 5,24% in .it).

Invii il report al titolare

Una volta che i CNAME sono attivi, ripeta la scansione e inoltri il report con i voti al titolare dell’azienda o al cliente. Mostra, in linguaggio semplice, cosa falliva, cosa ha sistemato e dove si trova ora il dominio — esattamente la prova che serve per il rinnovo dell’assicurazione o per il questionario di sicurezza del cliente, per iscritto invece che sulla sua parola.

Controlli gratuitamente il suo dominio

Veda esattamente quale gamba di SPF, DKIM e DMARC sta fallendo — in privato e visibile solo al titolare.

Controlli il suo dominio → · Sistemare l’SPF → · SPF PermError: “too many DNS lookups” → · Come assegniamo i voti → · Solo dati aggregati. Dati conservati ed elaborati nell’UE.