DKIM fallisce dopo il cambio di strumento email: la guida alla migrazione di CNAME e selettori (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.

DKIM si rompe dopo un cambio di strumento per due ragioni meccaniche: il Suo pannello DNS ha storpiato i target CNAME del nuovo strumento — di solito accodando la Sua zona — oppure i selettori del vecchio strumento sono stati rimossi prima che la sua posta si esaurisse. Solo il 3,87% dei domini — 10.092.481 — completa la triade SPF+DKIM+DMARC, secondo il censimento Defaults.Exposed su 261.086.232 domini valutati.

L’ordine di intervento: scansioni il dominio, poi controlli il target memorizzato di ogni nuovo CNAME con dig — un target che termina con il Suo stesso nome di dominio è la pistola fumante. Ripari i record sui nameserver autoritativi, confermi che il nuovo strumento firma e passa prima di instradarci la posta reale, e mantenga pubblicati i selettori del vecchio strumento finché il suo traffico non si esaurisce.

Perché DKIM si è rotto quando ha cambiato strumento?

Nulla di DKIM in sé è cambiato — sono cambiati i Suoi selettori. Il vecchio strumento firmava con i suoi selettori; il nuovo firma con selettori diversi, di solito delegati tramite due o tre record CNAME aggiunti durante l’attivazione. Quattro trappole spiegano quasi tutti i fallimenti DKIM post-migrazione:

Il Suo pannello DNS ha accodato la Sua zona al target del CNAME. Molti pannelli trattano qualsiasi hostname incollato come relativo e memorizzano in silenzio target.provider.com.suodominio.com invece di target.provider.com. Il record esiste, il pannello mostra la spunta verde, e non risolve verso nulla.
La confusione del punto finale. Alcuni pannelli richiedono il punto finale (target.provider.com.) per dire “assoluto — smetti di accodare la mia zona”; altri rifiutano il punto come non valido e gestiscono l’assolutezza da soli. Lo stesso valore incollato è giusto in un pannello e storpiato in quello accanto.
I selettori del vecchio strumento sono stati cancellati il giorno del passaggio. La posta che il vecchio strumento aveva già firmato resta nelle code di retry e nei percorsi di inoltro per giorni; rimuovere i suoi selettori — o chiudere il vecchio account, che uccide i suoi CNAME delegati — rompe retroattivamente quella posta.
Ha verificato sui nameserver sbagliati. Se la migrazione includeva un cambio di nameserver, i record corretti possono esistere su un set di NS mentre i destinatari interrogano ancora l’altro.

Solo il 51,84% dei 261 milioni di domini nel censimento presenta una chiave DKIM rintracciabile al momento della scansione (dati aggiornati al 2026-06-29).

La stessa migrazione di solito lascia anche detriti SPF — 1.013.416 domini, circa 1 su 138 fra quelli che tentano l’SPF, hanno due record v=spf1, il segno classico che un cambio di provider ha aggiunto un record invece di fonderne uno. Quel lato del trasloco ha la sua guida: l’SPF ha smesso di funzionare dopo il cambio di provider email.

Come riconosco un record CNAME storpiato?

Non si fidi del pannello — chieda al DNS cosa ha davvero memorizzato. Interroghi il target del CNAME per ogni selettore che il nuovo strumento Le ha dato. Un esempio illustrativo, che imita un selettore delegato in stile SendGrid (la forma del target del Suo provider sarà diversa):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

Il provider aveva chiesto s1.domainkey.u1234567.wl123.sendgrid.net — ma il target memorizzato termina con .yourdomain.com. Il pannello ha accodato la zona; quel nome non risolve verso nulla, quindi i destinatari non trovano alcuna chiave. La versione sana:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Un singolo punto finale nell’output di dig è normale — indica un nome pienamente qualificato.) Se il target è giusto, lo segua per un salto: dig TXT s1._domainkey.yourdomain.com +short dovrebbe restituire la chiave del provider. Risposta vuota con un CNAME corretto significa che il problema è sul lato provider della delega — completi il loro passaggio di verifica, o veda DKIM “no key for signature” per la diagnosi a livello di selettore.

Il runbook della migrazione: prima, durante, dopo

Il fallimento di solito non sta nei record — sta nell’ordine. Le migrazioni DKIM vanno male al momento del passaggio perché la verifica avviene dopo lo scambio, quando la posta reale sta già fallendo.

Fase	Cosa fare	Condizione prima di procedere
Prima del passaggio	Aggiunga i CNAME DKIM del nuovo strumento (e i record del dominio di bounce), poi li metta alla prova: `dig` sul target memorizzato di ogni CNAME da fuori la Sua rete, completi il passaggio di verifica dello strumento e invii un test attraverso il nuovo strumento verso una casella sotto il Suo controllo	Il messaggio di prova mostra `dkim=pass` con `d=` = il Suo dominio — non instradi mai posta reale attraverso uno strumento non verificato
Il giorno del passaggio	Sposti il traffico reale sul nuovo strumento. Non tocchi nulla del vecchio: lasci vivi i suoi selettori, i CNAME e l’account	La posta del nuovo strumento passa presso destinatari reali; il vecchio continua a passare per tutto ciò che ancora vi transita
Dopo l’esaurimento	Osservi i report aggregati DMARC finché i selettori del vecchio strumento non smettono di comparire (code di retry e inoltri girano per giorni — conceda una settimana o più), poi ritiri i suoi record e l’account	Vecchi selettori assenti dai report da ≥ 7 giorni prima della rimozione

La riga in grassetto è dove le migrazioni si salvano o si perdono: ogni controllo lì dentro si può fare giorni prima del passaggio, con zero rischio per la posta in produzione. La meccanica del ritiro dei selettori — incluso perché ripubblicare con un p= vuoto batte la cancellazione — è trattata nel runbook di rotazione; questa tabella riguarda la sequenza del cambio di strumento in sé.

Come sistemo DKIM dopo il passaggio?

Esegua la scansione gratuita su defaults.exposed prima di toccare il DNS. Legge i Suoi record in produzione e mostra cosa vedono davvero i destinatari — inclusi i target CNAME con la zona accodata e i selettori che non risolvono.
Elenchi i record DKIM che il nuovo strumento si aspetta. Dalla sua console di amministrazione — per i provider di posta, le guide di configurazione Google Workspace e Microsoft 365 mostrano dove; gli strumenti per newsletter e CRM elencano i loro CNAME sotto l’autenticazione del dominio (veda le email di Mailchimp/Brevo/Klaviyo falliscono DMARC).
Controlli il valore memorizzato di ogni record con dig CNAME <name> +short e lo confronti carattere per carattere con quello richiesto dallo strumento. Un target che termina con il Suo dominio = zona accodata; lo reinserisca, e se il pannello continua ad accodare, aggiunga il punto finale (o lo rimuova, se il pannello rifiuta i punti).
Verifichi sui nameserver autoritativi. dig +short NS yourdomain.com, poi ripeta i controlli sui CNAME con @<quel nameserver>. Se la migrazione ha cambiato i nameserver, controlli entrambi i set — i destinatari potrebbero interrogare ancora il vecchio finché la delega non si propaga.
Riesegua la verifica dello strumento e invii un messaggio di prova. L’intestazione Authentication-Results deve mostrare dkim=pass con d= uguale al Suo dominio — un pass sul dominio di default dello strumento non si allinea per DMARC.
Lasci pubblicati i selettori del vecchio strumento finché la sua posta non si esaurisce, poi li ritiri deliberatamente. Poi riesegua la scansione e lavori su tutto il resto segnalato nella pagina sistemare DKIM.

Domande frequenti

Il punto finale sul mio CNAME DKIM serve o no? Dipende interamente dal pannello. Il punto significa “nome assoluto — non accodare la mia zona”; alcuni pannelli lo richiedono, alcuni lo aggiungono per Lei, alcuni lo rifiutano. L’unico test che conta è l’output di dig CNAME <selector>._domainkey.yourdomain.com +short dopo il salvataggio: se il target termina con il Suo dominio, il pannello ha accodato la zona e Le serve il punto (o un formato di inserimento diverso).

Posso cancellare i record DKIM del vecchio strumento il giorno del passaggio? No. La posta firmata dal vecchio strumento è ancora nelle code di retry e nei percorsi di inoltro, e cancellare la chiave a cui punta rompe quei messaggi retroattivamente. Mantenga vivi i vecchi selettori finché non smettono di comparire nei Suoi report aggregati DMARC — una settimana o più — e non chiuda nemmeno il vecchio account prima di allora.

Il mio pannello DNS e il nuovo strumento dicono entrambi “verificato”, ma i destinatari falliscono ancora DKIM. Come? Due casi comuni: lo strumento ha verificato contro un controllo in cache mentre i nameserver autoritativi servono altro (li interroghi direttamente con dig @<ns>), oppure DKIM passa ma sul dominio di firma di default dello strumento anziché sul Suo, quindi DMARC fallisce comunque l’allineamento. La scansione distingue i due casi.

I record DKIM di entrambi gli strumenti possono coesistere durante la sovrapposizione? Sì — e dovrebbero. DKIM non ha alcuna regola del record unico: ogni selettore è un nome DNS a sé, quindi i record dei due strumenti convivono senza conflitti, il che rende gratuita da seguire la regola tieni-i-vecchi-selettori-fino-all’esaurimento. (L’SPF è l’opposto — due record v=spf1 lo annullano, motivo per cui la guida alla migrazione SPF parla di fusione.)

Invii il report al titolare

Se sta conducendo questa migrazione per un cliente o per il Suo datore di lavoro, la chiuda con le prove. Quando il nuovo strumento firma e si allinea, riesegua la scansione gratuita e inoltri il report con il voto al titolare dell’azienda: la prova datata, in linguaggio semplice, che il passaggio ha lasciato il dominio pienamente autenticato. È il documento che gli servirà per il rinnovo dell’assicurazione cyber e per il prossimo questionario di sicurezza dei fornitori — trasforma “la migrazione è finita” da affermazione a documento.

Controlli il Suo DKIM gratis

Veda se i selettori del Suo nuovo strumento risolvono — ed esattamente cosa correggere — in privato e visibile solo al titolare.

Controlli il Suo dominio → · L’SPF si è rotto dopo il cambio di provider → · Sistemare DKIM → · Configurare DKIM su Google Workspace → · Solo dati aggregati. Dati conservati e trattati nell’UE.