Un record SPF nasce quasi sempre semplice: una riga con il server di posta dell'azienda e poco altro. Poi arrivano il CRM, la piattaforma per le newsletter, il sistema di ticketing, il gestionale che invia le fatture, e ognuno chiede di aggiungere il proprio include:. Dopo qualche anno il record funziona solo sulla carta. Il motivo è una regola precisa della specifica SPF, spesso ignorata finché le email non iniziano a finire nello spam.
La regola: al massimo 10 meccanismi che interrogano il DNS
La specifica SPF (RFC 7208) stabilisce che la valutazione di un record non può richiedere più di 10 interrogazioni DNS aggiuntive. Il limite esiste per evitare che un record mal scritto, o costruito apposta, trasformi ogni email ricevuta in una raffica di query verso i server DNS.
Contano ai fini del limite questi meccanismi e modificatori:
include:aemxptr(sconsigliato in ogni caso)exists:redirect=
Non contano invece ip4:, ip6: e all, perché non richiedono interrogazioni: l'indirizzo è già scritto nel record.
Il dettaglio che sorprende molti è che il conteggio è ricorsivo. Se includi il record di un fornitore e quel record contiene a sua volta tre include:, hai consumato quattro lookup, non uno. Un singolo servizio di posta in cloud può da solo impegnarne tre o quattro.
Esiste anche un secondo limite meno noto: le cosiddette void lookup, cioè le interrogazioni che restituiscono una risposta vuota o un dominio inesistente. La specifica raccomanda di non tollerarne più di due. Un include: che punta a un dominio di un fornitore dismesso è quindi doppiamente dannoso.
Cosa succede quando si supera il limite
Quando il destinatario conta l'undicesimo lookup, interrompe la valutazione e restituisce permerror. Non è un «fail» esplicito, ma per molti filtri il risultato è equivalente: SPF non ha dato esito positivo. Se il dominio pubblica una policy DMARC e il messaggio non è firmato DKIM in modo allineato, l'email può essere rifiutata o messa in quarantena.
Il problema è insidioso perché non è stabile. I fornitori modificano i propri record nel tempo: un record che ieri richiedeva nove lookup oggi può richiederne undici senza che tu abbia toccato nulla.
Contare i lookup a mano
Prendiamo un record di esempio:
example.com. TXT "v=spf1 mx include:_spf.mail.example.net include:spf.crm.example.org include:mailing.example.net a:smtp.example.com ~all"
Il conteggio procede così:
mx: 1 lookup (più la risoluzione degli host MX, che la specifica conta insieme).include:_spf.mail.example.net: 1, più quelli contenuti nel record incluso.include:spf.crm.example.org: 1, più gli eventuali annidati.include:mailing.example.net: 1, più gli annidati.a:smtp.example.com: 1.
Siamo già a cinque prima di aprire i record dei fornitori. Se ciascuno ne contiene due, il totale arriva a undici. Per verificare conviene interrogare ogni record incluso con dig TXT nome o nslookup -type=TXT nome e annotare la profondità, oppure usare uno dei tanti validatori SPF che mostrano l'albero completo.
Come rientrare nel limite
Eliminare ciò che non serve
Il primo passo è sempre l'inventario. Nel mio lavoro trovo regolarmente include: di servizi abbandonati da anni, meccanismi mx per domini che non inviano dai propri MX, o a che punta al sito web, che non spedisce posta. Ogni voce va giustificata: chi invia davvero con questo dominio nel Return-Path?
Sostituire a e mx con indirizzi espliciti
Se il server di posta interno ha indirizzi stabili, scriverli come ip4: o ip6: azzera i lookup corrispondenti. Il prezzo è la manutenzione: se l'indirizzo cambia, va aggiornato anche l'SPF.
Spostare i servizi su sottodomini
È la soluzione più pulita. Molte piattaforme di invio consentono di usare un dominio di bounce personalizzato (per esempio bounce.example.com) come Return-Path. SPF viene valutato sul dominio del Return-Path, non su quello visibile nel From. Così il record della piattaforma va pubblicato sul sottodominio e non consuma lookup del dominio principale. DMARC resta soddisfatto grazie all'allineamento rilassato, perché il sottodominio appartiene allo stesso dominio organizzativo.
Appiattire con giudizio
L'appiattimento (flattening) sostituisce gli include: con l'elenco degli indirizzi che risolvono. Riduce i lookup a zero, ma congela una fotografia: quando il fornitore aggiunge nuovi indirizzi, i tuoi messaggi da quegli indirizzi falliscono SPF. Ha senso solo con uno strumento che rigenera automaticamente il record a intervalli regolari, e mai per servizi che cambiano spesso infrastruttura.
Contare su DKIM
SPF non è l'unico modo per superare DMARC. Se ogni servizio firma con DKIM allineato al tuo dominio, un SPF imperfetto diventa molto meno critico. Non è una scusa per lasciare il record rotto, ma è il motivo per cui DKIM va configurato ovunque, non solo sul server principale.
Errori frequenti da evitare
| Errore | Conseguenza |
|---|---|
Due record TXT che iniziano con v=spf1 |
permerror immediato |
+all alla fine |
chiunque è autorizzato a inviare |
ptr nel record |
lento, sconsigliato dalla specifica |
| Include verso domini inesistenti | void lookup e possibile permerror |
| Record oltre 255 caratteri non spezzato | alcuni pannelli DNS lo troncano |
Sull'ultimo punto: una stringa TXT non può superare 255 caratteri, ma un record può contenere più stringhe tra virgolette, che vengono concatenate. Molti pannelli DNS gestiscono la divisione da soli, altri no.
In sintesi
- SPF ammette al massimo 10 meccanismi che interrogano il DNS, contati anche dentro gli
include:annidati. - Superare il limite produce permerror, che molti filtri trattano come un fallimento.
- Prima di tutto si eliminano le voci inutili; poi si spostano i servizi esterni su sottodomini di bounce.
- L'appiattimento funziona solo se automatizzato e aggiornato con regolarità.
- DKIM allineato su ogni servizio rende la posta molto meno fragile rispetto ai problemi di SPF.
