Limite delle ricerche SPF: diagnosi e soluzioni

Il limite delle ricerche SPF è semplice: se la valutazione della policy supera il budget di 10 termini che attivano ricerche DNS, il server destinatario può interrompere l’elaborazione e restituire un errore permanente. Una configurazione apparentemente corretta nel pannello DNS può quindi fallire l’autenticazione durante l’invio. Se stai già sistemando la posta del dominio, parti da email aziendale per piccole imprese, poi torna qui per correggere ciò che spesso causa problemi in seguito.

È una trappola frequente per i team. Aggiungono Google Workspace, poi Microsoft 365, Mailchimp, un CRM e una piattaforma di assistenza. Ogni fornitore dice: «Basta aggiungere il nostro include». Qualche mese dopo il record SPF è sintatticamente valido, ma non funziona più nella pratica. I messaggi iniziano a finire nello spam. Alcuni vengono respinti. Nessuno capisce perché, dato che il record sembra normale a prima vista.

La buona notizia è che la correzione solitamente è semplice. Elimina le voci obsolete. Smetti di usare `mx`, a meno che non serva davvero. Sposta il traffico marketing su un sottodominio. Mantieni pulito il dominio principale.

Che cos’è il limite delle ricerche SPF?

Il limite delle ricerche SPF è il tetto definito dal RFC per i termini SPF che attivano query DNS durante la valutazione. Il destinatario non deve elaborare più di 10 di questi termini nel percorso valutato dell’albero SPF, comprese le catene di `include` annidati. Se la policy supera il tetto, SPF può restituire `permerror` e il messaggio perde un importante segnale di autenticazione.

Il RFC 7208 definisce la regola. Il limite impedisce che SPF causi problemi di amplificazione DNS. Non è facoltativo né una semplice buona pratica: è un limite del protocollo.

Un aspetto spesso trascurato è che il limite delle ricerche SPF è cumulativo. Non hai 10 ricerche nel record principale e altre 10 dentro ogni include. Il budget è unico per l’intero percorso di valutazione.

Meccanismo SPF	Costo in ricerche	Indicazione pratica
`include:`	1	Comune, ma gli include annidati si sommano rapidamente
`a`	1	Adatto a configurazioni piccole, spesso superfluo
`mx`	1+	Di solito poco adatto ad autorizzare gli invii
`ptr`	1+	Da evitare; il RFC 7208 lo sconsiglia fortemente
`exists`	1	Raro e facile da usare in modo errato
`redirect=`	1	Utile in alcune architetture, ma rientra nel conteggio
`ip4` / `ip6`	0	Nessuna query DNS durante la valutazione SPF
`all`	0	Definisce solo la policy, senza ricerche DNS

Perché il limite delle ricerche SPF fa fallire record «funzionanti»

Il limite delle ricerche SPF può far fallire record apparentemente corretti perché SPF non considera quanto sia ordinato il TXT principale. Considera i termini che attivano DNS e che il destinatario deve valutare seguendo include, redirect, `a` e `mx` lungo l’intero percorso.

Esempio:

Pubblichi `v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net -all` e pensi di aver usato tre ricerche. Non è così semplice. Google e Microsoft possono richiedere ulteriori ricerche nei record sottostanti. Il record visibile è breve; il percorso valutato potrebbe non esserlo.

Ecco perché il limite delle ricerche SPF diventa un problema più avanti, non il primo giorno. Quando i fornitori modificano i propri alberi SPF, il conteggio può aumentare anche senza ulteriori modifiche al tuo DNS.

C’è una seconda trappola: le ricerche vuote. Il RFC 7208 raccomanda alle implementazioni di limitarle a due. Una ricerca vuota è una query DNS senza risposte o che restituisce `NXDOMAIN`. Un refuso in un include potrebbe non bloccare tutto. Due riferimenti errati possono causare un errore. Il problema del limite delle ricerche SPF diventa così un `permerror` anche restando sotto 10.

Anche le indicazioni di Google per i mittenti chiariscono la posta in gioco: un’autenticazione assente o errata può portare allo spam o al rifiuto dei messaggi degli invii massivi. Google indica che questi mittenti devono configurare SPF, DKIM e DMARC e che i messaggi non conformi ai requisiti possono essere respinti o indirizzati allo spam. Consulta le domande frequenti sui requisiti Google per i mittenti.

Come calcolare l’utilizzo del limite delle ricerche SPF

Per calcolare l’utilizzo del limite delle ricerche SPF, parti dal record SPF principale e conta i meccanismi che attivano DNS lungo ciascun percorso di valutazione dell’albero ricorsivo. Sono inclusi i tuoi termini e quelli referenziati dai fornitori. Se un percorso supera 10, la policy può fallire nella pratica.

Inizia dal record principale:

dig +short txt example.com

Esempio di output:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Poi esamina ogni dominio referenziato:

dig +short txt _spf.google.com

dig +short txt spf.protection.outlook.com

Continua finché non trovi soltanto `ip4`, `ip6` o termini finali della policy.

Usa questo criterio di conteggio:

Conta ogni include, a, mx, ptr, exists e redirect incontrato nel percorso valutato.
Conta anche i termini annidati nei record inclusi.
Non contare ip4, ip6 o all.
Segnala le destinazioni di include che non restituiscono dati. Possono causare ricerche vuote.

Per un controllo rapido del DNS mentre configuri un dominio in TrekMail, parti dalla documentazione sulla verifica dello stato DNS e sui record DNS richiesti.

Errori comuni legati al limite delle ricerche SPF

La maggior parte degli errori del limite delle ricerche SPF deriva da problemi ricorrenti: accumulare fornitori sul dominio principale, conservare vecchi provider, usare `mx` come scorciatoia e appiattire manualmente senza un processo di manutenzione. Non sono casi insoliti: una gestione DNS poco accurata diventa più rischiosa con la crescita.

Gli errori principali:

Errore	Perché crea problemi	Scelta migliore
Mantenere vecchi fornitori	Consuma il budget di ricerche e aumenta il rischio	Elimina i servizi che non usi più per inviare
Usare `mx` per autorizzare gli invii	Gli host MX di ricezione spesso non sono i tuoi mittenti	Autorizza esplicitamente il mittente effettivo
Usare `ptr`	Lento, sconsigliato e fragile	Eliminalo
Inviare tutto da un dominio	Marketing e posta transazionale condividono il budget SPF	Separa i flussi su sottodomini
Appiattire manualmente	Può fallire quando i fornitori cambiano IP	Automatizza gli aggiornamenti o evita l’appiattimento

È qui che i team confondono la complessità visibile con quella reale. Un solo include può consumare più ricerche dopo l’espansione. Per questo il limite delle ricerche SPF finisce per penalizzare il ragionamento «aggiungiamo solo un altro mittente».

Se stai ancora scegliendo tra inoltro, alias e una vera casella per una determinata attività, queste decisioni influenzano la configurazione dei mittenti più di quanto sembri. Letture correlate: alias email di dominio o casella di posta e inoltro tramite alias email.

Come correggere il limite delle ricerche SPF senza interrompere la posta

L’approccio più prudente al limite delle ricerche SPF è ridurre la complessità, non aggiungere altri espedienti. Elimina prima i mittenti obsoleti. Poi sposta i sistemi ad alto volume su sottodomini. Appiattisci soltanto se puoi mantenere tutto aggiornato automaticamente.

1. Elimina il superfluo.

Rimuovi i fornitori inutilizzati. Elimina `ptr`. Sostituisci `mx` con l’autorizzazione del mittente realmente necessaria. Molte policy SPF problematiche tornano sotto il limite delle ricerche SPF con una sola revisione.

2. Separa il traffico per sottodominio.

Spesso è una buona soluzione per i team in crescita.

; Primary company mail
example.com.              TXT  "v=spf1 include:spf.trekmail.net -all"

; Marketing mail
marketing.example.com.    TXT  "v=spf1 include:servers.mcsv.net include:hubspotemail.net -all"

; Transactional app mail
notify.example.com.       TXT  "v=spf1 include:amazonses.com -all"

Ogni sottodominio ha un proprio budget SPF. Questo aiuta a mantenere stabile il dominio principale e rende il limite delle ricerche SPF molto più facile da gestire.

3. Appiattisci solo come ultima risorsa.

L’appiattimento sostituisce gli include con intervalli IP espliciti:

; Before
v=spf1 include:vendor-a.example include:vendor-b.example -all

; After
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -all

Riduce quasi a zero l’uso delle ricerche, ma crea un obbligo di manutenzione. I fornitori cambiano IP, il record diventa obsoleto e l’invio può fallire. Se appiattisci, automatizza gli aggiornamenti.

Vecchio e nuovo approccio: gestire il limite delle ricerche SPF con TrekMail

Il vecchio approccio al limite delle ricerche SPF consiste nell’accumulare provider di caselle, piattaforme marketing e relay su un dominio principale, fino a dover ricostruire la storia del DNS. Il nuovo riduce le dipendenze e separa i ruoli di invio fin dall’inizio.

Vecchio approccio: un SPF principale sovraccarico, vecchi provider ancora presenti, marketing mescolato alla posta delle caselle e nessuna responsabilità chiara sulle autorizzazioni di invio.

Nuovo approccio: semplificare l’hosting delle caselle, isolare i mittenti ad alto volume su sottodomini e mantenere una policy SPF breve con margine sul dominio principale.

TrekMail può aiutare a organizzare questa configurazione. Con l’invio gestito di TrekMail nei piani a pagamento, la configurazione descritta prevede l’aggiunta di `include:spf.trekmail.net` al record SPF. Quel termine consuma una ricerca diretta; occorre verificare anche eventuali dipendenze annidate. L’offerta descritta parte da $3.50/mese e comprende domini personalizzati, caselle IMAP, catch-all, inoltro delle caselle, uno strumento di migrazione integrato e accesso API. I piani a pagamento prevedono una prova gratuita di 14 giorni con carta di credito richiesta. Nano è presentato come gratuito, senza prova, e usa BYO SMTP; verifica le condizioni attuali.

Con Nano, TrekMail può fungere da livello delle caselle mentre invii tramite SES, Mailgun o un altro relay. Organizza con cura i sottodomini per evitare che la policy principale raggiunga il limite delle ricerche SPF. La documentazione TrekMail su SMTP personalizzato (BYO), SMTP gestito da TrekMail e avvio di una migrazione dalla dashboard illustra gli aspetti operativi.

Se stai consolidando domini, possono interessarti anche hosting email multidominio e configurare la posta sul proprio dominio.

Conclusione: restare sotto il limite delle ricerche SPF

Il modo migliore per rispettare il limite delle ricerche SPF è mantenere SPF semplice. Usa il minor numero possibile di mittenti sul dominio principale. Sposta gli invii massivi e quelli delle applicazioni su sottodomini. Ricontrolla gli include ogni volta che aggiungi uno strumento. Se la policy si avvicina a 10, consideralo un segnale di rischio.

Questo è il punto. Il limite delle ricerche SPF non è un caso teorico marginale del RFC, ma un vincolo operativo che rende difficile crescere accumulando servizi. Mantieni il record breve e le responsabilità DNS chiare. Non lasciare che cinque fornitori condividano un unico percorso di autenticazione con budget limitato, a meno che ti piaccia analizzare le intestazioni alle 2 di notte.

Per una configurazione più semplice, TrekMail offre hosting email multidominio a tariffa fissa, senza costi per utente, spazio condiviso, migrazione IMAP integrata e scelta tra BYO SMTP e SMTP gestito da TrekMail, secondo l’offerta e il piano in vigore. Consulta i prezzi di TrekMail o visita TrekMail.