Defaults.Exposed › Report

Perché il mio SPF non funziona? Il problema dei 10 lookup per i mittenti UK e UE con strumenti SaaS (2026)

Pubblicato 2026-07-09

Dati al 2026-06-29 · metodologia v7. Dati aggregati del censimento su 261 milioni di domini valutati. Vedi come valutiamo.

Quando SPF fallisce per un’azienda che utilizza strumenti SaaS nel Regno Unito o nell’UE, la causa più probabile è un’unica regola RFC a cui non si è mai dovuto pensare: oltre 10 query DNS, SPF non restituisce “fail” — restituisce PermError, il che significa che il record viene trattato come se non esistesse. Almeno 797.263 domini hanno già superato quel limite. Altri 2.119.539 si trovano esattamente a 9–10 lookup — basta un nuovo strumento per cadere dallo stesso precipizio.

Perché SPF si rompe quando si aggiunge uno strumento SaaS?

SPF funziona elencando i server di posta autorizzati a inviare per conto del dominio. Le aziende moderne non gestiscono i propri server di posta — usano Google Workspace per le email interne, Mailchimp per le campagne, HubSpot per le sequenze di vendita, Pipedrive per il CRM. Ogni piattaforma fornisce una riga include: da incollare nel DNS.

Il problema: ogni include: è di per sé una query DNS. E ogni record all’interno di quell’include può scatenare ulteriori lookup in modo ricorsivo. RFC 7208 §4.6.4 fissa un limite rigido di dieci. Oltre dieci, il server di posta ricevente interrompe la valutazione e restituisce PermError — e un PermError non è un fallimento morbido che finisce nello spam. Significa che il record SPF è trattato come assente. L’autenticazione dell’email fallisce al livello SPF.

Non vedrete questo nel pannello DNS. Il contatore scatta solo durante la valutazione in tempo reale. Si possono avere tre righe include: nel record visibile ed essere comunque a dodici lookup di profondità, perché il record SPF di ogni fornitore contiene i propri sub-include.

Quanti domini hanno già superato il limite?

Almeno 797.263. È il conteggio dopo aver risolto ogni destinazione SPF include: referenziata 100 o più volte — 10.842 destinazioni distinte che coprono il 95,2% di tutti i riferimenti include — e aver calcolato la catena completa di ogni dominio. Il conteggio superficiale (contando solo le righe visibili in un record) trova circa 7958. Il numero calcolato per catena è 100 volte superiore, perché quasi tutto il danno è invisibile all’interno delle destinazioni include.

La situazione che più spesso colpisce un’azienda europea:

Fornitori di hosting europei e impostazioni SPF deboli

Il fornitore di hosting scelto all’inizio è importante — perché alcuni impostano configurazioni SPF predefinite che consumano già diversi dei dieci lookup prima ancora di collegare un singolo strumento SaaS.

Tra i principali fornitori di hosting usati da domini europei nel nostro censimento:

IONOS si distingue negativamente: solo il 1,0% dei domini ospitati su IONOS ha DMARC attivo, il che significa che la stragrande maggioranza non dispone di alcuna autenticazione del mittente significativa. I domini OVH se la cavano meglio con l’impostazione SPF strict (43,7%), ma scendono al 2,2% sull’applicazione DMARC — SPF da solo, senza DMARC che lo colleghi all’intestazione From:, protegge solo la busta, non ciò che vede il destinatario.

Microsoft 365 è l’eccezione positiva: il 85,0% dei domini ospitati da Microsoft usa SPF strict, principalmente perché la procedura guidata di Microsoft imposta -all per impostazione predefinita. Google Workspace imposta ~all (softfail) per impostazione predefinita, lasciando il 92% dei suoi domini senza protezione rigorosa.

Come diagnosticare il fallimento di SPF in meno di 60 secondi

La verifica più rapida è uno strumento gratuito che valuta l’intera catena di lookup — non solo il record visibile. Eseguire nslookup -type=TXT iltuodominio.com dalla riga di comando e contare ogni include: visibile. Poi cercare ognuno di quei record e contare i loro. Se si esauriscono le dita prima degli include, si è nella zona di pericolo.

Un approccio più affidabile: controlla il tuo dominio qui — lo scanner valuta l’intera catena risolta, segnala i PermError e mostra quali meccanismi stanno consumando il budget di lookup.

Tre possibili esiti diagnostici:

• PermError — si è già oltre dieci. Ogni email inviata fallisce il controllo SPF al ricevente.
• A 9–10 lookup — si è sul bordo del precipizio. La prossima integrazione SaaS farà cadere oltre.
• Softfail (~all) invece di hardfail (-all) — si è sotto il limite, ma il record è configurato in modo troppo permissivo per offrire una protezione reale. Vedere il report sulle configurazioni errate di SPF per il quadro completo su -all vs ~all.

Come correggere SPF quando si usano più strumenti SaaS

Esistono tre approcci, in ordine di permanenza:

1. Verificare e potare. Iniziare elencando tutti gli include: nel record attuale. Rimuovere qualsiasi piattaforma che non si usa più — vecchi ESP, strumenti CRM di contratti precedenti, piattaforme testate ma abbandonate. È gratuito e spesso recupera diversi lookup. Ogni include: rimosso può eliminare 1–3 sub-lookup.

2. Appiattire il record SPF. L’appiattimento SPF risolve tutte le destinazioni include: nei relativi intervalli IP sottostanti e li scrive direttamente nel record come meccanismi ip4: e ip6:. I meccanismi IP non attivano lookup, quindi un record appiattito può elencare decine di fonti di invio e rimanere comunque a zero lookup. Lo svantaggio: occorre ri-appiattire ogni volta che un fornitore aggiorna i propri IP di invio, il che avviene senza preavviso. La maggior parte delle organizzazioni usa un servizio di appiattimento gestito (PowerDMARC, EasyDMARC, Dmarcian e altri) o costruisce un flusso di monitoraggio.

3. Usare le macro SPF. Le macro RFC 7208 consentono di costruire record che eseguono una singola query DNS per ogni verifica e rispondono dinamicamente, invece di una catena di include. Le macro richiedono il supporto dell’hosting DNS e un certo sforzo implementativo, ma sono la soluzione architetturalmente pulita per le organizzazioni con molti mittenti SaaS.

Dopo aver corretto SPF, associarlo con l’applicazione di DMARC — SPF senza DMARC autentica solo il mittente della busta, non l’indirizzo From: dell’intestazione che i destinatari vedono.

Domande frequenti

Perché il mio record SPF supera il test del mio strumento DNS ma fallisce nelle intestazioni delle email? La maggior parte degli strumenti di lookup DNS conta solo i meccanismi visibili nel proprio record, non i sub-lookup che quei meccanismi scatenano. Si possono avere due righe include: ed essere comunque oltre il limite se il record di ogni fornitore ne contiene altri. Solo uno strumento di valutazione per catena (o un server di posta ricevente) conta la profondità totale. Controlla il tuo dominio per vedere il conteggio reale della catena.

Il fallimento di SPF significa che le mie email vanno nello spam? PermError (troppi lookup) significa che la componente SPF dell’autenticazione restituisce un non-risultato — di fatto assente. DMARC valuta sia SPF che DKIM; se DKIM passa, DMARC può comunque passare nonostante il PermError SPF. Se nessuno dei due passa, DMARC fallisce, e l’esito dipende dalla policy DMARC. Con p=none, l’email viene consegnata ugualmente, ma il fallimento viene registrato. Con p=quarantine o p=reject, l’email viene filtrata o respinta. Correggere SPF per non dipendere solo da DKIM.

Quanti lookup consuma una tipica pila SaaS? Il record SPF al p99 del nostro censimento si trova già a 9 lookup — proprio al limite — prima di aggiungere qualsiasi cosa. Un record Google Workspace aggiunge 3–4 lookup; Mailchimp ne aggiunge 1–2; HubSpot ne aggiunge 1–3 a seconda della configurazione attuale. Tre strumenti comuni più la configurazione predefinita del fornitore di hosting sono spesso sufficienti per superare dieci.

L’appiattimento SPF è sicuro? Sì, a condizione che venga mantenuto aggiornato. L’appiattimento converte le catene include: in intervalli IP statici — se un fornitore ruota i propri IP di invio e non si ri-appiattisce, si inizierà a rifiutare la loro posta. La maggior parte delle organizzazioni usa un servizio di appiattimento gestito che monitora le modifiche agli IP piuttosto che farlo manualmente.

Il mio SPF è così da anni — perché sta fallendo improvvisamente? Perché i tuoi fornitori hanno aggiornato i loro record SPF, non il tuo. Ogni volta che una piattaforma SaaS aggiunge un nuovo intervallo di IP di invio o annida un altro include, il costo della catena sale senza alcuna modifica dalla tua parte. Il limite dei 10 lookup viene valutato in tempo reale alla ricezione del messaggio, quindi una modifica da parte di un fornitore un martedì mattina può rompere il tuo SPF entro il martedì pomeriggio.

Correggere SPF migliora la consegnabilità delle email? Rimuove una fonte di fallimento dell’autenticazione, che è un prerequisito per una consegna coerente — soprattutto da quando Google e Yahoo impongono ora l’allineamento DMARC per i mittenti di massa. SPF da solo non è il quadro completo: abbinarlo con DKIM e DMARC per un’autenticazione email completa.

Controlla il tuo SPF gratuitamente

Se non sei sicuro che il tuo record SPF superi il limite di lookup — o sia impostato in modo troppo debole per proteggere il tuo dominio — esegui un controllo gratuito. Valuta l’intera catena risolta e mostra esattamente dove viene speso il budget.

Controlla il tuo dominio → · Correggi SPF → · Il report SPF PermError → · Report sulle configurazioni errate di SPF → · Il modello di maturità di adozione di SPF → · Correggi DMARC → · Solo dati aggregati. Dati archiviati ed elaborati nell’UE.