Defaults.Exposed › Correzioni › Guides

L'SPF ha smesso di funzionare dopo il cambio di provider email — la soluzione per la migrazione (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.

Di solito l’SPF si rompe dopo un cambio di provider email perché il record del nuovo provider è stato aggiunto accanto a quello vecchio. Due record v=spf1 sono un errore permanente — l’SPF si annulla completamente. 1.013.416 domini — circa uno su 138 di quelli che tentano l’SPF — si trovano in quello stato, secondo il censimento Defaults.Exposed di 261 milioni di domini. Li unisca in uno solo.

La soluzione richiede circa dieci minuti: scansioni il dominio per vedere esattamente che cosa ha lasciato indietro la migrazione, elenchi ogni record SPF sui suoi nameserver autoritativi, li unisca in un unico record che includa solo il nuovo provider e riverifichi con dig. Questa guida percorre ogni passo, più i controlli su DKIM e nameserver che la maggior parte delle migrazioni dimentica.

Perché l’SPF si è rotto proprio dopo la migrazione?

Perché la guida di configurazione del nuovo provider diceva “aggiunga questo record TXT” — e lei l’ha fatto, accanto a quello vecchio. È l’unica cosa che lo standard SPF non permette. La RFC 7208 (§3.2, esito di errore prescritto al §4.5) consente esattamente un record v=spf1 per dominio; un ricevente che ne trova due o più deve restituire PermError invece di indovinare quale sia quello autoritativo. PermError significa che l’SPF è annullato: non il vecchio record, non il nuovo, nessun SPF del tutto.

E non finisce lì. Il DMARC tratta un PermError come un fail sul fronte SPF, quindi la sua posta ora dipende interamente dal DKIM. Se nemmeno il DKIM del nuovo provider è ancora configurato — cosa comune a metà migrazione — sta inviando senza autenticazione esattamente nel momento in cui ha cambiato infrastruttura, cioè quando i riceventi la scrutano con più severità.

Questo è il copia-incolla che annulla la protezione quando si cambia provider, e non è raro: 1.013.416 domini pubblicano due o più record SPF in questo momento — circa uno su 138 della popolazione di 139 milioni di domini che tenta l’SPF, secondo il censimento Defaults.Exposed di 261 milioni di domini (dati aggiornati al 2026-06-29). I numeri completi sulla trappola dei due record hanno un rapporto dedicato; questa pagina è la soluzione procedurale.

Che cosa ha lasciato indietro la migrazione?

Cinque residui causano quasi tutti i fallimenti SPF post-migrazione. Li controlli in questo ordine:

Come lo sistemo? La checklist della migrazione

1. Esegua prima la scansione gratuita su defaults.exposed. Legge il suo DNS live e le dice se ha più record SPF, un include mancante o una lacuna DKIM — diagnostichi prima di toccare qualsiasi cosa.

2. Elenchi ogni record SPF sui nameserver autoritativi. dig +short NS yourdomain.com, poi dig +short TXT yourdomain.com @<nameserver> verso uno di essi. Conti le stringhe che iniziano con v=spf1. L’unico conteggio sicuro è 1.

3. Unisca tutto in un unico record. Un record, che inizia con v=spf1, contenente l’include del nuovo provider e ogni altro mittente che usa ancora (strumento di fatturazione, CRM, piattaforma newsletter), un solo -all o ~all finale. Esempio — vecchio Google Workspace, nuovo Microsoft 365, a metà transizione:

   Before:  "v=spf1 include:_spf.google.com ~all"
            "v=spf1 include:spf.protection.outlook.com -all"
   
   After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
   Later:   "v=spf1 include:spf.protection.outlook.com -all"
   

   I valori dei provider e le stranezze dei pannelli DNS sono nelle guide di configurazione per Google Workspace e Microsoft 365.

4. Elimini i record in eccesso. Unire senza eliminare non risolve nulla — il PermError deriva dal conteggio.

5. Mantenga l’include del vecchio provider solo finché il vecchio sistema invia ancora — report programmati, un vecchio connettore CRM, una casella dimenticata. Quando il deflusso è concluso, lo rimuova: un include obsoleto lascia la vecchia infrastruttura autorizzata a inviare a suo nome, e ogni include costa lookup DNS rispetto al limite rigido di 10 dell’SPF — almeno 797.263 domini hanno annullato l’SPF sforando quel limite (censimento, 2026-06-29).

6. Configuri il DKIM del nuovo provider — e non elimini ancora i vecchi selettori. I nuovi selettori firmano la nuova posta; i vecchi devono restare pubblicati finché ogni messaggio firmato con essi non è stato consegnato e gli eventuali inoltri non si sono assestati. Procedura completa in DKIM che fallisce dopo il cambio di strumenti email.

7. Se ha cambiato anche i nameserver, controlli entrambi i set. Le migrazioni DNS spesso viaggiano insieme a quelle email. Interroghi direttamente il vecchio e il nuovo set di NS (dig TXT yourdomain.com @old-ns e @new-ns) — finché la delega del registrar non si è propagata del tutto, alcuni riceventi interrogano ancora i vecchi server, quindi il record corretto deve esistere su qualunque set risponda.

8. Riesegua la scansione e confermi che l’SPF mostri un singolo record valido con esito pass.

Quale dominio controlla davvero l’SPF?

I riceventi valutano l’SPF rispetto al dominio del Return-Path (RFC5321.MailFrom) — l’indirizzo di bounce — non l’intestazione From che i suoi destinatari vedono. Dopo una migrazione questo conta due volte: il nuovo provider potrebbe usare il proprio dominio di bounce finché lei non ne configura uno personalizzato, e un SPF che “passa” su un dominio che non è il suo non sarà allineato per il DMARC. La soluzione per questo è il DKIM del nuovo provider, firmato con il suo dominio.

Migrazione e rebranding allo stesso tempo?

Ha cambiato il dominio oltre al provider? Li tratti come due lavori distinti. Il nuovo dominio ha bisogno dell’intero pacchetto — SPF, DKIM, DMARC — dal primo giorno; usi la checklist email per un nuovo dominio. Il vecchio dominio resta autenticato finché ci passa traffico di inoltro o di risposta, e viene esplicitamente blindato (non semplicemente abbandonato) una volta parcheggiato. Un vecchio dominio con un SPF residuo e mezzo rotto è un bersaglio di spoofing che indossa il suo vecchio nome.

Domande frequenti

Posso tenere due record SPF mentre migro? No. Lo standard non prevede alcun periodo di tolleranza — due record v=spf1 sono un PermError dal momento in cui il secondo esiste, e 1.013.416 domini si trovano in quello stato al censimento (2026-06-29). Lo schema sicuro per la migrazione è un unico record che porta gli include di entrambi i provider durante la sovrapposizione.

Per quanto tempo devo tenere l’include del vecchio provider? Finché nulla invia più attraverso il vecchio provider — tipicamente la durata della sua finestra di sovrapposizione, da giorni a poche settimane. Osservi il Return-Path di tutto ciò che arriva ancora tramite il vecchio sistema; quando quel traffico si ferma, rimuova l’include e ricontrolli il conteggio dei lookup.

Perché un checker mostra ancora il mio vecchio record dopo che l’ho sistemato? La cache DNS rispetta il TTL del record, e se i suoi nameserver sono cambiati, alcuni resolver interrogano ancora il vecchio set. Verifichi direttamente sui nameserver autoritativi con dig TXT yourdomain.com @<ns> — se lì la risposta è corretta, la correzione è fatta e le cache si aggiorneranno. Se è sbagliata su uno dei set di NS, veda “SPF record not found” — le cause reali.

Devo cambiare il DMARC quando cambio provider? Di solito non il record in sé — indica la sua casella per i report e la policy, non il provider. Ma i suoi risultati DMARC dipendono dall’SPF e dal DKIM che ha appena migrato: si aspetti un calo nei report durante il passaggio, e confermi che entrambe le gambe passino prima di irrigidire la policy. Parta da sistemare l’SPF se la scansione mostra che il fronte SPF fallisce ancora.

Invii il rapporto al titolare

Se sta facendo questa migrazione per un cliente, chiuda con le prove. Rilanci la scansione gratuita quando la fusione dei record è attiva e inoltri il rapporto con i voti al titolare dell’azienda: SPF, DKIM e DMARC che passano sul nuovo provider, in linguaggio semplice, con data. È il documento che archivierà per il rinnovo dell’assicurazione cyber e per il prossimo questionario di sicurezza dei fornitori — la prova che la migrazione ha lasciato il dominio meglio autenticato di com’era all’inizio.

Controlli il suo dominio → · DKIM che fallisce dopo il cambio di strumenti email → · “SPF record not found” — le cause reali → · Come assegniamo i voti → · Solo dati aggregati. Dati conservati ed elaborati nell’UE.