Defaults.Exposed › Report
Il report sul PermError SPF: 100× più domini superano il limite delle 10 ricerche di quanti ne mostrino i conteggi in superficie (2026)
Pubblicato 2026-07-03
Cifre aggiornate al 2026-06-29 · metodologia v7, più un passaggio di valutazione delle catene eseguito il 2026-07-03. Dal censimento di 261 milioni di domini valutati, abbiamo risolto ogni target di
include:SPF referenziato 100 o più volte — 10.842 target che coprono il 95,2% di tutti i riferimenti include — e abbiamo valutato la catena mantenuta da ciascun dominio rispetto a quella mappa. I target di coda non risolti sono stati contati come zero e il contenuto delle catene riflette il giorno della risoluzione, quindi il titolo è un’approssimazione conservativa, orientata al minimo: diciamo “almeno”. Solo dati aggregati; mai il record di una singola azienda. Vedi come valutiamo.
Quanti domini superano il limite delle 10 ricerche SPF?
Almeno 797.263 — perché SPF ha un’autodistruzione integrata nello standard, e il fattore scatenante si nasconde dove i proprietari non possono vederlo. L’RFC 7208 §4.6.4 limita una verifica SPF a 10 ricerche DNS; oltre dieci, il ricevente si ferma e restituisce PermError, e un record in PermError non protegge nulla. Conta solo le ricerche visibili nel record stesso — come fa la maggior parte degli strumenti, e come faceva il nostro stesso censimento fino a questo report — e trovi circa 8.000 trasgressori (7958, per la precisione). Valuta le catene di include: che quei record effettivamente richiamano, e il conteggio arriva a 797.263: circa 100 volte più grande.
Perché i proprietari non riescono a prevederlo?
Perché il budget viene consumato dai record di altri. include:onetool.example.com si legge come una riga nel tuo pannello DNS — ma il ricevente deve recuperare anche quel record, e contare ogni meccanismo di ricerca che esso contiene, in modo ricorsivo. Un record con tre include può costare undici. Nulla è cambiato nella tua zona il giorno in cui hai superato il limite; un provider ha annidato un include in più, e il tuo SPF è morto senza preavviso.
Peggio ancora, DMARC tratta un PermError come un fallimento sulla parte SPF — quindi un dominio che ha rotto il proprio SPF in questo modo ora fallisce metà della propria autenticazione.
Cosa ha trovato la valutazione delle catene
| Riscontro | Domini |
|---|---|
| Oltre il limite delle 10 ricerche, catene valutate | 797.263 |
| Oltre il limite contando solo i meccanismi visibili | 7958 |
Oltre il limite pur terminando con -all restrittivo | 112.215 |
| Esattamente a 9–10 ricerche — sull’orlo del precipizio | 2.119.539 |
Due storie in quella tabella — la terza, l’orlo del precipizio, ha una sezione tutta sua qui sotto:
- I conteggi in superficie mancano circa il 99% della rottura. Il conteggio dei meccanismi visibili trova 7958; la valutazione delle catene trova 797.263. Quasi tutto il danno è ereditato da ciò che gli include includono.
- 112.215 dei record rotti terminano con
-all. I loro proprietari hanno fatto tutto bene — hanno scalato il muro, hanno scelto la terminazione restrittiva — e un include di troppo ha annullato il tutto. Sembrare restrittivi ed essere rotti è la modalità di fallimento più dura nella sicurezza email.
2,1 milioni di domini sono a uno strumento di distanza dal precipizio
Il numero che dovrebbe preoccupare i lettori che sono attualmente a posto: 2.119.539 domini si risolvono esattamente a 9 o 10 ricerche — sotto il limite oggi, morti il giorno in cui qualcuno collega un’altra piattaforma. È circa 1 su 66 di tutti i publisher SPF, e corrisponde alla forma della distribuzione: il record SPF al 99° percentile è già a 9 ricerche. Iscriviti a un altro strumento di marketing, incolla la sua riga “basta aggiungere questo include”, e un record che al mattino era sotto il limite è nullo all’ora di pranzo.
Di chi è la colpa? Sempre più, dello stack
I provider più grandi hanno silenziosamente appiattito il loro SPF — _spf.google.com di Google e spf.protection.outlook.com di Microsoft ora si espandono in semplici liste di IP che costano zero ricerche interne (abbiamo verificato entrambi rispetto al DNS reale durante questa analisi). Le esplosioni arrivano da altrove: catene di pannelli di hosting annidate su tre livelli, provider regionali il cui include costa da solo 7–10 ricerche, e l’onesto accumulo di SaaS — casella di posta più newsletter più CRM più helpdesk, ognuno “solo un include”. Quasi nessuno aggiunge l’undicesima ricerca di proposito. Arriva come somma di decisioni ragionevoli.
Come controllare e correggere il tuo — gratis
- Conta il tuo totale reale — il nostro controllo gratuito risolve la tua catena, oppure usa un qualsiasi contatore di ricerche SPF.
- Elimina il peso morto: strumenti che hai smesso di usare, include duplicati, e il meccanismo
ptrdeprecato. - Appiattisci solo ciò che controlli. Sostituire un include profondo con i suoi blocchi di IP funziona per la tua infrastruttura; gli IP di terze parti cambiano senza preavviso.
- Dai ai mittenti di massa un sottodominio. Le newsletter da
news.tuodominio.comottengono un proprio record e un proprio budget di 10 ricerche.
Domande frequenti
Cos’è il limite delle 10 ricerche DNS di SPF?
L’RFC 7208 §4.6.4 consente al massimo 10 ricerche DNS per valutare un record SPF — contando ricorsivamente le ricerche all’interno di ogni include:. Superarlo restituisce PermError: il record è trattato come non valido e non fornisce alcuna protezione.
Cosa significa PermError SPF? Un errore permanente di valutazione — il ricevente non è riuscito a elaborare il tuo record (troppe ricerche, record multipli, o sintassi non valida) e tratta il tuo dominio come privo di un SPF utilizzabile. DMARC lo conta come un fallimento sulla parte SPF.
Quanti domini superano il limite di ricerche SPF? Almeno 797.263 su 139 milioni di publisher SPF, secondo il nostro passaggio di valutazione delle catene — circa 100× i 7958 visibili senza risolvere le catene. Altri 2.119.539 si trovano a 9–10 ricerche, a un include dal limite.
Un PermError impedisce la consegna della mia email? Di solito no — i riceventi procedono senza SPF, e la tua posta si affida a DKIM e alla reputazione. Ciò che smette di funzionare è la protezione: i falsificatori non vengono più rifiutati, e ogni verifica DMARC della tua posta perde la sua parte SPF. È invisibile finché non diventa costoso.
Come riduco il conteggio delle ricerche SPF?
Rimuovi gli include inutilizzati e ptr, appiattisci la tua infrastruttura in ip4:/ip6:, sposta i mittenti di massa sui sottodomini, e riconta dopo ogni nuovo strumento. La guida alla correzione ti accompagna passo passo.
Scopri il tuo numero reale
I meccanismi che puoi vedere non sono il tuo conteggio di ricerche — il numero risolto è quello che calcolano i riceventi, ed è un controllo di 30 secondi.
Controlla il tuo dominio → · Correggi SPF → · Il modello di maturità SPF → · Due record SPF = nessuno → · La trappola del ptr → · Solo dati aggregati. Dati archiviati ed elaborati nell’UE.