Record SPF Gmail: La tua guida passo dopo passo per il 2026

Lanci un aggiornamento per i clienti, un’email di assunzione o una sequenza di vendita da Gmail. Il testo è solido. La lista è pulita. Poi le risposte rallentano fino a fermarsi, o peggio, qualcuno ti dice che il tuo messaggio è finito nello spam.

Nei piccoli team, questo porta solitamente a controllare prima le righe dell’oggetto, i modelli e il volume di invio. Giusto. Ma una delle cause più comuni risiede fuori da Gmail, nelle tue impostazioni DNS. Il tuo record SPF decide se i server di posta in arrivo trattano Gmail come un mittente approvato per il tuo dominio.

Ciò è ancora più importante se stai facendo ricerche su strumenti basati su Gmail per l’outreach. Fai attenzione ai nomi di prodotti che suonano generici, specialmente Mail Merge for Gmail. La frase descrive una categoria tanto quanto uno specifico prodotto, quindi è facile leggere consigli di configurazione pensati per un diverso strumento di mail merge e applicarli al sistema sbagliato.

Perché il tuo record SPF Gmail è importante

Un modo utile per pensare all’SPF è come a una lista degli invitati per il tuo dominio. Quando la tua email raggiunge un altro server di posta, quel server controlla se il mittente è nella lista. Se Gmail è presente, il tuo messaggio ha molte più probabilità di essere trattato come legittimo. Se Gmail non c’è, il ricevente ha un motivo per diffidare del messaggio prima ancora che il destinatario legga l’oggetto.

Quel problema di fiducia si presenta in situazioni aziendali ordinarie. Un fondatore invia email di onboarding. Un responsabile HR invia inviti a colloqui. Una scuola invia aggiornamenti sugli eventi ai genitori. Tutto sembra a posto dentro Gmail, ma il server ricevente non vede alcuna chiara autorizzazione per il tuo dominio e inizia a gestire quei messaggi con maggiore cautela.

Cosa protegge l’SPF

L’SPF svolge due compiti contemporaneamente:

• Protezione della consegna: Aiuta i server riceventi a riconoscere che Google è autorizzato a inviare per conto del tuo dominio.
• Protezione del brand: Rende più difficile per qualcun altro falsificare (spoofing) il tuo dominio nelle email in uscita.

L’SPF comunica al mondo esterno quali sistemi di invio parlano per il tuo dominio e quali no.

Se stai cercando di aumentare il successo dell’email marketing, questo è uno dei primi controlli tecnici che vale la pena fare. Un testo migliore non può compensare un dominio che non è autenticato correttamente.

Perché piccoli errori causano grandi problemi

La parte frustrante è che i problemi SPF spesso non sembrano problemi SPF. I messaggi potrebbero comunque essere inviati. Alcuni destinatari potrebbero riceverli. Altri potrebbero vedere il posizionamento nello spam, avvisi o filtri silenziosi. Quell’incoerenza è ciò che confonde le persone.

Se le tue email stanno già finendo nelle cartelle di posta indesiderata, vale la pena abbinare questa guida alla configurazione con una pratica guida su come evitare che le email finiscano nello spam. L’SPF non è l’intera storia della deliverability, ma è una delle poche correzioni che migliora direttamente la fiducia a livello di dominio invece di modificare il contenuto sperando per il meglio.

Creare il tuo record SPF Gmail principale

Se il tuo dominio invia email solo tramite Gmail o Google Workspace, la configurazione è semplice. Il record SPF ufficiale di Google è la stringa esatta documentata nel Centro assistenza Google Workspace:

v=spf1 include:_spf.google.com ~all

Quel valore deve essere pubblicato come un singolo record TXT alla radice del tuo dominio. Nella maggior parte dei pannelli DNS, l’host è @. Google raccomanda anche un TTL di 3600 secondi (1 ora), e le modifiche DNS possono richiedere fino a 48 ore per propagarsi completamente a seconda del tuo provider, secondo la stessa documentazione di Google Workspace.

Cosa inserire nel DNS

Che il tuo DNS sia gestito in GoDaddy, Cloudflare, Namecheap o un altro provider, i campi solitamente si mappano così:

1. Tipo: TXT
2. Host o Nome: @
3. Valore o Contenuto: la stringa SPF sopra indicata
4. TTL: 3600 se il tuo provider ti permette di impostarlo manualmente

L’errore più comune qui è pensare troppo al tipo di record. Molti pannelli DNS non offrono più un tipo di record SPF separato. È normale. Ti serve un record TXT.

Una rapida guida visiva può aiutare se è la prima volta che modifichi il DNS:

Cosa funziona e cosa no

Ecco la versione pratica.

• Funziona: aggiungere un record TXT alla radice del dominio con l’esatto valore SPF di Gmail.
• Non funziona: aggiungere spazi extra, dividere il valore in record SPF separati o pubblicarlo sotto l’host sbagliato, come un sottodominio, quando la tua posta viene inviata dal dominio principale.

Regola pratica: Copia il valore SPF esattamente, pubblicalo una volta e resisti alla tentazione di creare un secondo record SPF in seguito quando aggiungi un altro mittente.

Se ti trovi in un semplice ambiente solo Gmail, questo è solitamente sufficiente per completare correttamente la configurazione del record SPF Gmail di base. Salva il record, attendi la propagazione e verifica prima di cambiare qualsiasi altra cosa.

Gestire mittenti email multipli e Mail Merge

Una configurazione comune per le piccole imprese si presenta così. Il personale invia posta regolare da Google Workspace, il marketing gestisce campagne da uno strumento di mail merge e un CRM o un help desk invia messaggi automatizzati dallo stesso dominio. L’SPF deve coprirli tutti, altrimenti uno di quei sistemi inizierà a fallire l’autenticazione.

È qui che molte configurazioni SPF di Gmail si rompono. Il record Google di base è facile. La complessità inizia quando ogni nuovo strumento ti chiede di aggiungere un’altra voce include: e nessuno controlla cosa facciano quelle aggiunte al record completo.

Le due regole che contano di più

Regola uno: pubblica un record TXT SPF per il dominio.

Regola due: mantieni la valutazione SPF completa sotto i 10 lookup DNS. Quel limite include i lookup nidificati all’interno di ogni include:. Un record può sembrare breve nel tuo pannello DNS e fallire comunque perché il record SPF di un fornitore si espande in diversi altri controlli. Questa analisi di DMARC Report spiega perché il numero di lookup è importante nella configurazione SPF di Gmail.

Gli ambienti con mittenti multipli raggiungono quel limite più velocemente di quanto le persone si aspettino. Google Workspace più un mittente di mail merge, un CRM e una piattaforma di supporto possono metterti nei guai anche se le istruzioni di ogni fornitore sono tecnicamente corrette di per sé. L’errore è trattare ogni mittente come un progetto DNS separato invece di una politica di autorizzazione combinata.

Come appare un merge corretto

Se Gmail e un altro servizio approvato inviano entrambi posta per il tuo dominio, aggiungi entrambi i mittenti allo stesso record SPF.

Scenario	Record SPF unito corretto
Solo Gmail	v=spf1 include:_spf.google.com ~all
Gmail più un mittente di terze parti	v=spf1 include:_spf.google.com include:spf.thirdparty.com ~all
Gmail più diversi mittenti	v=spf1 include:_spf.google.com include:spf.vendorone.com include:spf.vendortwo.com ~all

Quegli esempi mostrano la struttura. I tuoi valori reali di terze parti devono provenire dalla documentazione di ogni provider. Il punto pratico rimane invariato. Un dominio ottiene un record SPF.

Cosa si rompe solitamente nella vita reale

Solitamente vedo tre schemi di fallimento.

• Viene pubblicato un secondo record SPF. Qualcuno aggiunge una nuova voce TXT che inizia con v=spf1 invece di modificare quella esistente.
• I vecchi servizi rimangono autorizzati per sempre. Un’azienda smette di usare uno strumento, ma il suo include: rimane nel DNS e continua a consumare lookup.
• Il mail merge viene trattato come “solo Gmail”. Alcuni strumenti inviano tramite l’infrastruttura di Google, mentre altri inviano tramite i propri server o un provider collegato. Quella differenza cambia se l’SPF necessita di un altro include.

Il terzo punto viene spesso trascurato. Se il tuo team utilizza un flusso di lavoro basato su Fogli, conferma come quello strumento invia posta prima di toccare il DNS. Una guida sul mail merge da Google Fogli può aiutarti a mappare il flusso di lavoro, ma l’SPF dipende comunque dall’infrastruttura di invio dietro quel flusso.

Come rimanere sotto il limite di 10 lookup

Inizia con un inventario dei mittenti. Elenca ogni sistema autorizzato a inviare posta come tuo dominio. Includi piattaforme di marketing, CRM, strumenti di supporto, app di fatturazione, moduli del sito web e qualsiasi prodotto di mail merge.

Poi riduci drasticamente.

Rimuovi i mittenti che non usi più. Controlla se due strumenti inviano tramite lo stesso provider, il che potrebbe rendere superfluo un include. Se un fornitore offre più di un’opzione SPF, scegli quella che documentano per il tuo caso d’uso invece di incollare ogni record che riesci a trovare.

Se il record è ancora troppo grande, la risposta non è un secondo record SPF. La risposta è ridurre il numero di percorsi di invio autorizzati o, in alcuni casi, utilizzare un sottodominio per un flusso di posta separato in modo che il record SPF del dominio principale rimanga gestibile.

Se aggiungi un nuovo mittente, trattalo come una revisione del cambio DNS. Conferma che il mittente sia ancora necessario, aggiorna il singolo record SPF e controlla il conteggio dei lookup prima di salvare.

Come verificare che il tuo record SPF funzioni

Una volta salvato il record, non dare per scontato di aver finito. La verifica è dove catturi gli errori silenziosi, specialmente se il tuo pannello DNS ha accettato la voce ma la sintassi o il conteggio dei lookup è ancora sbagliato.

Usa prima un validatore

Inizia con un controllo SPF pubblico come MxToolbox o dmarcian SPF Surveyor. Questi sono utili perché non confermano solo che esiste un record TXT. Ispezionano anche la struttura e, nel caso di lookup più avanzati, ti aiutano a vedere se i tuoi include creano troppi lookup DNS.

Inserisci il nome del tuo dominio e rivedi attentamente il risultato. Stai cercando tre cose:

• Il record viene trovato: lo strumento può vedere il tuo record TXT SPF nel DNS pubblico.
• La sintassi è valida: nessun meccanismo malformato, spazi dispersi o voci SPF duplicate.
• La catena è gestibile: gli include non si espandono in un risultato rotto.

Come appare un buon risultato

Un controllo sano solitamente sembra noioso, ed è esattamente ciò che vuoi. Lo strumento trova un record SPF, lo analizza in modo pulito e non segnala un errore permanente.

Un risultato fallimentare solitamente rientra in uno di questi secchi:

• Nessun record SPF trovato: il record non si è ancora propagato, è stato salvato sotto l’host sbagliato o non è mai stato pubblicato.
• Trovati record SPF multipli: hai aggiunto un secondo record TXT v=spf1 invece di modificare quello esistente.
• Troppi lookup: la tua lista combinata di mittenti è troppo grande o troppo nidificata.

Controlla anche un’email dal vivo

I validatori sono buoni per la struttura. Un messaggio reale conferma il comportamento.

Invia un’email di prova a una casella di posta Gmail a cui puoi accedere. Apri il messaggio, usa l’opzione di Gmail per visualizzare l’originale del messaggio e ispeziona i risultati dell’autenticazione. Se l’SPF passa, è un forte segno che il tuo DNS pubblico e il tuo percorso di invio reale sono allineati.

Gli strumenti di validazione ti dicono se il record DNS è pubblicabile. Un test dal vivo ti dice se il tuo flusso di posta reale corrisponde alla politica DNS.

Se il validatore passa ma i messaggi dal vivo continuano a comportarsi male, il problema potrebbe risiedere altrove nel tuo stack di autenticazione piuttosto che solo nell’SPF.

Risoluzione dei problemi comuni del record SPF

I problemi SPF diventano solitamente evidenti subito dopo una modifica. Una piccola impresa inizia a inviare proposte da Google Workspace, aggiunge uno strumento di mail merge, poi nota che le risposte rallentano o i messaggi finiscono nello spam. In pratica, il problema è spesso un errore DNS, non un complicato problema di posta.

Trovati record SPF multipli

Sintomo: il tuo validatore segnala record SPF multipli o i server riceventi restituiscono un errore SPF permanente.

Causa: il tuo dominio ha più di un record TXT che inizia con v=spf1. Vedo questo dopo che un’azienda aggiunge un secondo mittente, come un CRM o una piattaforma di outreach, e la guida alla configurazione del nuovo fornitore viene seguita alla lettera. L’SPF non unisce quei record. I riceventi vedono il conflitto e lo trattano come non valido.

Soluzione: mantieni un record SPF per il dominio e raggruppa ogni mittente approvato in quella singola voce TXT. Se hai già record separati, scegline uno come master, combina i meccanismi necessari, poi elimina gli extra.

Troppi lookup DNS

Sintomo: il record sembra completo, ma l’SPF fallisce comunque con un limite di lookup o un risultato di errore permanente.

Causa: i controlli SPF possono seguire solo un numero limitato di lookup DNS. Questo è l’errore che le guide base all’SPF di Gmail spesso saltano. Appare in ambienti reali dove Google Workspace è solo un mittente tra molti, specialmente se usi anche software di mail merge, un help desk, un sistema di fatturazione e una piattaforma di marketing dallo stesso dominio. Ogni include: può tirare dentro altri include sotto di sé, quindi un record che sembra breve può comunque superare il limite.

Soluzione: riduci la lista dei mittenti prima di provare qualsiasi cosa ingegnosa. Rimuovi i servizi che non inviano più posta per il tuo dominio. Chiedi a ogni fornitore se tutti i loro include pubblicati sono necessari per il tuo caso d’uso. Se il tuo stack è ancora troppo grande, dividi i flussi di posta per sottodominio. Ad esempio, mantieni l’email del personale regolare sul tuo dominio principale e sposta l’outreach o la posta di massa su un sottodominio con la sua politica SPF. Quell’approccio è spesso la correzione più pulita in una configurazione a mittenti multipli perché riduce la pressione sui lookup e impedisce a un record gonfio di rompere tutto il resto.

Problemi di sintassi e record mancanti

Sintomo: il record esiste nel DNS, ma il validatore segnala errori di formattazione o non viene trovato alcun record SPF.

Causa: questo deriva solitamente da un cattivo copia-incolla, dal valore host sbagliato o dalla pubblicazione della stringa SPF nel campo sbagliato. In cPanel, GoDaddy, Cloudflare e nei sostituti di Google Domains, le etichette differiscono appena abbastanza da confondere gli amministratori alle prime armi. Un record destinato al dominio radice potrebbe essere inserito sotto www, o il valore TXT potrebbe essere diviso in modo errato.

Soluzione: confronta il valore TXT pubblicato con il record previsto carattere per carattere. Conferma che l’host sia corretto per il dominio che stai autenticando e assicurati di aver creato un record TXT, non un altro tipo di record. Se la sintassi va bene ma la posta fallisce comunque, rivedi la più ampia configurazione dell’autenticazione email per domini personalizzati, perché il record SPF potrebbe essere valido mentre un altro controllo di autenticazione sta causando il problema.

Un ordine pratico di risoluzione dei problemi

Usa questo ordine quando l’SPF si rompe:

1. Controlla la presenza di record SPF duplicati. Questo è il problema più veloce da confermare e risolvere.
2. Rivedi attentamente il testo del record. Cerca refusi, spazi mancanti, virgolette extra o l’host sbagliato.
3. Mappa ogni servizio di invio. Includi Google Workspace, strumenti di mail merge, CRM, piattaforme di supporto e qualsiasi altra cosa che invii come tuo dominio.
4. Conta gli include pesanti in termini di lookup. Se la lista è affollata, semplificala o sposta alcuni mittenti su un sottodominio.

Questo ordine fa risparmiare tempo perché corrisponde a come l’SPF fallisce solitamente sul campo. I piccoli team spesso presumono che lo strumento più recente abbia causato il problema, ma il vecchio disordine DNS è altrettanto comune. Se desideri una lista di controllo operativa più ampia mentre fai pulizia, la guida alla sicurezza email di Simply Tech Today è un riferimento utile.

Oltre l’SPF: i tuoi prossimi passi nell’autenticazione email

Una piccola impresa può pubblicare un record SPF corretto e vedere comunque i messaggi finire nello spam una volta che fatture, outreach e follow-up iniziano a uscire da sistemi diversi. Ciò accade solitamente in configurazioni miste, specialmente quando Google Workspace gestisce la posta quotidiana e un altro strumento invia campagne o mail merge dallo stesso dominio.

L’SPF copre solo una parte della decisione che prende un server di posta ricevente. Controlla se il server mittente è autorizzato a usare il tuo dominio. Questo è importante, ma non prova che il messaggio sia stato firmato correttamente né dice al server ricevente cosa fare quando l’autenticazione fallisce.

È qui che entrano in gioco DKIM e DMARC, e contano ancora di più negli ambienti con mittenti multipli.

DKIM aggiunge una firma crittografica al messaggio in modo che i server riceventi possano confermare che il messaggio è legittimo e non è stato alterato dopo aver lasciato il tuo sistema. DMARC si posiziona sopra SPF e DKIM e dice ai provider di posta come valutare quei controlli per il tuo dominio. Ti fornisce anche report, che sono spesso la prima visione chiara di un mittente che avevi dimenticato stesse usando il tuo dominio.

Questo è il punto che molte guide base all’SPF tralasciano. Se usi Google Workspace, uno strumento di mail merge, un CRM e una piattaforma di supporto, l’SPF può diventare difficile da mantenere a causa del limite di 10 lookup. DKIM aiuta a ridurre quanto devi fare affidamento solo sull’SPF, e DMARC ti fornisce uno strato di politica in modo che il tuo dominio non sia giudicato solo da un record TXT affollato.

Per il prossimo passo tecnico dopo l’SPF, rivedi questa guida all’autenticazione email per domini personalizzati. Fornisce il percorso di configurazione pratica per DKIM e DMARC dopo che il tuo record SPF è a posto.

Se desideri una lista di controllo operativa più ampia, la guida alla sicurezza email di Simply Tech Today è una lettura complementare utile.

Il punto pratico è semplice. L’SPF mette in atto l’autorizzazione. DKIM prova l’integrità del messaggio. DMARC ti dà controllo, visibilità e un modo più sicuro per gestire un dominio che invia posta da più di un sistema.