Guida alla configurazione del record SPF su GoDaddy per il 2026

Hai inserito il record in GoDaddy, l’ultima campagna è partita e Gmail ha continuato a trattare metà dei tuoi invii come se provenissero da uno sconosciuto. Poi qualcuno aggiunge un CRM, uno strumento per newsletter e una piattaforma transazionale, e l’intera configurazione inizia a comportarsi come un groviglio di cavi sparsi. È solitamente a questo punto che un record SPF su GoDaddy smette di essere una semplice casella da spuntare e diventa l’elemento che mantiene integra la tua deliverability.

La parte dolorosa è che i fallimenti SPF raramente si annunciano in modo chiaro. Un mittente viene aggiunto, il DNS viene modificato una volta e, settimane dopo, il team nota che le email finiscono nello spam, riscontra errori di autenticazione o scopre che una piattaforma funziona mentre un’altra è sparita dalla lista. Se ti suona familiare, hai a che fare con la gestione del DNS, la struttura del record e il limite dei 10 lookup, non solo con semplici problemi di posta elettronica.

Perché il tuo record SPF su GoDaddy è più importante di quanto pensi

L’SPF è semplice nel concetto ma brutale nella pratica. Un server ricevente controlla la policy pubblicata dal dominio nel DNS e chiede se il server mittente è autorizzato a inviare email per quel dominio. Se la risposta non coincide, il messaggio può essere trattato come non autorizzato anche quando il mittente è legittimo.

Ecco perché un record SPF su GoDaddy non configurato correttamente fa più danni di quanto molti realizzino. Sia Microsoft 365 che Google Workspace si affidano a segnali di autenticazione che i provider di posta valutano dietro le quinte, quindi un record SPF mancante o malformato può influenzare la consegna nella posta in arrivo molto prima che qualcuno noti un fallimento visibile. La differenza tra hardfail e softfail è fondamentale qui, perché il qualificatore finale indica ai destinatari se la posta non autorizzata debba essere rifiutata categoricamente o trattata con sospetto.

La parte che la maggior parte dei team trascura

L’SPF non dice solo “questo dominio è tuo”. Dice “questo mittente è nella lista approvata pubblicata nel DNS”. È anche qui che l’allineamento SPF inizia ad avere importanza, perché il DMARC controlla successivamente se il dominio visibile nel campo From coincide con la fonte autenticata.

Regola pratica: se un mittente è stato aggiunto allo stack dopo la creazione del record SPF originale, quel mittente è probabilmente diventato il problema, a meno che anche il record DNS non sia stato aggiornato.

Le linee guida di GoDaddy riflettono l’approccio moderno, in cui l’SPF viene pubblicato come record TXT anziché come un tipo di record SPF separato, e il flusso di lavoro si concentra sulla modifica del DNS all’interno del portfolio domini. Quella configurazione sembra ordinaria, ma è esattamente il motivo per cui l’SPF si rompe così spesso. Il record è facile da aggiungere una volta e facile da dimenticare dopo che il prossimo strumento viene approvato.

Aggiungere il tuo primo record SPF nel DNS di GoDaddy

Inizia dal Portfolio Domini, apri il DNS e aggiungi un record di tipo TXT. L’aiuto di GoDaddy mostra questo percorso per la configurazione SPF, con la policy SPF inserita nel campo Valore e l’host impostato sulla radice (root) quando la policy si applica all’intero dominio, mentre il TTL rimane su Predefinito nell’esempio documentato per i record di posta correlati Guida di GoDaddy al record SPF Campi dei record DNS di GoDaddy per l’autenticazione email.

I campi che contano

Il Tipo dovrebbe essere TXT, non SPF. La documentazione di GoDaddy utilizza TXT perché è il formato di pubblicazione standard per l’SPF nel DNS moderno, e questa scelta evita ambiguità tra i validatori.

Il Nome dovrebbe solitamente essere @ per una policy del dominio principale. Questo indica a GoDaddy che il record appartiene alla radice del dominio anziché a un sottodominio. Il Valore è dove risiede la stringa SPF, quindi è lì che incolli la policy stessa.

Il TTL può rimanere su Predefinito se stai seguendo la configurazione documentata di GoDaddy, specialmente quando non sei nel bel mezzo di una risoluzione dei problemi. È facile trascurare i nomi esatti dei campi, ma sono la differenza tra un record che risiede alla radice del dominio e uno che si trova in un posto inutile.

Un semplice esempio di posta gestita da GoDaddy appare come v=spf1 include:secureserver.net -all, che è il formato mostrato da GoDaddy per l’email in hosting. Se stai autorizzando solo una fonte mittente, questa è la forma che vuoi: un record, una policy, un posto.

Per una variante specifica di Gmail, questa guida SPF per utenti Gmail mostra la stessa logica “TXT-first” in pratica.

Se imposti il tipo di record come qualcosa di diverso da TXT, o lasci l’host vuoto quando la policy deve risiedere alla radice, il record potrebbe apparire nell’interfaccia ma fallire comunque a livello DNS.

Più avanti nel processo, l’interfaccia di GoDaddy diventa meno importante rispetto alla zona DNS autorevole, ma la prima vittoria consiste nell’inserire il record nel campo giusto, con il tipo giusto, all’host giusto.

Sintassi SPF per i mittenti che utilizzi

Molte organizzazioni non utilizzano un solo mittente. Gestiscono una casella di posta principale, una piattaforma di marketing, un CRM e un sistema transazionale. Il record SPF è l’unica dichiarazione che li autorizza tutti, quindi il compito reale è scegliere i meccanismi giusti e mantenere la lista abbastanza breve da essere convalidata prima che il DNS di GoDaddy inizi a lavorare contro di te.

Stringhe SPF pronte da copiare per stack di mittenti comuni

Configurazione Mittente	Valore SPF	Lookup utilizzati
Google Workspace	v=spf1 include:_spf.google.com -all	Un include, poi il controllo della policy finale
Microsoft 365	v=spf1 include:spf.protection.outlook.com -all	Un include, poi il controllo della policy finale
Google Workspace più uno strumento di marketing	v=spf1 include:_spf.google.com include:servers.mcsv.net -all	Due include, più eventuali lookup nidificati all’interno dei record inclusi
Microsoft 365 più un mittente transazionale	v=spf1 include:spf.protection.outlook.com include:amazonses.com -all	Due include, più eventuali lookup nidificati all’interno dei record inclusi

Queste stringhe sono utili perché mostrano il modello: un record, una policy, un posto dove controllarlo in GoDaddy. Se il tuo stack inizia con Google Workspace o Microsoft 365 e poi cresce includendo email di marketing e transazionali, il record solitamente smette di riguardare la sintassi e inizia a riguardare quanti lookup DNS ogni provider consuma dietro le quinte.

Cosa fanno i meccanismi

include indica di controllare la policy SPF di un altro dominio ed ereditarne l’autorizzazione. È il meccanismo principale per Google Workspace, Microsoft 365, Mailchimp, SendGrid e piattaforme simili.

ip4 è per indirizzi IP di invio fissi, il che aiuta quando controlli l’IP sorgente e non vuoi dipendere dalla catena di policy di un altro provider. all alla fine imposta la regola per tutto ciò che non è già autorizzato, e il qualificatore decide quanto rigoroso debba essere il fallimento.

Regola pratica: usa una terminazione più rigorosa quando la tua lista di mittenti è stabile, e una più morbida solo mentre stai ancora pulendo lo stack.

Una prospettiva esterna utile sulla pianificazione dei mittenti è il consiglio per le campagne email delle piccole imprese, poiché i team di campagna spesso aggiungono strumenti senza verificarne l’impatto sul DNS.

La parte che mette in difficoltà le configurazioni reali su GoDaddy è il budget dei lookup. Ogni include extra consuma quel budget, e un record può sembrare pulito pur fallendo perché la catena diventa troppo profonda. Costruisci la sintassi attorno allo stack che utilizzi, non a quello che vorresti utilizzare.

Unire più mittenti senza superare il limite di lookup

La principale modalità di fallimento con un record SPF su GoDaddy non è la sintassi, ma l’accumulo. Un dominio inizia con un mittente, poi il marketing ne aggiunge un altro, poi le vendite aggiungono un CRM, poi le operazioni aggiungono una piattaforma transazionale, e nessuno nota che l’SPF sta ora cercando di convalidare più sistemi di quanto lo standard consenta.

La regola è netta e non ammette eccezioni. Non pubblicare mai più di un record SPF con lo stesso nome. Se esistono due record TXT SPF per lo stesso dominio, i destinatari possono trattare il risultato come non valido o ambiguo, il che significa che il record che pensavi stesse aiutando potrebbe essere la causa del fallimento dell’autenticazione.

Come funziona il processo di unione

Inizia elencando ogni mittente legittimo. Poi uniscili in un’unica policy TXT, utilizzando le istruzioni include dove il provider gestisce la propria infrastruttura di invio. Se hai già un record in GoDaddy, modifica quello invece di crearne una seconda copia.

La seconda trappola è la nidificazione. Un singolo include può nascondere diversi altri lookup all’interno della policy SPF del provider, ed è per questo che i domini possono esaurire il budget più velocemente di quanto il team si aspetti. Le linee guida focalizzate su GoDaddy avvertono gli utenti di rimanere sotto il limite di 10 lookup DNS, e quel limite si applica durante la valutazione, non a posteriori Best practice per la configurazione del record SPF per i domini GoDaddy Guida SPF 2026 per i domini GoDaddy.

Un modello operativo più pulito

• Verifica prima ogni mittente: rimuovi i vecchi strumenti che non inviano più email, perché gli include obsoleti consumano comunque budget.
• Consolida in un’unica policy: mantieni tutta l’autorizzazione in un singolo record TXT con il nome corretto.
• Verifica il conteggio dei lookup prima di salvare: un record che sembra ordinato può comunque fallire se gli include nidificati lo spingono oltre il limite.

Mail Merge for Gmail si adatta perfettamente a questa logica. Invia tramite l’infrastruttura autenticata di Google, quindi non ha bisogno di un proprio include separato e non aggiunge nulla al budget SPF quando stai già autorizzando Google Workspace.

Il motivo per cui questo è così importante è semplice. Un team può rimanere sotto il limite per mesi, poi un nuovo fornitore spinge il record oltre il limite e l’SPF inizia a fallire senza alcun errore DNS evidente nell’interfaccia di GoDaddy.

Verificare che il tuo record funzioni davvero

Salvare il record in GoDaddy non è una prova. Significa solo che la modifica è stata inserita, non che la zona autorevole la stia servendo, non che le cache si siano aggiornate e non che la policy venga analizzata correttamente.

Tre controlli, tre risposte diverse

Il primo controllo è una ricerca DNS sulla zona attiva. Una query dig o nslookup ti dice cosa stanno restituendo i server dei nomi autorevoli, il che è importante perché l’interfaccia di GoDaddy può mostrare un valore prima che la propagazione sia terminata, e non ti dirà se un altro host DNS possiede la zona.

Il secondo controllo è un parser SPF come il controllo SPF di MXToolbox. Quel tipo di strumento è utile perché legge la sintassi e conta i lookup contemporaneamente, che è esattamente dove appaiono gli include nidificati e le catene fuori limite.

Il terzo controllo è l’evidenza a livello di messaggio. Invia un test a Gmail, apri il messaggio originale e ispeziona le intestazioni. La riga Authentication-Results di solito mostrerà se l’SPF è passato o fallito per il dominio mittente, il che ti dice come un provider di posta ha valutato il messaggio, non solo cosa dice il DNS.

Regola pratica: se il DNS sembra corretto ma le intestazioni falliscono comunque, il problema è solitamente a livello di validazione, non nell’interfaccia di GoDaddy.

Esiste anche una realtà di propagazione che i team ignorano a proprio rischio. Il comportamento TTL di GoDaddy è solitamente veloce, ma le modifiche DNS ai casi limite possono richiedere tempo per stabilizzarsi tra i resolver. Se stai spostando record tra provider, conferma prima i server dei nomi autorevoli e poi convalida rispetto alla zona effettiva, non al pannello di controllo che hai usato. Per tracciare i messaggi dall’inizio alla fine, questa guida al tracciamento delle email è il complemento ideale.

Dal superamento dell’SPF alla completa autenticazione email

Il superamento dell’SPF è rassicurante, ma non risolve l’intero problema. L’SPF autorizza solo le fonti di invio, non firma il messaggio e non impedisce che un messaggio venga alterato dopo aver lasciato il mittente. Ecco perché l’SPF da solo può ancora lasciare casi limite di inoltro e buchi per l’impersonificazione.

Dove si inseriscono DKIM e DMARC

DKIM aggiunge una firma crittografica al messaggio stesso. Nel DNS gestito da GoDaddy, ciò significa tipicamente un record TXT sotto l’host del selettore, e Google Workspace utilizza comunemente google._domainkey come parte di tale configurazione.

DMARC si posiziona sopra SPF e DKIM. Indica ai sistemi riceventi cosa fare quando l’autenticazione fallisce e dove inviare i report, solitamente tramite un record TXT su _dmarc nel dominio. Senza DMARC, i provider di posta non hanno una policy condivisa da seguire quando SPF o DKIM non coincidono.

Il punto chiave è che l’SPF è solo uno strato di fiducia. Un messaggio contraffatto può ancora sfruttare un allineamento debole se DKIM non è attivo, e un messaggio inoltrato può ancora comportarsi diversamente da un invio originale anche quando l’SPF era pulito alla fonte.

Lo stack pratico è semplice. L’SPF autorizza il mittente, DKIM firma il messaggio e DMARC dice ai destinatari come agire quando i due non sono d’accordo. La sezione precedente sulla verifica è importante qui perché non vuoi irrigidire la policy prima di sapere che ogni mittente legittimo si sta autenticando.

Per un approfondimento sull’intero stack, questa guida all’autenticazione email collega SPF, DKIM e DMARC in un unico flusso di lavoro.

Mantenere l’SPF pulito durante le campagne di Mail Merge

Una campagna di mail merge mette rapidamente sotto pressione il lavoro sul DNS. I team di vendita, recruiting o eventi possono inviare una sequenza pulita da Gmail un giorno e poi incolpare il contenuto la settimana successiva quando le risposte diminuiscono, anche se il problema più profondo era la deriva dell’autenticazione.

Mail Merge for Gmail invia tramite l’infrastruttura autenticata di Google, quindi non crea un mittente separato che necessita di un proprio include SPF. Il rischio maggiore è che lo stack circostante cambi, il proprietario del dominio aggiunga un’altra piattaforma e i provider di posta inizino a valutare una cronologia dei messaggi che non sembra più coerente.

Una checklist pre-campagna che aiuta davvero

• Conferma che l’SPF passi per l’account Google mittente: testa l’esatta casella di posta che invierà la campagna, non un alias casuale.
• Conferma che DKIM sia abilitato nell’amministrazione di Google Workspace: l’SPF da solo è troppo fragile per la posta inoltrata o riconfezionata.
• Conferma che DMARC sia almeno p=none con la reportistica attiva: questo ti dà visibilità prima di rendere più rigorosa la policy.

Un risultato SPF verde da solo non significa che la campagna sia sicura da lanciare. Significa solo che il mittente corrispondeva all’attuale policy DNS in quel momento.

L’abitudine migliore è trattare il record SPF come un impianto idraulico. Controllalo prima della campagna, controllalo quando viene aggiunto un nuovo mittente e ricontrollalo quando una piattaforma cambia il suo percorso di invio. È così che eviti che un record SPF su GoDaddy invecchi diventando un problema di deliverability.

---

Mail Merge for Gmail aiuta i team a inviare campagne personalizzate da Gmail mantenendo il percorso di invio legato a Google Workspace, il che rende l’SPF più facile da gestire quando lo stack del dominio diventa affollato. Se stai pulendo una configurazione DNS su GoDaddy prima della tua prossima attività di outreach, visita Mail Merge for Gmail e rivedi come si inserisce in un flusso di lavoro che dipende già dal fatto che SPF, DKIM e DMARC rimangano puliti.