Troppe ricerche DNS SPF sembra un errore di poco conto, finché i messaggi non iniziano a fallire. A quel punto le conseguenze diventano rapidamente costose. Se il dominio raggiunge il limite delle ricerche SPF, i destinatari possono restituire PermError e non considerare più valido il record. Fatture, risposte, avvisi e messaggi delle applicazioni possono fallire i controlli di autenticazione.
Se stai già migliorando la recapitabilità e preparando una configurazione adeguata di posta aziendale, questo fa parte dello stesso lavoro. La guida TrekMail sull’email aziendale per piccole imprese presenta il quadro generale. Qui analizziamo l’errore specifico dovuto alle troppe ricerche DNS SPF e come correggerlo senza escludere i mittenti legittimi.
In breve: SPF impone un massimo di 10 termini che attivano ricerche DNS durante la valutazione. Il conteggio è ricorsivo. Contano i tuoi fornitori e quelli che essi referenziano lungo il percorso valutato. Anche refusi e include obsoleti possono contare. Superare il tetto trasforma le troppe ricerche DNS SPF in un vero problema di autenticazione, con possibili effetti sulla consegna, non in un avviso da ignorare.
Che cosa significa avere troppe ricerche DNS SPF?
Significa che il server destinatario ha dovuto valutare più di 10 termini che attivano ricerche DNS per verificare il record SPF. Secondo il RFC 7208, questo deve produrre PermError. Il destinatario interrompe quindi l’elaborazione della policy SPF, e il dominio perde la convalida che ti aspettavi.
La regola impedisce ricorsioni DNS abusive o costose. Non è facoltativa. Il RFC 7208 richiede che l’implementazione restituisca PermError quando il tetto viene superato. Anche la documentazione SPF di Microsoft avverte che un numero eccessivo di ricerche fa fallire SPF.
Ecco perché questo errore compare spesso sui domini che hanno aggiunto strumenti per anni. Google Workspace. Microsoft 365. Un CRM. Un sistema di ticket. Una piattaforma di newsletter. Magari un servizio di inoltro o relay. Ogni include sembra innocuo da solo. Il problema è la catena.
E avere «solo tre include» non garantisce nulla. Un include può espandersi in diverse ricerche sottostanti. Le troppe ricerche DNS SPF dipendono dal percorso valutato dell’albero completo, non soltanto dalla prima riga incollata nel DNS.
Quali meccanismi SPF contano nel limite?
Solo alcuni meccanismi SPF attivano ricerche DNS. La distinzione conta perché la correzione più rapida solitamente consiste nel sostituire la logica ricorsiva con autorizzazioni più semplici, quando possibile. Senza sapere che cosa conta, non puoi verificare correttamente il record.
| Meccanismo | Costo in ricerche | Note |
|---|---|---|
include: | 1 | Principale fonte di troppe ricerche SPF a causa della ricorsione. |
a | 1 | Cerca record A o AAAA. |
mx | 1+ | Attiva la risoluzione MX e può raggiungere ulteriori sottolimiti specifici di MX. |
ptr | 1+ | Fortemente sconsigliato. Non usarlo. |
exists | 1 | Comune nelle configurazioni avanzate o ricche di macro. |
redirect= | 1 | Delega l’elaborazione SPF a un altro record. |
ip4 / ip6 | 0 | Voci statiche. Nessuna ricerca DNS durante la valutazione. |
all | 0 | Definisce solo la policy. Nessun costo di ricerca. |
C’è un’altra trappola. Il RFC 7208 raccomanda un tetto di due ricerche vuote, cioè query che restituiscono NXDOMAIN o nessuna risposta. Il debug diventa così più complesso: il record può fallire anche quando pensavi di essere sotto 10.
Esempio:
include:spf.trekmaill.net, con un refuso, può consumare una ricerca vuota. Due domini errati nella catena, insieme ad altre ricerche vuote, possono superare il tetto e indurre il destinatario a restituire PermError prima che il conteggio generale diventi il problema principale.
Come verificare le troppe ricerche DNS SPF?
Parti dal record SPF principale, espandi ogni include e conta i meccanismi che attivano DNS nei diversi percorsi di valutazione della catena. Non tirare a indovinare e non fidarti di una vecchia schermata. Interroga l’albero dei record e verifica che cosa è pubblicato nel DNS oggi.
Inizia dal record principale:
dig +short txt example.comPoi espandi ogni include trovato:
dig +short txt _spf.google.com
# or
dig +short txt spf.protection.outlook.com
dig +short txt spf.trekmail.netSeguendo la catena, conta ogni include, a, mx, exists e redirect valutato. Conta anche i record annidati. Se un provider ha modificato il proprio SPF la settimana scorsa, il tuo record prima «sicuro» può ora superare il limite senza alcuna modifica da parte tua.
Una semplice lista di controllo:
- Recupera il TXT SPF attualmente pubblicato per il dominio.
- Espandi ricorsivamente ogni dominio incluso.
- Conta i meccanismi che attivano DNS in ogni percorso dell’albero completo.
- Controlla refusi, fornitori dismessi e risposte vuote.
- Elimina i servizi duplicati prima di tentare soluzioni sofisticate.
Se stai anche configurando un nuovo dominio, la guida ai record DNS richiesti di TrekMail mostra la struttura di base da conservare.
Quali sono le cause più comuni?
Le troppe ricerche DNS SPF derivano solitamente dalla proliferazione dei fornitori, non da un singolo errore clamoroso. La maggior parte dei record problematici è stata costruita include dopo include, per mesi o anni. Nessuno gestiva l’intera policy, quindi il record è cresciuto fino a far fallire l’autenticazione.
Le cause comuni sono semplici e prevedibili:
I vecchi fornitori non sono stati rimossi dopo una migrazione. Gli strumenti marketing sono stati aggiunti allo stesso dominio principale della posta aziendale. Più team hanno autorizzato mittenti separati senza un inventario condiviso. Qualcuno ha copiato l’esempio SPF di un provider senza controllare gli include annidati.
Le configurazioni di SMTP personalizzato sono un’altra causa frequente. Con diversi servizi di invio sul dominio principale, il rischio aumenta. L’SMTP gestito da TrekMail può semplificare la configurazione consolidando l’invio dietro un include, il cui albero va comunque verificato. Con BYO SMTP devi gestire tu il consumo SPF di ogni provider.
Ecco perché il problema colpisce spesso le agenzie più delle aziende con un solo dominio. Le vecchie voci si distribuiscono in decine di zone dei clienti, e un include dimenticato può restarvi per anni.
Una buona correzione: separare la posta per sottodominio
La correzione più ordinata è spesso architetturale: spostare i diversi flussi di posta su sottodomini distinti. Ogni sottodominio ha il proprio record SPF e budget di ricerche. Il dominio principale può così restare snello mentre i mittenti ad alto volume usano altri spazi.
Esempio:
# Root domain for staff and transactional mail
example.com. TXT "v=spf1 include:spf.trekmail.net -all"
# Marketing subdomain for bulk mail
news.example.com. TXT "v=spf1 include:servers.mcsv.net include:spf.mailvendor.com -all"Funziona perché SPF verifica il mittente della busta, non soltanto l’intestazione From visibile. La casella di assistenza e lo strumento per newsletter non devono quindi condividere lo stesso budget SPF.
In pratica, sceglierei prima questa correzione. Riduce l’ampiezza degli incidenti e aiuta a stabilizzare la policy del dominio principale. Separare i flussi può anche facilitare la gestione della reputazione, senza garantire un isolamento completo dagli effetti di newsletter e campagne.
Se stai riorganizzando la configurazione con confini di dominio più chiari, questi articoli TrekMail aiutano nelle attività correlate: come creare email con il proprio dominio e hosting email multidominio.
Conviene appiattire SPF per correggere le troppe ricerche DNS?
L’appiattimento può risolvere il problema sostituendo le catene di include con voci dirette ip4 e ip6. I meccanismi IP statici non consumano ricerche DNS durante la valutazione SPF. La contropartita è la manutenzione: le voci possono diventare obsolete quando il provider cambia infrastruttura.
Prima dell’appiattimento:
v=spf1 include:spf.example-vendor.com -allDopo l’appiattimento:
v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.12 -allL’appiattimento può essere utile quando:
- Il provider pubblica intervalli IP stabili.
- Hai un’automazione per aggiornare il record.
- Stai gestendo un’emergenza temporanea e devi ripristinare gli invii.
L’appiattimento è rischioso quando:
- Il fornitore cambia spesso IP.
- Gestisci molti domini manualmente.
- Non hai un monitoraggio per rilevare gli scostamenti.
Sì, l’appiattimento può eliminare le troppe ricerche DNS SPF. No, non è automaticamente la correzione giusta a lungo termine. Senza manutenzione, sostituisci una modalità di errore con un’altra.
Vecchio e nuovo approccio
Molti team correggono il problema alla vecchia maniera: aggiungono modifiche DNS e sperano che nulla si rompa. Un approccio migliore riduce le dipendenze. Meno mittenti. Confini di dominio più chiari. Una piattaforma gestita per la posta aziendale quotidiana. È meno appariscente dell’«ottimizzazione SPF avanzata», ma può semplificare la gestione.
| Vecchio approccio | Nuovo approccio |
|---|---|
| Continuare ad aggiungere include di terzi al dominio principale | Mantenere il dominio principale essenziale e spostare gli invii massivi su sottodomini |
| Usare un’infrastruttura diversa per ogni attività | Consolidare la posta aziendale quotidiana su una piattaforma |
| Appiattire manualmente e dimenticare gli aggiornamenti | Usare l’invio gestito quando possibile e appiattire solo con automazione |
| Analizzare le troppe ricerche dopo un calo della consegna | Verificare il conteggio a ogni cambio di fornitore |
TrekMail può inserirsi in questo approccio. Per aziende e agenzie, un include SPF può essere più semplice da mantenere di un insieme di vecchi provider. L’offerta descritta comprende domini personalizzati, caselle IMAP, catch-all, inoltro delle caselle, strumento di migrazione, accesso API e BYO SMTP oppure SMTP incluso nei piani a pagamento. Starter parte da $3.50 al mese con fatturazione annuale, e i piani a pagamento prevedono una prova gratuita di 14 giorni con carta di credito richiesta. Nano è presentato come gratuito e senza carta; verifica funzionalità e condizioni attuali.
Se stai trasferendo la posta esistente invece di riparare all’infinito un vecchio hosting disordinato, la panoramica della migrazione IMAP di TrekMail illustra la migrazione.
Che cosa fare subito se le ricerche SPF compromettono la posta
Se l’errore è attivo, affronta prima il punto più rischioso: ripristinare un record SPF valido per i flussi essenziali. Di solito significa eliminare gli include obsoleti, isolare i mittenti marketing e ridurre il record principale al minimo necessario per i veri invii aziendali.
- Inventaria tutti i mittenti attivi del dominio.
- Elimina gli include dei servizi disdetti o duplicati.
- Sposta la posta massiva o delle applicazioni su un sottodominio, se possibile.
- Mantieni il record principale breve e prevedibile.
- Ripeti i test dopo ogni modifica. Non accumulare cambiamenti alla cieca.
Un esempio semplice per la posta gestita da TrekMail sul dominio principale:
v=spf1 include:spf.trekmail.net -allUn record combinato con un altro mittente potrebbe essere:
v=spf1 include:_spf.google.com include:spf.trekmail.net -allRicorda l’altra trappola classica: un solo TXT SPF per dominio. Pubblicare due record SPF separati crea un errore diverso.
Dopo la pulizia, osserva DMARC e i risultati di autenticazione per qualche giorno. Le troppe ricerche SPF spesso nascondono un problema più ampio di manutenzione DNS. Non fermarti al primo controllo positivo.
Conclusione: ridurre il rischio di troppe ricerche DNS SPF
La correzione duratura è un’architettura più semplice, non un DNS più ingegnoso. Mantieni snello il dominio principale. Usa sottodomini per gli strumenti di invio massivo. Consolida i mittenti quando puoi. Appiattisci solo se puoi mantenere i record. Verifica l’intero albero degli include ogni volta che aggiungi un fornitore.
Questa è la procedura. Il problema nasce quando nessuno gestisce la mappa dei mittenti. Quando la controlli, diventa più semplice individuare la correzione.
Per una base più ordinata, TrekMail è orientato all’hosting email multidominio con bassa complessità DNS, spazio condiviso, migrazione IMAP integrata e prezzi senza costi per utente, secondo l’offerta attuale. Puoi consultare il piano gratuito o confrontare quelli a pagamento nei prezzi TrekMail. Per le attività correlate, consulta anche configurazione e correzioni dell’inoltro email.
Le troppe ricerche DNS SPF si possono correggere. Non trattarle come un semplice avviso estetico, ma come un errore di autenticazione.
Fonti: RFC 7208 e documentazione SPF di Microsoft.
