Un’email di ripristino della password viene inviata. Non arriva mai. Nessun messaggio di errore dal lato del mittente, nessun bounce, nessun avviso nel tuo strumento di invio. Solo silenzio. In alcuni casi, la causa è un record SPF che ha superato il suo limite di 10 richieste DNS, senza che nessuno nell’organizzazione se ne accorga. Questo è noto come PermError. Si verifica molto più frequentemente di quanto si pensi nelle aziende che utilizzano diversi servizi SaaS per i loro invii.
Qual è il limite SPF e perché esiste
Il SPF (Sender Policy Framework) è un protocollo di autenticazione email che consente a un dominio di dichiarare quali server sono autorizzati a inviare a suo nome. Il limite di 10 ricerche DNS per verifica SPF è stabilito nella RFC 7208 (IETF, 2014), la specifica ufficiale del protocollo. Non è opzionale: la RFC richiede che un’implementazione SPF restituisca un errore permanente se questa soglia viene superata.
La ragione tecnica è concreta. Ogni meccanismo SPF del tipo include:, a, mx, ptr o exists attiva una richiesta DNS aggiuntiva. Senza un tetto massimo, una regola SPF maligna o mal configurata potrebbe costringere i server di ricezione ad effettuare decine di richieste DNS, creando un carico eccessivo sui risolutori ricorsivi e aprendo la porta ad attacchi di denial of service. I meccanismi ip4:, ip6: e all non innescano alcuna richiesta e non contano nel limite.
Questo limite risale a quando un’azienda aveva raramente più di uno o due fornitori di servizi email. Nel 2014, Microsoft 365 non esisteva con quel nome, Salesforce Marketing Cloud si chiamava ancora Exact Target e HubSpot rappresentava solo una frazione del suo utilizzo attuale. Il limite è stato pensato per un mondo che non è più il nostro.
Perché le aziende SaaS di oggi raggiungono questo limite senza accorgersene
Il problema risiede nel modo in cui i servizi email moderni pubblicano i propri record SPF. Un include: verso un fornitore non costa una sola ricerca: costa tanto quanto il fornitore ha definito nel proprio record, incluse le inclusioni nidificate. Google Workspace (_spf.google.com) consuma tra 3 e 5 ricerche da solo. Microsoft 365 (spf.protection.outlook.com) consuma tra 3 e 5 a seconda della configurazione regionale. Aggiungi SendGrid (1 a 3), Salesforce (1 a 3) e HubSpot (1 a 2): il totale supera 10 anche prima di aver aggiunto il servizio di fatturazione, la piattaforma RH o lo strumento di supporto.
Ciò che aggrava la situazione è che i fornitori possono modificare la loro infrastruttura DNS senza preavviso. Il servizio a cui hai delegato un include: sei mesi fa potrebbe aver aggiunto nuovi server nel frattempo, portando il tuo conteggio da 9 a 12 ricerche senza alcuna azione da parte tua. Secondo i dati di dmarcchecker.app sui top 1 milione di domini (2024), il 2% dei domini con un record SPF valido ha già una configurazione non valida che causa un PermError. Questo numero può sembrare basso, ma rappresenta migliaia di organizzazioni i cui email legittimi sono continuamente influenzati, spesso senza che i team IT lo sappiano.
Cosa succede concretamente quando viene superata la soglia
Quando una verifica SPF raggiunge 11 richieste DNS, il server di ricezione restituisce un risultato permerror, un errore permanente non recuperabile. Il destino dell’email dipende poi dalla policy DMARC configurata sul dominio del mittente.
Con p=none, l’email viene generalmente consegnata nonostante il PermError. Il dominio viene trattato come non autenticato. È una falsa tranquillità: le email passano, ma la protezione contro l’usurpazione del dominio non esiste. Con p=quarantine, le email finiscono nello spam, senza avviso dal lato mittente. Con p=reject, la politica più severa e quella che Google e Yahoo richiedono dal febbraio 2024 per i mittenti di più di 5000 messaggi al giorno, le email vengono respinte. Conferme d’ordine, reimpostazioni di password, avvisi di sicurezza e comunicazioni interne scompaiono senza lasciare traccia negli strumenti di invio.
È lo scenario più difficile da diagnosticare. L’email parte. Non ritorna. Non arriva.
Il flattening SPF: perché la soluzione rapida peggiora le cose
La reazione più comune a questo problema è il “flattening” SPF: si sostituiscono tutti i meccanismi include: con gli indirizzi IP corrispondenti, riducendo il numero di ricerche a zero o quasi. Il risultato immediato è positivo. Gli effetti a medio termine sono più problematici.
Il CTO di dmarcian riassume bene il problema di fondo: la maggior parte dei record appiattiti finisce per autorizzare range di indirizzi IP troppo ampi, appartenenti ai grandi host cloud, di cui una parte non corrisponde a nessun server di invio reale del fornitore. Gli attori malintenzionati possono sfruttare questi range autorizzati per inviare dal tuo dominio. Si risolve un problema di deliverability creando un problema di sicurezza.
L’altra difficoltà è la manutenzione. I fornitori di email cambiano regolarmente i loro pool di IP, senza preavviso. Un record appiattito deve essere aggiornato manualmente a ogni modifica, altrimenti i nuovi server del fornitore restano esclusi e le email che gestiscono falliscono l’autenticazione SPF. Il flattening converte un problema di configurazione in un onere operativo permanente.
Le soluzioni che funzionano a lungo termine
Il primo passo è un audit del conteggio reale. Strumenti come MXToolbox, il SPF Record Checker di dmarcian analizzano il tuo record SPF e contano le ricerche in cascata, inclusioni nidificate comprese. Senza questo audit, è impossibile sapere dove si trova realmente il contatore.
La segmentazione per sotto-domini è la soluzione architetturale più affidabile. Spostare le email di marketing su marketing.tuodominio.com e le email transazionali su notifiche.tuodominio.com dà a ogni sotto-dominio il proprio limite di 10 ricerche. Questa separazione ha un ulteriore vantaggio: un problema di reputazione sulle campagne di marketing non influisce sulle email transazionali critiche.
Per i domini che non possono facilmente segmentare, le macro SPF sono un’alternativa seria. Spostano la valutazione fuori dalla catena di ricerche standard, passando la verifica a un servizio esterno tramite una singola richiesta DNS. Esistono soluzioni basate su questo principio. Il risvolto è reale: se l’infrastruttura del fornitore cade, cade anche l’autenticazione SPF del dominio.
La misura più spesso trascurata rimane l’eliminazione delle voci diventate inutili. Molti record SPF accumulano include: verso fornitori che l’azienda non utilizza più da mesi o meccanismi a e mx ereditati da una configurazione vecchia. Un audit annuale recupera spesso diverse ricerche senza toccare l’architettura di invio.
Monitorare nel tempo, non solo correggere una volta
Un record SPF conforme oggi può superare il limite domani se un fornitore modifica la sua infrastruttura. I report aggregati DMARC (formato RUA) sono l’indicatore più accessibile: mostrano la percentuale di email che passano o falliscono l’autenticazione SPF per ogni dominio mittente dichiarato. Qualsiasi picco improvviso di fallimenti SPF merita un’indagine immediata sul conteggio delle ricerche.
Il limite delle 10 ricerche SPF è un vincolo del 2014 che la RFC 7208 non ha rivisto da allora. Le organizzazioni che passano a DMARC in modalità enforcement, come richiesto da Google dal 2024 per i mittenti di grandi volumi, lo scoprono talvolta nel peggior momento: quando le loro email critiche smettono di arrivare e nessuno sa perché.
Che cos’è un PermError SPF?
Un PermError SPF è un errore permanente restituito dal server di ricezione quando la verifica SPF non può essere completata, in particolare perché il numero di richieste DNS supera 10. A differenza di un TempError (errore temporaneo recuperabile), un PermError persiste fino a quando il record SPF non viene corretto. DMARC tratta un PermError come un fallimento SPF a tutti gli effetti.
I meccanismi ip4 e ip6 contano nel limite delle 10 ricerche?
No. I meccanismi ip4:, ip6: e all non innescano alcuna richiesta DNS e non contano nel limite. Vengono conteggiati solo i meccanismi che richiedono una risoluzione DNS: include:, a, mx, ptr, exists e il modificatore redirect.
Come sapere se il mio record SPF supera il limite?
Strumenti come MXToolbox SPF Checker, il verificatore di domini di dmarcian analizzano il record SPF e contano le ricerche DNS in cascata, inclusioni nidificate incluse. Un risultato superiore a 10 conferma che il record restituisce un PermError a ogni verifica, indipendentemente dalla policy DMARC in vigore.
