Il limite SPF di 10 lookup: cosa conta e come restare sotto

Un mail server ricevente verifica l'SPF valutando il tuo record, e valutarlo costa query DNS. Per mantenere limitato quel costo, l'RFC 7208 pone un tetto al numero di termini che causano query che una singola verifica può valutare. Supera il tetto e il risultato è permerror, un errore permanente che non è un pass. I checker lo segnalano comunemente come «too many DNS lookups» e di solito compare subito dopo che un altro servizio di invio è stato aggiunto al record.

Cosa conta la specifica

La sezione 4.6.4 dell'RFC 7208 elenca i termini che causano query DNS: i meccanismi include, a, mx, ptr ed exists e il modificatore redirect. Le implementazioni devono limitare a 10 il totale di questi termini durante una valutazione e devono restituire permerror se il limite viene superato. I meccanismi all, ip4 e ip6 non richiedono alcuna query e non vengono contati, e nemmeno il modificatore exp, che viene recuperato solo in un secondo momento, dopo un fallimento.

Contano due dettagli. Primo, include non copia un altro record nel tuo: ne viene usato solo il risultato, e l'RFC ammette che il nome sia stato scelto male. Un -all dentro un record incluso non pone fine alla valutazione complessiva. Secondo, i meccanismi vengono valutati da sinistra a destra e l'elaborazione si ferma al primo che corrisponde. Il limite si applica ai termini effettivamente valutati durante una verifica, non alla dimensione del record sulla carta.

Contare un record a mano

Considera un record ipotetico per un'azienda che usa due piattaforme di posta, un CRM, un help desk e un proprio mail server:

v=spf1 include:mailer-a.example include:mailer-b.example include:crm.example include:helpdesk.example mx a ~all

Supponi che i record inclusi contengano i termini qui sotto. Sono inventati a scopo illustrativo, e i record dei provider reali differiscono e cambiano nel tempo.

La posta inviata tramite la prima piattaforma corrisponde subito e passa. La posta del server che solo l'ultimo a autorizza richiede un undicesimo lookup, quindi la verifica restituisce permerror invece di una corrispondenza. Questa asimmetria è il motivo per cui il guasto sembra intermittente: dipende dalla posta di quale mittente viene controllata.

Altri limiti nella stessa specifica

• Lookup vuoti. Una query che non restituisce record, o un errore sul nome, è un lookup vuoto. L'RFC 7208 raccomanda di limitarli a due, e superare il limite produce permerror. A parte, un include: la cui destinazione non ha alcun record SPF, compreso un nome che non esiste più, restituisce none, e il meccanismo include lo trasforma subito in permerror, quindi un include obsoleto può rompere da solo un record.
• Fan-out. Un meccanismo mx non può innescare più di 10 lookup di indirizzi. Per ptr, i nomi oltre i primi 10 vengono ignorati.
• Un solo record. Se un dominio pubblica più di un record la cui versione è esattamente v=spf1, il risultato è permerror.
• Dimensione. L'RFC consiglia di mantenere il record pubblicato abbastanza piccolo da far stare la risposta in 512 ottetti, così da viaggiare in un singolo pacchetto UDP senza EDNS(0).
• Tipo di record. L'SPF deve essere pubblicato come record TXT. Il tipo di record SPF dedicato usato nel periodo sperimentale è stato dismesso.
• Tempo. I riceventi dovrebbero limitare il tempo dedicato a una valutazione, ma concedere almeno 20 secondi. Se questo limite di tempo viene superato, il risultato dovrebbe essere temperror, un errore temporaneo, non permerror.

Come tornare sotto il limite

1. Elimina ciò che non usi più. Un servizio disdetto costa comunque un lookup ogni volta che la valutazione raggiunge il suo include. Rimuovere gli include ormai inutili è la correzione più economica.
2. Sposta i mittenti su sottodomini. Ogni nome ha il proprio record e il proprio budget di 10. La posta il cui envelope sender è su news.example.com viene verificata rispetto al record di quel nome, non a quello del dominio radice. Con l'allineamento rilassato, DMARC continua ad associare il sottodominio al dominio organizzativo.
3. Sostituisci a e mx con valori letterali quando i server sono tuoi e cambiano di rado. ip4 e ip6 non costano nulla.
4. Usa il flattening con cautela. Il flattening sostituisce un include con gli indirizzi a cui si risolve in questo momento. Oggi passa e fallisce in silenzio quando il provider cambia i propri intervalli.
5. Elimina ptr. L'RFC dice che non dovrebbe essere pubblicato. Sostituire redirect con include non fa risparmiare nulla, poiché entrambi contano un lookup.
6. Ordina per volume, ma non farci affidamento. Poiché la valutazione si ferma alla prima corrispondenza, elencare per primi i valori letterali e i mittenti con il volume più alto consuma meno lookup per la maggior parte della posta. Questo riduce la frequenza con cui il limite crea problemi; non rende valido un record che supera il limite, e può nascondere il guasto finché non invia la posta un mittente usato di rado.

Un permerror ha conseguenze che vanno oltre l'SPF stesso. DMARC (RFC 7489) passa quando SPF o DKIM passa per un dominio allineato, e permerror non è un pass, quindi l'SPF non può più contribuire. Se anche DKIM manca o non è allineato, il messaggio non supera DMARC. Per vedere il tuo conteggio, lo strumento di controllo SPF segue ogni include e redirect e conta i lookup lungo l'intero albero rispetto al limite di 10. È un conteggio nel caso peggiore dei termini, non solo di quelli che un dato messaggio farebbe scattare. Quando modifichi il record, abbassa prima il suo TTL, così un errore potrà essere annullato in fretta; vedi il TTL DNS spiegato. Per il quadro generale, leggi SPF, DKIM e DMARC spiegati.

Fonti e letture di approfondimento

• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (Kitterman, 2014)
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Kucherawy and Zwicky, 2015)