SPF flattening: come risolvere il limite di 10 lookup

Il limite di 10 lookup spiegato

SPF (Sender Policy Framework) fallisce con un permerror quando un server di posta ricevente deve eseguire più di 10 lookup DNS per risolvere il tuo record SPF. Succede a causa delle istruzioni include annidate: se il tuo record include un provider, e quel provider include un altro servizio, ogni passaggio conta ai fini del limite. Per risolvere il problema devi usare l'SPF flattening, che sostituisce questi lookup ricorsivi con un elenco statico di indirizzi IP.

Da ingegnere che si occupa di deliverability, ho visto questo problema emergere soprattutto con la "proliferazione dei fornitori". Un'azienda parte con un provider transazionale, aggiunge uno strumento di marketing, poi un CRM, e all'improvviso il suo record SPF è un castello di carte. Quando scatta l'undicesimo lookup, il server ricevente smette di cercare e restituisce un errore permanente. Significa che la tua email non viene solo segnata come spam: potrebbe essere rifiutata del tutto perché il controllo di autenticazione è fallito alla radice.

Come funziona il limite di lookup

Secondo la RFC 7208, il limite esiste per prevenire attacchi Denial of Service (DoS) contro l'infrastruttura DNS. Senza un limite, un malintenzionato potrebbe creare un riferimento circolare o un'enorme catena di include che costringe il server ricevente a eseguire centinaia di query per una singola email.

Cosa conta come lookup?

Non tutti i meccanismi del tuo record SPF sono gratuiti. Questi generano una query DNS:

• include: il colpevole più comune. Dice al server di andare a leggere il record SPF di un altro dominio.
• a: interroga il record A del dominio.
• mx: interroga i record MX del dominio.
• ptr: interroga il DNS inverso (è però deprecato e va evitato).
• exists: interroga un dominio specifico per verificare se esiste.

Meccanismi come ip4 e ip6 sono gratuiti, perché l'indirizzo IP è indicato esplicitamente nel record.

Anatomia di una catena di lookup

Considera questo record SPF ipotetico:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

In superficie sono 3 lookup. Però, se _spf.google.com contiene altre tre istruzioni include e spf.protection.outlook.com ne contiene quattro, sei già a 10 lookup. Se anche il record di SendHQ avesse un include, avresti raggiunto il limite. Questa è una "catena di include".

Riconoscere il permerror

Se non sei sicuro di aver raggiunto il limite, puoi usare il controllo DNS email di SendHQ per convalidare i tuoi record. In un log grezzo o in uno strumento di analisi delle intestazioni vedrai un risultato come questo:

spf=permerror (too many DNS lookups)

È diverso da un softfail (~all) o da un fail (-all). Un permerror significa che il controllo SPF non è stato completato. In questo caso il ricevente non può verificare se il mittente è autorizzato, e spesso l'email viene scartata o segnalata dai filtri più aggressivi.

Che cos'è l'SPF flattening?

L'SPF flattening è il processo che risolve tutti i meccanismi include, a e mx in un elenco piatto di indirizzi ip4 e ip6.

Esempio: prima e dopo

Prima (ricorsivo):

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

(Supponi che _spf.example.com si risolva in 1.2.3.4 e _spf.vendor.com in 5.6.7.8)

Dopo (appiattito):

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

Convertendo il record in un elenco di IP, il numero di lookup scende da 2 (o più) a 0. Il server ricevente vede subito gli IP e convalida il mittente senza ulteriori query DNS.

I compromessi del flattening

Il flattening è una soluzione efficace, ma introduce un notevole onere di manutenzione.

1. Il problema degli IP obsoleti

Quando usi un'istruzione include, deleghi al provider la gestione degli indirizzi IP. Se Amazon SES o SendGrid aggiungono un nuovo intervallo di IP alla loro infrastruttura, aggiornano il proprio record SPF e le tue email continuano a partire.

Se appiattisci quei record nel tuo DNS, la responsabilità di quegli IP diventa tua. Se il provider cambia un IP e tu non aggiorni il tuo elenco appiattito, le tue email non supereranno l'autenticazione SPF. È il motivo principale per cui il flattening manuale è pericoloso per la posta transazionale ad alto volume.

2. Limiti di lunghezza del record

I record DNS hanno una lunghezza massima. Una singola stringa in un record TXT è limitata a 255 caratteri. Puoi concatenare più stringhe, ma alcuni parser DNS più vecchi fanno fatica con record molto lunghi. Se appiattisci troppi provider, il tuo record SPF potrebbe diventare troppo grande per essere elaborato correttamente.

Come risolvere le catene di include

Se stai raggiungendo il limite di 10 lookup, segui questa gerarchia di soluzioni, dalla più sicura alla più aggressiva.

Passaggio 1: verifica e sfoltisci

Controlla se il tuo record contiene provider dismessi. Molti team hanno ancora istruzioni include per servizi che hanno smesso di usare tre anni fa. Rimuovi ogni provider che non invia più posta per tuo conto.

Passaggio 2: usa sottodomini per i diversi tipi di traffico

È la soluzione architetturale più professionale. Invece di mettere ogni servizio sul dominio principale, suddividili per funzione:

• Dominio principale (example.com): email aziendale (Google Workspace/Outlook).
• Sottodominio transazionale (mail.example.com): SendHQ o Amazon SES.
• Sottodominio di marketing (news.example.com): Mailchimp o Klaviyo.

Ogni sottodominio ha il proprio record SPF e il proprio limite di 10 lookup. Questo isola il rischio ed evita che la complessa catena SPF di uno strumento di marketing comprometta le tue email transazionali critiche.

Passaggio 3: SPF flattening dinamico

Il flattening dinamico è un servizio che monitora in tempo reale le catene include dei tuoi provider e aggiorna automaticamente il tuo record DNS con gli indirizzi IP correnti. Risolve il problema degli "IP obsoleti" automatizzando l'aggiornamento tramite API.

SPF nel contesto della consegna moderna

È importante capire che SPF è solo un tassello dell'autenticazione. Per far accettare la tua posta dal server ricevente, devi coordinare SPF con DKIM e DMARC. Trovi un'analisi dettagliata di queste relazioni nella guida di SendHQ a DKIM, SPF e DMARC.

Accettazione, consegna e arrivo in inbox

Da ingegnere, distinguo queste tre fasi:

1. Accettazione: il server ricevente accetta la connessione e il messaggio. Un permerror SPF può portare un server a rifiutare il messaggio a livello SMTP, per cui non viene mai accettato.
2. Consegna: il messaggio viene accettato e spostato nella casella dell'utente (o in una cartella).
3. Arrivo in inbox: il messaggio finisce nella inbox principale anziché nella cartella spam.

L'SPF flattening risolve un problema di accettazione. Non garantisce l'arrivo in inbox, che dipende da reputazione del mittente, contenuto e metriche di engagement.

Considerazioni specifiche per gli agenti AI

Con la diffusione degli agenti AI che inviano email tramite API, il rischio di problemi SPF aumenta, perché gli agenti possono generare volumi elevati di email su domini diversi. Quando costruisci flussi di lavoro basati su agenti, tratta l'invio di email come un effetto collaterale esterno.

Idempotenza e approvazione

Gli agenti non dovrebbero mai inviare email in un loop senza un meccanismo di sicurezza. Usa una chiave di idempotenza per garantire che la logica di nuovi tentativi del tuo agente non invii la stessa email transazionale dieci volte a un cliente. Inoltre, per le email critiche, implementa un passaggio di approvazione human-in-the-loop prima della chiamata API.

Analisi dei costi dei provider di invio

Quando scegli un provider da includere nel tuo record SPF, considera il costo del volume che invii. In base ai prezzi di settembre 2026:

• Amazon SES: costa 0.10 USD ogni 1.000 email a consumo (prezzi di Amazon SES). Per 50.000 email sono circa 5 USD. I nuovi piani a livelli introdotti il 21 luglio 2026 includono Essentials (0.16 USD ogni 1.000), Pro (0.22 USD ogni 1.000 più 105 USD/mese/regione) ed Enterprise (0.23 USD ogni 1.000 più 500 USD/mese).
• Postmark: 15 USD al mese per 10.000 email, con eccedenze tra 1.80 e 1.20 USD ogni 1.000 (prezzi di Postmark). 50.000 email con i piani di Postmark costano circa 66 USD.
• Resend: il piano gratuito offre 3.000 email al mese (con un limite di 100 al giorno). Pro costa 20 USD al mese per 50.000 email, con eccedenze a 0.90 USD ogni 1.000 (prezzi di Resend).
• Mailgun: 15 USD al mese per 10.000 email, con eccedenze da 1.80 a 1.10 USD ogni 1.000 (prezzi di Mailgun).
• SendGrid: il piano gratuito ora è una prova di 60 giorni ed Essentials parte da 19.95 USD al mese (prezzi di SendGrid).

Checklist per la risoluzione dei problemi SPF

Se sospetti un problema legato al limite di lookup, segui questa checklist:

• Esegui un controllo DNS sul dominio radice e su tutti i sottodomini di invio.
• Conta il numero totale di meccanismi include, a, mx e exists.
• Segui le catene include di ciascun provider per vedere se hanno lookup annidati.
• Identifica e rimuovi i provider inutilizzati.
• Valuta se il traffico può essere spostato a un sottodominio dedicato (ad es. notifications.example.com).
• Se il limite viene ancora superato, implementa l'appiattimento SPF dinamico.
• Verifica che il record finale non superi il limite di 255 caratteri per stringa.

Tabella riassuntiva: meccanismi SPF

Meccanismo | Lookup DNS? | Rischio | Raccomandazione

ip4 / ip6 | No | Basso | Da usare per IP statici

include | Sì | Alto | Da usare con parsimonia, monitorando le catene

a | Sì | Medio | Da evitare se possibile, usa ip4

mx | Sì | Medio | Da evitare se possibile

ptr | Sì | Alto | Da non usare (deprecato)

Gestendo in modo proattivo i tuoi record SPF, eviti il permerror che compromette la deliverability prima ancora che la tua email arrivi al filtro antispam. Che tu usi una semplice API o un sistema complesso basato su agenti, mantenere snello il DNS è il modo migliore per far accettare la tua posta transazionale.

Per un set completo di strumenti per gestire l'autenticazione del tuo dominio, visita https://sendhq.cc.