Validare un record SPF significa controllarlo rispetto alle regole che i server di posta riceventi applicano effettivamente - la specifica Sender Policy Framework (RFC 7208). Un record può sembrare corretto ed essere comunque rifiutato, quindi ecco cosa significa "valido" e come correggere i difetti che questo validatore individua.
Cosa significa "valido" secondo RFC 7208
Un record SPF valido soddisfa contemporaneamente tutte queste condizioni: è l'unico record TXT v=spf1 sul dominio, inizia con il tag v=spf1, usa solo meccanismi e qualificatori riconosciuti, si risolve in dieci o meno ricerche DNS, produce non più di due ricerche void e termina con un qualificatore all. Se ne manca anche una sola, i riceventi possono restituire un PermError e trattare il record come se non fosse mai stato pubblicato.
Le regole di sintassi che il validatore applica
- Un solo record. RFC 7208 consente esattamente un record
v=spf1per dominio. Un secondo è un PermError automatico: entrambi vengono ignorati. - Ordine corretto. Il tag di versione
v=spf1deve venire per primo e il meccanismoallper ultimo. - Solo meccanismi e qualificatori validi. I meccanismi consentiti sono
include,a,mx,ip4,ip6,existseall; ciascuno può recare un qualificatore+,-,~o?. Refusi comeip:oincludes:falliscono. - Lunghezza delle stringhe. Ogni singola stringa di caratteri nel record TXT deve restare entro 255 caratteri, e l'intero record entro 512 byte, altrimenti il DNS lo tronca.
I limiti di 10 ricerche e di 2 ricerche void
Due limiti numerici individuano la maggior parte dei record "sintassi valida, ma comunque fallito". Il primo è il noto tetto di dieci meccanismi che interrogano il DNS per valutazione - ogni include, a, mx, ptr ed exists conta, e gli include annidati contano ricorsivamente. Il secondo, meno noto, è quello delle ricerche void: non più di due meccanismi possono risolversi in una risposta DNS vuota. Se supera uno dei due, il risultato è un PermError. Se il suo record è oltre il limite di dieci ricerche, AutoSPF appiattisce gli include in un record compatto che si valida senza errori e riesamina ogni 15 minuti - veda troppe ricerche DNS per i dettagli.
Meccanismi deprecati e rischiosi
Il validatore avvisa su due cose tecnicamente analizzabili ma da evitare. Il meccanismo ptr è deprecato da RFC 7208 (§5.5) perché è lento e inaffidabile: lo sostituisca con ip4/ip6 o un include. E +all autorizza l'intera Internet a inviare a nome del suo dominio, vanificando del tutto lo scopo di SPF; un record valido dovrebbe terminare con -all o ~all.
Come correggere un record SPF non valido
La maggior parte dei fallimenti di validazione corrisponde a una di quattro correzioni - e la nostra guida su come risolvere i problemi di validazione SPF tratta ciascuna in dettaglio:
- Due record SPF? Unisca ogni mittente in un unico record
v=spf1. - Oltre 10 ricerche? Sostituisca gli include pesanti in ricerche con voci
ip4/ip6, oppure appiattisca automaticamente il record con AutoSPF. ptrdeprecato? Lo rimuova e autorizzi quegli host tramite IP o include.- Qualificatore mancante o errato? Si assicuri che il record inizi con
v=spf1e termini con-all(o~alldurante i test).
Ricostruire da zero è spesso più facile che correggere: il generatore di record SPF gratuito produce un record sintatticamente pulito che può validare qui in un solo passaggio.
Dove si colloca SPF accanto a DKIM e DMARC
Un record SPF valido è necessario ma non sufficiente. DKIM firma il corpo del messaggio e DMARC lega SPF e DKIM al dominio From visibile e imposta il criterio di applicazione. Dopo aver controllato il suo record SPF e averlo validato, confermi gli altri due con il DMARC checker e il DKIM lookup gratuiti. Rivalidi SPF ogni volta che aggiunge o rimuove un servizio di invio, e lo verifichi almeno una volta a trimestre - e ricordi che ogni sottodominio che invia necessita del proprio record valido.