Defaults.Exposed › Correzioni › Guides

"SPF Record Not Found" — ma lei un record ce l'ha? Le 5 cause reali (2026)

Pubblicato 2026-07-08

Dati aggiornati al 2026-06-29 · metodologia v7. Dati aggregati del censimento su 261 milioni di domini valutati. Veda come assegniamo i voti.

Se un checker dice “SPF record not found” ma lei è sicuro di averne pubblicato uno, il record è di solito invisibile, non mancante: 1.013.416 domini — circa uno su 138 di quelli che tentano l’SPF — pubblicano due o più record SPF, un PermError (RFC 7208 §3.2) che molti checker segnalano come not-found, secondo il censimento Defaults.Exposed di 261 milioni di domini.

Le cause reali sono cinque, tutte risolvibili in una sola seduta: host sbagliato, record duplicato, tipo DNS sbagliato o virgolette pasticciate, nameserver incoerenti, oppure una collisione di lunghezza/CNAME. Qui sotto: il test da 60 secondi per ciascuna, nell’ordine in cui controllarle, poi i passaggi per la soluzione.

È sicuro che il record esista davvero?

Parta dall’ipotesi meno lusinghiera, perché è di gran lunga la più comune: dei 261.086.232 domini valutati nel censimento Defaults.Exposed, 121.145.609 — il 46,4% — non hanno alcun record SPF. Molti casi di “ma io l’avevo configurato” si rivelano un record aggiunto a una zona di staging o a un vecchio provider DNS che non è più autoritativo. Controlli il provider DNS a cui puntano davvero i suoi nameserver (spesso non il suo registrar) cercando un record TXT che inizi con v=spf1. Se davvero non c’è, salti il lavoro da detective e vada dritto a sistemare il suo record SPF.

Come si controlla correttamente un record SPF?

I checker web interrogano il DNS tramite il proprio resolver con cache. Per vedere la verità, chieda direttamente al nameserver autoritativo del suo dominio:

# find the authoritative nameservers
dig NS yourdomain.com +short

# ask one of them directly for TXT records
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Su Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Due regole di interpretazione. Primo, conti le righe che iniziano con v=spf1 — il numero conta quanto il contenuto. Secondo, verifichi di aver interrogato il nome giusto: i riceventi valutano l’SPF rispetto al dominio nel Return-Path (RFC5321.MailFrom, l‘“envelope from”) — non l’indirizzo From che i destinatari vedono. Se il suo strumento per newsletter fa rientrare i bounce via bounce.yourdomain.com, un record perfetto sull’apex non è il record che i riceventi consultano.

Quali sono le cinque cause reali?

Dati aggiornati al 2026-06-29.

1. Il record è sull’host sbagliato?

Il classico: SPF aggiunto su mail.yourdomain.com quando la posta dichiara di provenire da yourdomain.com, o viceversa. L’SPF non si eredita verso il basso — un record sull’apex non dice nulla sui sottodomini, e viceversa. Pubblichi esattamente sul nome presente nel suo Return-Path. Un fornitore che invia dal proprio sottodominio di bounce ha bisogno di un record su quel sottodominio — di solito un CNAME o TXT fornito dal fornitore stesso (la guida alla configurazione SPF su GoDaddy mostra dove si trovano questi campi).

2. Ha due record SPF?

La causa principale, e il messaggio di errore più fuorviante dell’autenticazione email. L’RFC 7208 §3.2 è netto: un dominio deve avere esattamente un record SPF. Due o più sono un PermError — i riceventi trattano il suo SPF come nullo. Alcuni checker riportano quello stato con precisione (“multiple records found”); altri riportano l’effetto netto: no valid SPF record found. Lei vede un record nel suo pannello e conclude che il checker è rotto. Non lo è — lei ha un record di troppo.

Il censimento ha trovato 1.013.416 domini con due o più record SPF — circa uno su 138 dei domini che tentano l’SPF — ognuno con l’SPF di fatto spento. Succede di solito durante un cambio di provider: la procedura guidata del nuovo provider aggiunge un record nuovo invece di modificare quello vecchio. La soluzione è un’unione, mai un secondo record: combini tutto in un’unica riga v=spf1 … ~all ed elimini il resto. Il nostro report sui dati due record SPF equivalgono a nessuno analizza come un milione di domini sia finito qui; se è iniziato dopo una migrazione, veda l’SPF ha smesso di funzionare dopo il cambio di provider. Durante l’unione, non concateni alla cieca ogni include: — ognuno costa lookup DNS contro il limite rigido di 10 dell’SPF, scambiando il not-found con un PermError: too many DNS lookups.

3. Ha pubblicato il tipo di record sbagliato — o l’interfaccia lo ha pasticciato?

Agli inizi l’SPF aveva un proprio tipo di record DNS (tipo 99, chiamato letteralmente “SPF”). È stato deprecato: l’RFC 7208 richiede TXT, e i riceventi non interrogano il tipo 99. Alcuni pannelli DNS offrono ancora “SPF” nel menu a tendina del tipo di record; lo scelga e il suo record sarà reale, ben formato e invisibile. Controlli la colonna del tipo e ripubblichi come TXT.

Il fratello più subdolo sono le virgolette. Incollare un valore racchiuso tra virgolette in un campo che aggiunge le proprie virgolette produce ""v=spf1 …"" — che non inizia più con v=spf1, quindi per un verificatore non esiste. L’output di dig mostra la verità; il pannello DNS spesso la nasconde per motivi estetici.

4. Sta davvero “ancora propagando”?

“Dia 24–48 ore per la propagazione” è il consiglio più abusato del DNS. La propagazione è solo la scadenza delle cache: una volta trascorso il TTL del record (tipicamente 1 ora, raramente più di 24), ogni resolver può vedere la nuova risposta. Ancora not-found dopo 24 ore? La propagazione non è la causa.

I due veri colpevoli: il negative caching — un resolver che l’ha cercata prima che aggiungesse il record memorizza in cache la risposta “nessun record” fino alla scadenza del TTL negativo — e i nameserver incoerenti dopo una migrazione, quando il dominio elenca ancora i nameserver del vecchio provider accanto ai nuovi e metà del mondo legge una zona che lei non modifica più. Interroghi direttamente ogni nameserver elencato; se le risposte differiscono, l’ha trovato. Sistemi la delega NS presso il registrar in modo che sia autoritativo solo il provider che lei effettivamente modifica.

5. Il record è troppo lungo, o bloccato da un CNAME?

Una singola stringa in un record TXT arriva al massimo a 255 caratteri. I record SPF più lunghi sono leciti ma devono essere suddivisi in più stringhe tra virgolette all’interno di un unico record — e le interfacce dei provider DNS sbagliano regolarmente la suddivisione, troncando il valore o spezzandolo a metà di un meccanismo così che non venga più interpretato. Se il suo record è lungo, controlli nell’output di dig un valore che termina bruscamente.

A parte, il DNS vieta un record TXT su un nome che ha già un CNAME. Se mail.yourdomain.com è un CNAME verso il suo provider, non può metterci anche l’SPF — alcuni pannelli lo accettano e poi servono solo il CNAME. Metta il record dove punta il CNAME (se lo controlla), oppure ristrutturi in modo che il nome che invia non sia in CNAME. I provider con una gestione TXT pulita rendono entrambe le cose più facili — veda la guida alla configurazione SPF su Cloudflare.

Come si risolve, passo per passo?

1. Esegua la scansione gratuita su defaults.exposed — legge il suo DNS live e le dice in quale dei cinque stati si trova, prima che tocchi qualsiasi cosa.
2. Confermi quali nameserver sono autoritativi (dig NS) e che concordino tutti.
3. Interroghi i TXT sul nameserver autoritativo per il dominio esatto del Return-Path.
4. Conti le righe v=spf1: zero → ne pubblichi una; due o più → le unisca in una.
5. Verifichi che il tipo sia TXT, che il valore inizi esattamente con v=spf1 e che non si siano insinuate virgolette spurie o troncature.
6. Attenda la scadenza di un TTL, poi ripeta la scansione per confermare che si risolva correttamente ovunque.

Domande frequenti

Perché il checker dice “not found” quando io vedo il record nel mio pannello DNS? Di solito è la causa 2 o la 4: un secondo record v=spf1 li rende entrambi nulli — un PermError che alcuni strumenti segnalano come not-found, lo stato in cui si trovano 1.013.416 domini al 2026-06-29 — oppure il suo pannello non è il DNS effettivamente autoritativo.

Quanto tempo prima che i checker vedano la mia correzione? Un TTL — tipicamente un’ora, al massimo 24. Oltre, la “propagazione” non è la spiegazione; ricontrolli le cinque cause, partendo dalla coerenza dei nameserver.

Dovrei usare il tipo di record “SPF” che il mio pannello DNS offre? No. Il tipo 99 è deprecato; l’RFC 7208 richiede solo TXT. Un record di tipo 99 è invisibile ai riceventi moderni.

Ora il record viene trovato — perché la mia posta fallisce ancora l’SPF? Perché l’SPF viene verificato rispetto al dominio del Return-Path, non all’intestazione From, e il record deve elencare davvero i server che inviano per lei. Essere trovato è il primo passo; la guida sistemare il suo record SPF spiega come farlo passare.

Non avere alcun record SPF è davvero così comune? Sì — 121.145.609 domini, il 46,4% dei 261.086.232 valutati nel censimento Defaults.Exposed (al 2026-06-29), non pubblicano alcun SPF. Il not-found è lo stato predefinito di internet.

Invii il report al titolare

Una volta che il record si risolve correttamente, ripeta la scansione e inoltri il report con i voti al titolare dell’azienda o al cliente a cui appartiene il dominio. Mostra, in linguaggio semplice, cosa era rotto, cosa ha sistemato e dove si trova ora il dominio — esattamente la prova che gli verrà chiesta ai rinnovi dell’assicurazione informatica e nei questionari di sicurezza dei fornitori. Il report è la ricevuta del lavoro.

Controlli gratuitamente il suo record SPF

Veda in quale dei cinque stati di not-found si trova il suo dominio — in privato e visibile solo al titolare.

Controlli il suo dominio → · Sistemare l’SPF → · L’SPF si è rotto dopo il cambio di provider → · Come assegniamo i voti → · Solo dati aggregati. Dati conservati ed elaborati nell’UE.