Risolvere il limite SPF 10-Lookup: guida tecnica per MSP

Riepilogo esecutivo Il record SPF di ogni dominio è limitato a 10 lookup DNS — una restrizione introdotta nel 2006 che non tiene il passo con l’attuale stack SaaS moderno. Per gli MSP che gestiscono dozzine di domini clienti, ognuno con il proprio mix di strumenti per email, marketing, fatturazione e assistenza, superare questo limite è quasi inevitabile. Quando accade, le email legittime falliscono l’autenticazione senza segnalazioni, l’allineamento DMARC si rompe e i ticket di supporto iniziano ad accumularsi. Questa guida accompagna gli MSP nella comprensione del meccanismo del limite di lookup, come eseguire audit su scala per i domini dei clienti, perché le soluzioni tradizionali come flattening e delega dei sottodomini non sono sufficienti, e come Dynamic SPF elimina completamente la restrizione, trasformando la gestione SPF da reattiva ed emergenziale ad un servizio automatizzato e scalabile.

Punti chiave

• Ogni meccanismo SPF include, a, mx, redirect, exists e ptr conta ai fini del tetto delle 10 lookup — e gli include nidificati nei record di terze parti consumano lookup nascosti facilmente trascurabili durante una revisione manuale.
• Un tipico cliente mid-market che usa sette o più strumenti SaaS è già prossimo o a rischio di superare la soglia, il che significa che anche una sola nuova integrazione può causare PermError e interrompere la recapitabilità senza alcun preavviso.
• Google e Microsoft ora applicano esplicitamente la conformità SPF per i mittenti ad alto volume, rendendo il limite di lookup un requisito per la deliverability e non più solo una raccomandazione di best practice.
• Il flattening dell’SPF crea un onere manutentivo perché i provider Cloud cambiano spesso gli IP di invio e ciò rende i record flattened rapidamente obsoleti su tutto il portafoglio.
• Dynamic SPF consolida tutti i mittenti autorizzati in un unico include auto-aggiornante che resta sotto il limite a prescindere da quanti servizi il cliente utilizzi.
• Gli MSP dovrebbero eseguire audit su ogni dominio cliente all’onboarding, segnalare a rischio qualunque dominio che abbia 8 o più lookup e trattare la risoluzione SPF come lo snodo per portare i clienti dal monitoraggio DMARC all’enforcement totale.

Un cliente aggiunge HubSpot al proprio stack di marketing. Una settimana dopo, le fatture del CFO finiscono in spam. Arriva un ticket di supporto e la causa principale è qualcosa che nessuna checklist di onboarding aveva previsto: il record SPF del cliente ha appena superato il decimo lookup DNS, provocando un errore permanente di autenticazione che nessun tentativo di diagnosi lato inbox riuscirà a risolvere. Per gli MSP che gestiscono decine di domini clienti, ognuno con il proprio stack di email, CRM e supporto, questo scenario è sempre più frequente. 

Piattaforme come Red Sift OnDMARC affrontano il problema tramite Dynamic SPF, che elimina completamente il vincolo del limite di lookup. Ma comprendere perché esiste il limite, come viene superato e cosa non funziona nei workaround tradizionali è una conoscenza indispensabile per ogni MSP che costruisce una pratica DMARC.

Questa guida spiega il limite dei 10 lookup SPF in termini pratici, illustra i workaround più comuni e i loro limiti e presenta le soluzioni automatizzate che permettono agli MSP di scalare l’autenticazione email dei clienti senza incappare in questo ostacolo.

• Cosa significa davvero il limite dei 10 lookup SPF
• Perché gli MSP colpiscono il limite più di chiunque altro
• Come auditare il record SPF di un cliente
• Workaround tradizionali e perché non funzionano
• Dynamic SPF: la soluzione automatica
• Come costruire un workflow di gestione SPF per MSP
• FAQ

SPF (Sender Policy Framework) permette ai titolari di un dominio di dichiarare quali mail server sono autorizzati ad inviare email per loro conto. I server destinatari controllano il record SPF del dominio mittente e verificano se l’IP di origine è consentito. Il protocollo funziona, ma pone un limite rigido definito dalla RFC 7208: la valutazione SPF non deve richiedere più di 10 meccanismi o modificatori che generano ulteriori lookup DNS [1].

Questo limite esiste per proteggere l’infrastruttura DNS. Senza di esso, un record SPF errato o malevolo potrebbe causare catene di lookup DNS senza limiti, consumando risorse del ricevente e dando vita a condizioni di denial-of-service. Il limite rende la valutazione prevedibile e contenuta.

Una sfumatura importante: il limite conta il numero di meccanismi che richiedono lookup, non il numero totale di query DNS generate [2]. Un meccanismo mx conta come uno ai fini del limite, anche se può generare molteplici query follow-up per risolvere tutti gli indirizzi dei mail server. Questa distinzione è importante nell’ottimizzazione: sostituire mx con ip4 fa risparmiare sempre un lookup, a prescindere da quanti record MX abbia il dominio.

Quando un server destinatario supera il tetto dei 10 lookup nella valutazione, restituisce PermError, un errore SPF permanente. L’impatto varia a seconda della configurazione del destinatario: alcuni respingono il messaggio, altri lo mandano in spam, altri ancora lo trattano come risultato neutro. In tutti i casi, l’allineamento DMARC si rompe se SPF era l’unico meccanismo valido, portando a quarantena o rifiuto in downstream.

Il limite dei lookup SPF è stato definito nel 2006 e formalizzato nella RFC 7208 nel 2014, quando una tipica organizzazione usava uno o due servizi di invio email. Oggi lo scenario SaaS è ben diverso. Un singolo cliente mid-market può richiedere include SPF per:

• Piattaforma email (Google Workspace o Microsoft 365)
• Automazione marketing (HubSpot, Marketo o Mailchimp)
• Sistema CRM (Salesforce)
• Support desk (Zendesk o Freshdesk)
• Fatturazione e contabilità (QuickBooks, Xero)
• HR e recruiting (Greenhouse, BambooHR)
• Email transazionali (SendGrid o Amazon SES)

Ognuno di questi servizi tipicamente richiede un proprio meccanismo include nel record SPF del dominio. Sette servizi equivalgono già a sette lookup, senza contare eventuali meccanismi a o mx del dominio stesso. Basta aggiungere un ulteriore tool e si supera la soglia.

Per gli MSP il problema si amplifica perché ogni dominio cliente rappresenta una specifica variante di questa sfida. Un portafoglio di 30 domini significa 30 combinazioni SaaS diverse, 30 SPF da monitorare e 30 possibili punti di rottura. Quando l’IT del cliente o il marketing aggiunge un servizio senza avvisare l’MSP, il record SPF può superare il limite senza segnali. Le email iniziano a non passare sporadicamente (PermError scatta solo quando si raggiunge effettivamente l’undicesimo lookup, e non tutti i destinatari valutano ogni meccanismo per ogni messaggio), rendendo il problema difficile da rilevare e riprodurre.

Google ora richiede la conformità SPF per chi invia oltre 5.000 email giornaliere [3] e Microsoft prevede requisiti simili con indicazioni esplicite a restare entro il limite delle 10 lookup [4]. Per gli MSP, la conformità dei bulk sender non è più opzionale per alcun cliente che invii campagne email su larga scala.

Prima di risolvere il problema, gli MSP devono quantificarlo. Un audit sistematico determina quante lookup servono all’attuale record SPF e da dove arrivano gli eccessi.

Processo di audit passo passo:

1. Interroga il record SPF con uno strumento come Red Sift's SPF Checker o una query DNS a riga di comando (dig TXT example.com) per recuperare il record grezzo
2. Mappa la catena include espandendo ogni include in maniera ricorsiva. Ogni include aggiunge un lookup e il record incluso può contenere a sua volta include nidificati
3. Conta tutti i meccanismi che generano lookup ossia include, a, mx, redirect, exists e ptr
4. Identifica servizi non più utilizzati confrontando gli include SPF con l’infrastruttura reale di invio email del cliente. I servizi dormienti continuano a occupare lookup
5. Documenta il conteggio attuale e segnala a rischio ogni dominio con 8 o più lookup (due servizi lontano dalla rottura)
6. Controlla la profondità delle nidificazioni perché alcuni SPF di terzi contengono molti include a cascata: un solo include:terzo.it può consumare tre o quattro lookup una volta espanso

Eseguire questo audit su tutto il portafoglio rivela l’ampiezza del problema. La maggior parte degli MSP scopre che una quota significativa di domini clienti è già oltre il limite o a una sola aggiunta di distanza dal superarlo.

Gli MSP che incontrano per la prima volta il limite dei 10 lookup ricorrono spesso ai workaround più diffusi. Ognuno ha limiti che lo rendono inadatto alla produzione su larga scala.

Il flattening sostituisce i meccanismi include con gli indirizzi IP risolti (ip4 e ip6), riducendo così i lookup a zero per quei servizi. La soluzione è teorica: nella pratica i provider cloud variano spesso gli IP di invio, rendendo i record flattened rapidamente obsoleti e provocando il fallimento di email legittime.

Il flattening manuale richiede che l’MSP monitori tutte le range di IP dei provider e aggiorni i DNS a ogni variazione. Su un portafoglio di 30 domini, ciascuno con provider diversi, il carico manutentivo è insostenibile. Basta mancare una rotazione IP per causare disservizi diffusi.

Pubblicare più di un record SPF TXT per un dominio viola la specifica SPF [1]. I destinatari che trovano più record devono restituire PermError, quindi questa soluzione rompe attivamente l’autenticazione invece di risolvere il limite.

Separare i servizi email su diversi sottodomini (marketing.example.com, support.example.com) distribuisce i lookup SPF su più record. Così si riduce il conteggio per sottodominio ma si introduce complessità per l’allineamento DMARC, occorrono Return-Path configurati ad hoc e si crea un overhead operativo non gestibile su molti domini.

Alcuni MSP scoprono che non tutti i destinatari applicano in modo rigoroso il limite dei 10 lookup. Ciò porta a lasciar “funzionare” i record over-limit senza fix. Il rischio: le policy dei destinatari variano nel tempo e tra provider. Sia Google che Microsoft hanno ora riferimenti espliciti alla compliance SPF, quindi la tolleranza su questo approccio è destinata a ridursi.

Dynamic SPF affronta il limite con una strategia del tutto diversa. Invece di lavorare entro il vincolo dei 10 lookup gestendo manualmente i record, Dynamic SPF consolida tutte le sorgenti autorizzate in un unico include mantenuto automaticamente, sempre sotto soglia.

Come funziona:

1. Monitoraggio continuo: la piattaforma traccia in tempo reale gli intervalli IP di tutti i servizi di invio autorizzati (Google Workspace, Microsoft 365, Salesforce, HubSpot ecc.)
2. Consolidamento intelligente: i meccanismi include basati su dominio vengono risolti in IP e combinati in un record unico ottimizzato
3. Aggiornamento automatico: quando un provider cambia infrastruttura di invio, il Dynamic SPF si aggiorna in pochi minuti senza alcun intervento DNS manuale
4. Include singolo: il record SPF del cliente richiama un solo include Dynamic SPF, consumando un unico lookup a prescindere dai servizi autorizzati

Il risultato: gli MSP possono aggiungere nuovi servizi email ai domini dei clienti senza preoccuparsi del conteggio. Un cliente con quindici tool usa lo stesso singolo lookup di chi ne ha tre. L’ostacolo tecnico che bloccava l’enforcement DMARC scompare.

Per gli MSP che valutano le piattaforme DMARC, la capability Dynamic SPF deve essere un criterio di selezione centrale. Le differenze tra SPF, DKIM e DMARC contano, ma la vera domanda pratica è se la piattaforma gestisce il limite su larga scala in un portafoglio eterogeneo.

Risolvere il limite SPF per un singolo dominio è semplice. Risolverlo per tutto il portafoglio richiede un processo ripetibile.

Workflow consigliato:

1. Audit del portafoglio: all’onboarding calcolare il numero di lookup per tutti i domini clienti. Segnalare a rischio ogni dominio che ne abbia 8 o più
2. Priorità per impatto: intervenire prima sui domini over-limit, poi su quelli a rischio. I clienti con DMARC in p=quarantine o p=reject hanno massima priorità perché errori SPF incidono subito sulla deliverability
3. Distribuisci Dynamic SPF: migra i domini su una piattaforma con gestione Dynamic SPF. Il programma partner MSP Red Sift offre infrastrutture multi-tenant progettate per MSP con molti domini
4. Stabilisci il change control: crea una procedura che richieda la validazione MSP per ogni nuovo servizio email. Così si evita che i clienti aggiungano tool SaaS che avrebbero rotto lo SPF
5. Monitora costantemente: usa alert automatici per individuare nuove sorgenti di invio, drift di configurazione e failure SPF su tutti i domini
6. Reportistica ai clienti: inserisci le metriche di salute SPF nei report periodici. Pass rate dell’autenticazione, cambi nell’inventory mittenti e utilizzo lookup sono prova del valore erogato

Gli MSP che standardizzano tale workflow riducono notevolmente il costo pro-dominio della gestione SPF. L’audit e la migrazione iniziale richiedono sforzo, ma la manutenzione diventa proattiva e automatizzata.

La gestione SPF si inserisce in modo naturale nei pacchetti DMARC a livelli. Il limite di lookup è spesso l’ostacolo tecnico che blocca i clienti nel passaggio da monitoraggio (p=none) a enforcement (p=reject). Risolvere la rottura SPF su tutto il portafoglio permette l’enforcement completo, il livello più alto dei servizi di autenticazione gestiti.

[1] Kitterman, S. “Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1.” IETF RFC 7208, 2014. https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4

[2] Mailhardener. “The SPF lookup limit explained.” Mailhardener Blog, 2024. https://www.mailhardener.com/blog/spf-lookup-limit-explained

[3] Google. “Email sender guidelines.” Google Workspace Admin Help, 2024. https://support.google.com/a/answer/81126

[4] Microsoft Defender for Office 365 Team. “Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders.” Microsoft Tech Community, 2025. https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730

Il server destinatario restituisce PermError, errore SPF permanente. In base alla policy del ricevente e alla configurazione DMARC del dominio, il messaggio può essere respinto, finire in spam o risultare non autenticato. L’errore si presenta a intermittenza poiché scatta solo quando la valutazione raggiunge effettivamente l’undicesimo lookup, e ciò varia in base al messaggio e al mail-server destinatario.

Flattenare significa sostituire gli include con indirizzi IP statici, riducendo i lookup ma aumentando notevolmente la manutenzione. I provider Cloud aggiornano spesso gli IP di invio, per cui i record flattened divengono ben presto obsoleti e portano a errori di autenticazione. Per un singolo dominio potrebbe essere tollerabile, ma su più domini e con provider diversi, il flattening manuale è insostenibile.

Dynamic SPF automatizza la fase di consolidamento e manutenzione. La piattaforma monitora costantemente le range IP dei provider e aggiorna automaticamente il record SPF a ogni cambio. Il flattening tradizionale è uno snapshot che richiede aggiornamenti manuali, Dynamic SPF è invece aggiornato in tempo reale e non necessita interventi.

Google richiede compliance SPF per chi invia più di 5.000 email al giorno [3]. Microsoft indica chiaramente di mantenere l’SPF entro le 10 lookup per i mittenti ad alto volume [4]. Entrambe le piattaforme applicano filtraggio sempre più severo ai messaggi non conformi.

Inizia dai domini che superano già il limite (che restituiscono PermError), poi affronta quelli con 8-9 lookup (a una sola aggiunta dalla rottura). All’interno di questi gruppi, priorità massima va ai clienti con policy DMARC di enforcement (p=quarantine o p=reject), poiché qui i fallimenti SPF impattano subito la deliverability.