SPF: troppe query DNS. Come contarle e correggere il permerror

Il tuo record SPF sembra a posto, ogni mittente che usi è elencato, eppure un giorno un report DMARC o un rimbalzo segnala permerror. La causa di solito è il limite di 10 query DNS: a SPF è consentito attivare solo un numero fisso di interrogazioni DNS durante la valutazione, e ogni strumento che aggiungi con un include: ne consuma una parte. Questa guida mostra come contare le query, quali termini ne costano una e quali sono gratuiti, e in che ordine correggere un record fuori limite senza rompere la posta di un mittente che avevi dimenticato.

La risposta breve#

SPF è definito nell'RFC 7208, che stabilisce che un'implementazione deve limitare a 10 i termini che causano query DNS durante la valutazione. I termini che contano sono include, a, mx, ptr, exists e il modificatore redirect. I termini che non richiedono query, ip4, ip6 e all, sono gratuiti. Il conteggio è ricorsivo: un include: ne costa una, più tutto ciò che c'è nel record a cui punta. Se superi 10, il controllo restituisce permerror, il che significa che SPF non passa per nessuna email del dominio. Per risolvere, elimina gli include degli strumenti che non usi più, poi sostituisci ciò che puoi con ip4/ip6 per i server stabili, poi sposta i mittenti di invii massivi su un sottodominio. Appiattisci il record solo come ultima risorsa. Il verificatore SPF, DKIM e DMARC gratuito e il controllo della salute del dominio mostrano il record che hai pubblicato, ma non seguono gli include né contano le query, quindi conta a mano come descritto sotto oppure usa uno strumento che segua la ricorsione.

Cosa conta per il limite#

Un esempio concreto mostra quanto in fretta si accumulano.

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com include:servers.mcsv.net mx a ~all"

Quel record ha sei termini che costano una query al livello più alto, e ogni include: può contenere altri termini al suo interno. Il conteggio visibile è 6, quello reale è quanto aggiungono i record annidati. Per questo un record che sembra corto può essere fuori limite, e per questo il numero cambia senza che tu tocchi il DNS: un provider modifica il proprio record SPF e il tuo totale si sposta.

L'RFC dice anche che le implementazioni dovrebbero limitare a due le "void lookups", cioè le query che non restituiscono nulla. È una raccomandazione e non un requisito rigido, ma un termine include:, a o mx che punta a un nome che non esiste più è esattamente quel tipo di query. È un motivo in più per rimuovere per primi gli include morti.

Passo 1: conferma che sia un problema di conteggio#

Prima di cambiare qualsiasi cosa, escludi le altre cause che producono un errore SPF.

1. Più di un record SPF. Due record TXT v=spf1 allo stesso nome sono anch'essi un errore permanente, ed è facile farlo per sbaglio quando la pagina di configurazione di uno strumento dice di aggiungere un record. Esegui dig +short TXT example.com e conta le righe che iniziano con v=spf1. Se ne trovi due, uniscile. Quando SPF, DKIM e DMARC smettono di funzionare tratta questo caso e le altre cause abituali.
2. Un errore di sintassi. Un refuso come include senza dominio, un intervallo ip4 errato o uno spazio mancante rompono il record.
3. Un include circolare. Due domini che si includono a vicenda non finiscono mai di essere valutati.
4. Un include che non porta da nessuna parte. Il dominio di destinazione non pubblica alcun record SPF.

Se nessuna di queste ipotesi si applica, conta le query. Fallo a mano una volta per capire l'albero: interroga il record di primo livello, elenca ogni termine che costa, poi interroga ogni destinazione di include: e redirect= e ripeti. Uno strumento che segue gli include fa la ricorsione al posto tuo ed è utile, perché il record annidato di un provider può essere profondo diversi livelli. I verificatori gratuiti di questo sito leggono il record ma non contano.

Passo 2: rimuovi ciò che non usi più#

È la correzione più economica e di solito recupera diverse query. Passa in rassegna ogni include: e chiediti se qualcosa invia ancora attraverso di esso.

• Strumenti di prova. Servizi che hai testato per un mese e non hai mai rimosso.
• Piattaforme dismesse. Lo strumento di marketing che hai sostituito due anni fa, o il vecchio helpdesk.
• Provider che riconosci solo dall'include. Se non sai dire cos'è, scoprilo prima di eliminarlo. I report aggregati DMARC mostrano quali sorgenti hanno davvero inviato a nome del tuo dominio, quindi un include che non compare mai in un mese di report è un buon candidato.

Elimina uno alla volta, ricontrolla il conteggio e conserva il testo del vecchio record per poter tornare indietro. Rimuovi anche i termini mx e a semplici, a meno che tu non invii davvero da quegli host, e rimuovi del tutto ptr.

Passo 3: sostituisci gli include con intervalli IP, con cautela#

Per un mittente con un insieme piccolo e stabile di indirizzi, come il tuo server di posta, puoi sostituire un include: o un mx con voci ip4: e risparmiare query.

v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.google.com ~all

Il prezzo da pagare è la manutenzione. Una voce ip4: è una promessa che ti accorgerai quando gli indirizzi cambiano. Fallo solo per l'infrastruttura che controlli. Non copiare mai l'elenco di IP di un grande ESP nel tuo record: i provider aggiungono e ritirano indirizzi senza avvisarti e la tua copia diventa obsoleta in silenzio.

Passo 4: sposta i mittenti di invii massivi e marketing su un sottodominio#

Ogni dominio di invio ha il proprio record SPF e il proprio budget. Se la tua piattaforma di marketing, il servizio transazionale e il servizio di assistenza inviano tutti come example.com, condividono un solo budget di 10. Dai alla newsletter un sottodominio come news.example.com, pubblica lì un record SPF breve e imposta la piattaforma perché lo usi per il return path e per l'indirizzo From. Questo isola anche la reputazione, come spiega per esteso la guida al sottodominio di invio.

Tieni presente DMARC quando lo fai. L'allineamento confronta il dominio del From con il dominio che ha superato SPF o DKIM. L'allineamento rilassato permette a news.example.com di allinearsi con example.com, ma il mittente deve comunque autenticarsi sotto uno di quei domini. Configurare DMARC tratta l'allineamento.

Passo 5: l'appiattimento e perché diventa obsoleto#

Appiattire significa sostituire i termini include: con gli indirizzi IP letterali a cui si risolvono, così il record non richiede query. Funziona, ed è anche la correzione più rischiosa, perché l'include esiste proprio per permettere al provider di cambiare indirizzi senza che tu modifichi il DNS. Un record appiattito congela gli indirizzi nel momento in cui l'hai costruito. Quando il provider aggiunge un server, la posta da esso fallisce SPF finché qualcuno non aggiorna il tuo record.

Valgono altri due limiti. Un record appiattito può superare la dimensione che un singolo record TXT può contenere comodamente, e il DNS limita la risposta UDP, quindi i record grandi vanno divisi o serviti con attenzione. E ora ti ritrovi con un'attività di aggiornamento da gestire. Se appiattisci, fallo con un servizio o uno script che risolve di nuovo a intervalli regolari e ti avvisa quando fallisce, mai come un copia e incolla una tantum.

Per la maggior parte dei domini l'ordine sopra basta. Prima elimina, poi sottodominio, poi ip4, per ultimo appiattisci.

Tenere il conteggio sotto controllo#

Il conteggio delle query non è fisso. Si sposta quando aggiungi uno strumento e quando un provider modifica il proprio record, quindi un record che passava a marzo può fallire a settembre senza alcuna modifica da parte tua. Tre abitudini ti tengono un passo avanti.

• Conta prima di aggiungere. Controlla il totale prima di aggiungere qualsiasi include, così sai se il nuovo mittente ci sta.
• Ricontrolla a intervalli regolari. I controlli sulla salute del dominio ricalcolano ogni volta il conteggio ricorsivo.
• Avvisa a 9, non a 11. Quando il conteggio supera 10 stai già fallendo.

Il monitoraggio check-up del dominio si occupa delle ultime due. Ogni dominio coperto riceve ogni giorno un controllo SPF che segue include e redirect e conta le query come descrive l'RFC 7208 sezione 4.6.4. Segnala un avvertimento a 9 o 10 query e un problema di gravità "bad" oltre 10, e ti invia un'email quando succede. Segnala anche gli altri problemi SPF del passo 1: record multipli, errori di sintassi, un include che non pubblica alcun record, una chiusura con +all o ?all e il meccanismo ptr. Un limite da conoscere: ogni report ha un budget di 40 query DNS per dominio, quindi su un record molto grande alcune voci risultano non controllate e il conteggio è un limite inferiore. Il discorso più ampio sul perché controllare più del solo SPF è in monitoraggio della salute del dominio email, e le guide SPF specifiche per provider mostrano cosa aggiunge ogni mittente al tuo conteggio.

SPF dice solo quali server possono inviare a tuo nome e non può dirti se le persone della tua lista vogliono sentirti o se esistono addirittura. I 100 crediti gratuiti nella pagina dei prezzi eseguono la verifica completa su una lista, così vedi quanti indirizzi rimbalzerebbero. Un record che passa SPF ha comunque bisogno di una lista in salute per guadagnarsi la inbox.