Record SPF non trovato: perché succede e come risolvere

Un verificatore dice «no SPF record found», oppure l'intestazione di un messaggio riporta spf=none. Entrambe le segnalazioni significano la stessa cosa: il resolver ha chiesto i record TXT di un nome specifico e nessuno iniziava con v=spf1. Il tuo server di posta non ha nulla che non va. La domanda è perché la risposta fosse vuota, e di solito dipende dall'aver controllato, o pubblicato, al nome sbagliato.

Questo articolo è il percorso di diagnosi per quella risposta vuota. Se il tuo problema è un record che esiste ma non funziona, leggi invece gli articoli su troppe query DNS e sul limite di 10 query.

Cosa significa davvero «non trovato»

SPF risiede in un normale record TXT. Un ricevente prende il dominio dal messaggio (di norma il mittente della busta, detto anche indirizzo di rimbalzo o Return-Path), richiede i suoi record TXT e tiene solo quelli il cui testo inizia con v=spf1. Se questo elenco filtrato è vuoto, il risultato è none. Non è un errore di sintassi; è l'assenza di una policy.

È diverso dalle altre due situazioni con cui viene confuso. Ognuna ha il proprio risultato e la propria soluzione.

Causa 1: il record è al nome sbagliato

SPF viene cercato al dominio usato nella posta e da nessun'altra parte. Non è ereditato da un dominio superiore e non viene cercato su www. Un record pubblicato su www.example.com non serve a nulla per la posta inviata da @example.com, e un record su example.com non serve a nulla per la posta inviata da @news.example.com.

L'errore classico avviene nei pannelli DNS. Per un record sull'apex (il dominio senza sottodominio) il campo host è di solito @, ma alcuni pannelli richiedono di lasciarlo vuoto o di inserire il dominio completo. Leggi il testo di aiuto del pannello, poi conferma con una query invece di fidarti del modulo.

• Record su www o mail: testo corretto, host sbagliato. Spostalo sull'apex se invii da @example.com.
• Dominio raddoppiato: un pannello che aggiunge la zona in automatico trasforma example.com in example.com.example.com. Interroga quel nome e troverai lì il tuo record.
• Dominio di invio sbagliato: hai controllato example.com, ma il mittente della busta è bounce.example.net o mail.example.com. Il ricevente ha guardato quel nome, non il tuo.

Causa 2: stai controllando un dominio diverso da quello usato dalla posta

L'indirizzo che le persone vedono nell'intestazione From è una cosa. Il mittente della busta, che SPF valuta, può essere un'altra. Molti fornitori di servizi di posta usano un dominio di rimbalzo personalizzato, e alcuni usano per impostazione predefinita il proprio dominio. Allora SPF viene valutato su quel nome e il tuo record non viene proprio consultato per il controllo.

L'intestazione del messaggio mostra quale dominio è stato valutato (vedi sotto). Se è un tuo sottodominio, quel sottodominio ha bisogno di un proprio record anche quando il dominio superiore ne ha uno perfetto. Un sottodominio che non invia mai può pubblicare v=spf1 -all.

Causa 3: il testo non è una stringa SPF valida

Il verificatore è rigoroso sull'inizio del valore. Il testo deve iniziare con v=spf1, con il segno di uguale e senza spazi al suo interno. Tutti questi quasi-errori producono «non trovato»:

• spf1 include:_spf.example.net ~all (manca il v=)
• v=spf include:_spf.example.net ~all (la versione deve essere spf1)
• v = spf1 ... (spazi attorno al segno di uguale)
• Testo incollato con virgolette tipografiche «intelligenti» copiate da un documento o da una chat

Le virgolette meritano una nota. La maggior parte dei pannelli DNS ospitati aggiunge per te le virgolette doppie dritte, quindi digitare le tue può farle salvare come caratteri letterali. Se una risposta di dig mostra due livelli di virgolette, rimuovi quelle che hai digitato.

Causa 4: la zona che hai modificato non è quella attiva

Questa inganna anche chi ha esperienza. Puoi aggiungere un record TXT perfetto in un pannello DNS e non vedere comunque nulla nel DNS pubblico, perché quel pannello non è quello che interroga internet. Il motivo abituale è la delega.

• Registrar contro host DNS: il dominio è registrato presso una società, ma i suoi nameserver puntano a un'altra (una CDN, un hosting, un provider DNS separato). È attiva solo la zona presso i nameserver delegati. I record aggiunti nella pagina DNS del registrar stesso, o in una zona dimenticata presso un provider precedente, vengono ignorati.

Trova i nameserver delegati con la ricerca NS, poi modifica la zona esattamente presso quel provider. Questo spiega spesso meglio della propagazione il classico «l'ho aggiunto un'ora fa e ancora non c'è».

Causa 5: tipo di record obsoleto, cache o tempistica

Le prime bozze di SPF usavano un tipo di record dedicato (numero 99, chiamato SPF). Quel tipo è deprecato e i riceventi valutano i record TXT, quindi un record pubblicato solo come tipo SPF è invisibile ai controlli moderni. Pubblica un record TXT anche se il tuo provider DNS offre ancora un tipo SPF.

La tempistica è l'ultimo sospettato e il più debole. Se un resolver ha già appreso che il nome non aveva un record TXT, può continuare a servire quella risposta vuota per un periodo legato alle impostazioni di cache negativa della zona. Interrogare direttamente il nameserver autorevole elimina il dubbio. Il nostro articolo su quanto dura la propagazione DNS ne spiega il meccanismo.

Conferma cosa restituisce davvero il DNS

Prima di cambiare qualsiasi cosa, rivolgi al DNS la stessa domanda del ricevente. Su Linux o macOS:

dig TXT example.com +short
# a healthy answer includes a line like:
# "v=spf1 include:_spf.example.net ~all"

nslookup -type=TXT example.com

Una risposta vuota, o risposte che contengono solo cose come token di verifica del sito, conferma «non trovato». Per aggirare la cache del tuo resolver, interroga direttamente un nameserver: dig TXT example.com @ns1.example.net +short, usando un nameserver ottenuto dalla ricerca NS. Se restituisce il record e la tua query normale no, si tratta di cache. Se nessuna delle due lo restituisce, il record non è nella zona attiva.

Il verificatore SPF di questo sito interroga i record TXT del dominio inserito, tiene quelli che iniziano con v=spf1 e segnala «No SPF record» quando non ne trova. Se ne trova uno, segue anche gli include e conta le query. La ricerca TXT mostra tutti i valori TXT a un nome, utile quando il record è presente ma malformato, perché puoi vedere il testo grezzo.

Leggi l'intestazione di un messaggio fallito

Apri il sorgente originale di un messaggio consegnato e trova l'intestazione Authentication-Results aggiunta dal server ricevente. La parte SPF indica il risultato e di solito il dominio valutato. La formulazione varia a seconda del ricevente, quindi considera gli esempi come uno schema, non come un formato esatto.

spf=none (example.com does not designate permitted sender hosts)
spf=fail smtp.mailfrom=example.com
spf=permerror smtp.mailfrom=example.com

• spf=none: nessun record al dominio valutato. Usa questo articolo.
• spf=fail o softfail: esiste un record, ma l'IP di invio non è autorizzato. Aggiungi il mittente o correggi la policy.
• spf=permerror: il record è rotto, per due record o per troppe query.

Annota il dominio di smtp.mailfrom (o Return-Path). È quello, e non l'indirizzo From, che SPF ha valutato. Per leggere le intestazioni per intero, vedi come risalire al mittente originale di un'email.

Pubblica un record minimo e sicuro

Pubblica un solo record TXT al nome usato nel mittente della busta. Un record è un elenco di meccanismi letti da sinistra a destra, che termina con un valore predefinito per tutti gli altri.

• ip4 / ip6: autorizza un indirizzo o un intervallo, per esempio ip4:203.0.113.25. Non costa nessuna query DNS.
• include: autorizza ciò che autorizza il record SPF di un altro dominio, per esempio include:_spf.example.net. Costa una query.
• a: autorizza gli indirizzi IP nel record A (o AAAA) del dominio stesso. Costa una query.
• mx: autorizza gli host indicati nei record MX del dominio. Costa una query; è sbagliato quando il tuo host in entrata non è quello che invia.
• ~all, -all, ?all: il valore predefinito. ~all è softfail, -all è fail, ?all è neutral.

Inizia con ~all mentre confermi che ogni mittente è elencato, poi valuta -all quando sei sicuro. ?all non afferma nulla ed è per lo più transitorio. Un elenco corretto conta più della chiusura, dato che i riceventi pesano SPF insieme a DKIM e DMARC.

Indicazioni rapide per le piattaforme più comuni

I menu cambiano e differiscono, ma gli schemi di errore si ripetono. Controlla questi punti per ogni tipo di configurazione.

• Microsoft 365 e Google Workspace: entrambi pubblicano un include da copiare dalla console di amministrazione o dalla guida di configurazione. Un «non trovato» lì di solito significa che il record è finito sul provider DNS o sull'host sbagliato.
• GoDaddy e altri registrar: se i nameserver sono stati cambiati verso una CDN o una società di hosting, la pagina DNS del registrar non è più autorevole. Modifica i record presso il provider mostrato dalla ricerca NS.
• Cloudflare: quando il dominio usa i nameserver di Cloudflare, aggiungi il record TXT nella scheda DNS di Cloudflare.

Cosa fanno i riceventi quando non c'è SPF

SPF none non è un rifiuto automatico. Lo standard lascia la decisione alla policy locale del ricevente, quindi gli esiti variano. La posta senza SPF e senza DKIM o DMARC a compensare ha più probabilità di sembrare sospetta, e alcuni provider pubblicano requisiti di autenticazione per i mittenti di massa. Controlla le regole attuali dei provider a cui scrivi.

SPF controlla il mittente della busta, quindi da solo non impedisce a qualcuno di falsificare il tuo indirizzo From visibile; quello è compito di DMARC. Vedi SPF, DKIM e DMARC spiegati e come controllare un record SPF.