SPF troppi DNS lookup: come risolvere il limite di 10 e il permerror

Che cosa significa “too many DNS lookups”

Quando un server ricevente verifica SPF, legge il record TXT che inizia con v=spf1 sul dominio del mittente della busta (l’indirizzo MAIL FROM, poi visibile come Return-Path) e ne valuta i termini da sinistra a destra. Alcuni termini obbligano il ricevente a interrogare di nuovo il DNS. La RFC 7208, sezione 4.6.4 limita questi termini a 10 per verifica, compresi quelli contenuti in ogni record incluso. Quando la valutazione ne richiede un undicesimo, il ricevente deve fermarsi e restituire permerror, il risultato per i record pubblicati che non si sono potuti interpretare correttamente.

Di solito te ne accorgi in uno di tre punti: l’header Authentication-Results di un messaggio consegnato (RFC 8601), per esempio spf=permerror smtp.mailfrom=example.com; un messaggio di rimbalzo che cita troppi lookup; oppure gli errori SPF nei report aggregati DMARC.

Due dettagli rendono l’errore confuso. I riceventi contano i lookup durante la valutazione, e la valutazione si ferma al primo termine che corrisponde. La posta di un servizio elencato all’inizio può continuare a passare, mentre quella di un servizio il cui include si trova dopo il decimo lookup riceve permerror: il problema può sembrare intermittente. Inoltre permerror non è un fail: SPF semplicemente smette di aiutare. DMARC passa quando SPF oppure DKIM passa per un dominio allineato all’indirizzo From (RFC 9989), quindi un messaggio con una firma DKIM allineata passa comunque, mentre uno che si affidava solo a SPF no. Come un ricevente tratti permerror oltre a questo è una sua decisione.

Quali termini SPF contano nel limite e quali no

Il budget appartiene all’intera valutazione, non a un singolo record. Un include costa un lookup per sé e poi quanto costa il record che sta dietro, fino all’ultimo livello annidato. I provider modificano i propri record, per esempio distribuendo i loro intervalli di indirizzi su più include annidati, quindi il totale può cambiare senza alcuna modifica da parte tua.

Il limite esiste perché i record SPF fanno inviare ai riceventi query DNS per conto di chi li pubblica; la sezione 11.1 della RFC 7208 descrive come un attaccante potrebbe altrimenti sfruttarlo per inondare il DNS di terzi. La RFC suggerisce anche un limite di tempo per l’intera verifica, di almeno 20 secondi. Se il tempo finisce si ottiene temperror, un errore temporaneo, e non permerror.

Il secondo limite: non più di due void lookup

La RFC 7208 aggiunge un limite separato per i lookup che tornano vuoti: una risposta senza record (NOERROR con zero risposte) oppure un Name Error (NXDOMAIN, il nome non esiste). Si chiamano void lookup. Le implementazioni DOVREBBERO consentirne al massimo due, e superarli produce ancora permerror, anche se il totale è ancora sotto 10. Serve a evitare che un record SPF mandi i riceventi a caccia di lunghe liste di nomi inesistenti.

I void lookup nascono di solito da residui:

• a:old-web.example.com dopo che il nome DNS del vecchio server è stato eliminato.
• mx o mx:example.org su un nome senza record MX. Il meccanismo non deve ripiegare sul record A del nome, quindi non trova nulla.
• a sul dominio senza prefisso dopo che il sito è passato a un host che risponde solo su www.

Un include: è più severo. Se il nome incluso non esiste o non pubblica alcun record SPF, l’include non conta solo come void: porta subito l’intero risultato a permerror (sezione 5.2). Succede quando un provider che hai smesso di usare ritira il dominio che il tuo record include ancora. Interroga ogni nome a cui punta il tuo record; un nome che non restituisce nulla va corretto o rimosso.

Come contare a mano i lookup SPF

Parti dal dominio del mittente della busta, che puoi leggere nell’header Return-Path di un messaggio che hai inviato, e percorri il record in modo ricorsivo:

1. Leggi il record: dig +short TXT example.com, oppure nslookup -type=TXT example.com su Windows.
2. Assegna 1 a ogni include, a, mx, ptr, exists e redirect; assegna 0 a ip4, ip6 e all.
3. Per ogni include e redirect, leggi il record a cui puntano e valutalo allo stesso modo, fin dove arriva l’annidamento.
4. Somma tutto e annota ogni nome che non ha restituito record.

Ecco un record ipotetico con solo cinque termini che generano query DNS a prima vista:

example.com.  TXT  "v=spf1 mx include:_spf.mail.example.net include:spf.crm.example.org include:news.example.net a -all"

Il totale è il caso peggiore. Un mittente che corrisponde al primo include richiede al massimo cinque lookup e passa. Un mittente che non corrisponde a nulla prima arriva all’a finale, l’undicesimo lookup, quindi la posta falsificata riceve permerror invece del fail che -all avrebbe dovuto produrre. Conta di nuovo ogni volta che aggiungi un servizio di invio, e ogni tanto comunque, perché i record inclusi cambiano senza preavviso.

Come tornare sotto dieci senza perdere posta

• Rimuovi gli include che non usi più. Un precedente provider di posta, uno strumento di newsletter disdetto, una prova di CRM. I report aggregati DMARC mostrano quali fonti inviano davvero a nome del tuo dominio, e ti aiutano a individuare gli include inutili. Verifica con il responsabile di ciascun servizio prima di rimuoverlo.
• Controlla se un include viene davvero valutato. SPF si verifica sul dominio del mittente della busta. Se i messaggi di un servizio mostrano il dominio del servizio in Return-Path, i riceventi controllano il record SPF di quel dominio, non il tuo, e il tuo include non serve a nulla per quella posta. Conferma nella documentazione del provider prima di toglierlo.
• Sostituisci a e mx con ip4 e ip6 per i server che controlli. Se il tuo server invia da 192.0.2.10, ip4:192.0.2.10 non costa nulla, mentre a costa un lookup. Chiediti se mx debba esserci: i server che ricevono la tua posta non necessariamente la inviano, e se appartengono al tuo provider di posta, il suo include potrebbe già elencare i server di invio. Aggiorna l’indirizzo quando il server cambia.
• Assegna a ogni mittente ad alto volume un sottodominio dedicato. Lascia che un servizio di newsletter o ticketing usi come mittente della busta un dominio di rimbalzo come news.example.com, con un proprio record SPF e un proprio limite di 10. SPF non si eredita, quindi il sottodominio ha bisogno di quel record. Con l’allineamento rilassato predefinito di DMARC, news.example.com resta allineato a un indirizzo From su example.com. Molti servizi lo chiamano return-path personalizzato o dominio di bounce.
• Elimina ptr. La RFC 7208 dice che NON DOVREBBE essere pubblicato: è lento, dipende dal DNS inverso controllato da chi possiede l’indirizzo IP che si connette e consuma lookup. Sostituiscilo con ip4/ip6 o con l’include del provider.
• Non considerare il riordino una soluzione. Spostare in testa il mittente più attivo significa che meno messaggi arrivano all’undicesimo lookup, ma il record resta rotto per tutto ciò che sta più in basso, compresa la posta falsificata che dovrebbe incontrare -all.

Anche DKIM allenta la pressione. DMARC richiede un solo esito allineato positivo, e DKIM di norma sopravvive all’inoltro mentre SPF no. Assicurati che ogni servizio firmi con il tuo dominio, poi riduci il record SPF.

Flattening SPF: meno lookup, più manutenzione

Il flattening sostituisce un include con gli intervalli ip4 e ip6 a cui si risolve oggi. Il conteggio dei lookup scende, ma il tuo record contiene ora una copia dell’elenco di qualcun altro, e la copia non si aggiorna da sola.

I servizi di flattening automatico risolvono gli include a intervalli regolari e riscrivono il tuo record. Questo risolve il problema degli intervalli obsoleti, ma dà a una terza parte un ruolo nel tuo DNS, e un aggiornamento fallito rompe il tuo SPF. Prova prima le altre soluzioni. Se decidi di appiattire, annota quale include hai sostituito e quando, confronta regolarmente con gli intervalli pubblicati dal provider e testa SPF dopo ogni modifica (Microsoft Learn dà lo stesso consiglio ai propri clienti).

Un record SPF per nome, diviso nel modo giusto

Un nome deve avere esattamente un record TXT che inizia con v=spf1. Con due, il ricevente non può scegliere e restituisce permerror (RFC 7208, sezione 4.5). Capita spesso quando la guida di configurazione di un nuovo servizio dice di “aggiungere questo record TXT” e qualcuno aggiunge un secondo record SPF invece di modificare il primo. Un secondo record quindi non raddoppia il budget; unisci i due:

# Sbagliato: due record SPF sullo stesso nome
example.com.  TXT  "v=spf1 include:_spf.mail.example.net -all"
example.com.  TXT  "v=spf1 include:spf.crm.example.org ~all"

# Corretto: un solo record
example.com.  TXT  "v=spf1 include:_spf.mail.example.net include:spf.crm.example.org -all"

Altri record TXT sullo stesso nome, come i token di verifica del sito, vanno bene; contano solo i record che iniziano con v=spf1. Una singola stringa dentro un record TXT contiene al massimo 255 caratteri. Un record SPF più lungo resta un unico record TXT composto da più stringhe tra virgolette, che i riceventi uniscono senza aggiungere spazi (sezione 3.3), quindi chiudi una stringa con uno spazio dove finisce un termine:

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:_spf.mail.example.net " "include:spf.crm.example.org -all"

Diversi altri errori producono lo stesso permerror: un errore di sintassi in qualunque punto del record, come include= al posto di include: (sezione 4.6), oppure l’include di un dominio senza record SPF. Anche i record SPF non si ereditano, quindi ogni nome usato come mittente della busta ha bisogno del proprio record, e ciascuno ha il proprio limite di 10.

Che cosa conta il checker gratuito SPF e DMARC

Lo snapshot gratuito di preparazione al lancio esegue otto controlli passivi su un dominio pubblico, senza registrazione; uno di essi legge i record DNS della posta. Non è un pentest né l’audit su sei aree, e non invia posta.

• Hostname esatto. Legge il record SPF sul nome che inserisci, senza ripiegare sul dominio padre. Inserisci il dominio del mittente della busta, per esempio example.com anziché www.example.com.
• Conteggio di primo livello. Conta i termini che generano query DNS in quel record (include, a, mx, ptr, exists e redirect) e segnala più di dieci come segnale di rischio medio.
• Non seguiti. Non segue include: né redirect=, non conta i void lookup e non segnala un secondo record SPF sullo stesso nome. L’esempio a cinque termini sopra supera questo conteggio anche se i riceventi hanno bisogno di undici lookup, quindi fai anche tu il conteggio ricorsivo.
• Altri segnali SPF. +all è segnalato come rischio alto e ?all come basso; un record SPF o DMARC mancante viene segnalato quando l’host ha record MX.

Per aprire prima il controllo DNS della posta, usa la verifica gratuita SPF e DMARC: esegue lo stesso snapshot e mostra quel controllo sopra gli altri sette. Per il resto del record, da ~all contro -all al passaggio di DMARC da none a reject, vedi la guida a SPF e DMARC.