Defaults.Exposed › Correzioni › Guides

DKIM "No Key for Signature": correzioni di selettore e rotazione (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.

“No key for signature” significa che il destinatario ha interrogato il record DNS a cui punta la Sua firma DKIM — selector._domainkey.yourdomain — e non ha trovato alcuna chiave: non è mai stata pubblicata, oppure è stata eliminata a metà rotazione. Pubblichi il selettore che il Suo firmatario usa davvero. Solo 10.092.481 domini — il 3,87% — completano la triade SPF+DKIM+DMARC, secondo il censimento Defaults.Exposed su 261.086.232 domini valutati.

La correzione è un solo record DNS, individuato in una sola intestazione. Legga i tag s= e d= da una vera intestazione DKIM-Signature per scoprire con quale selettore la Sua posta viene firmata, pubblichi (o ripari) esattamente quel record e preferisca la delega tramite CNAME, così il provider ruota le chiavi al posto Suo. Poi ruoti seguendo il runbook qui sotto — questo errore di solito significa che qualcuno ha eliminato un vecchio selettore troppo presto.

Cosa significa “dkim no key for signature”?

Ogni firma DKIM porta due tag che dicono al destinatario dove recuperare la chiave pubblica: d= (dominio firmatario) e s= (selettore). Il destinatario interroga un unico nome DNS costruito da questi — s._domainkey.d — per ottenere la chiave. “No key for signature” significa che quella interrogazione è tornata vuota: la firma esiste, ma la chiave che indica no.

La formulazione compare nelle intestazioni Authentication-Results e nei report aggregati DMARC — la dicitura esatta varia da destinatario a destinatario, ma due varianti contano:

Un temperror isolato è “meteo DNS”. Un permerror — o un temperror che si ripete per giorni e presso più destinatari — significa che il record a cui punta la firma non è nella Sua zona. Ed è l’argomento di questa guida.

La conseguenza: una firma non verificabile conta come nessun DKIM, quindi DMARC ripiega sul solo SPF — e SPF si rompe con l’inoltro. Se la firma è presente ma non valida anziché mancante (body hash, chiave alterata), è un guasto diverso — veda “DKIM signature not valid”.

Come trovo con quale selettore viene firmata la mia posta?

Non tiri a indovinare dalla documentazione del provider — lo legga da un messaggio reale:

1. Invii un messaggio dal sistema interessato a una casella che controlla (un indirizzo Gmail va benissimo).
2. Apra il sorgente grezzo (“Mostra originale” in Gmail, “Visualizza origine messaggio” in Outlook).
3. Trovi l’intestazione DKIM-Signature: e legga due tag: s= è il selettore, d= è il dominio firmatario. Un esempio illustrativo: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
4. Il record che il destinatario interroga è s._domainkey.d — qui, mail2026._domainkey.yourdomain.com. Lo verifichi Lei stesso: dig TXT mail2026._domainkey.yourdomain.com +short. Risposta vuota = l’errore è reale per ogni destinatario.
5. Ripeta per ciascun sistema di invio. Un messaggio può portare più firme DKIM — provider della casella, strumento newsletter, helpdesk — ognuna con la propria coppia s=/d= e il proprio record. Sistemi quella che fallisce, e annoti il suo d=: solo una firma il cui d= corrisponde al Suo dominio From aiuta DMARC.

Perché manca il record del selettore?

Quattro cause spiegano la quasi totalità di questi errori — le verifichi in quest’ordine:

1. Non è mai stato pubblicato. Il firmatario è stato attivato (o si è attivato di default) con un selettore che nessuno ha aggiunto al DNS. Frequente con strumenti nuovi e gateway che firmano a sorpresa.
2. È stato eliminato a metà rotazione. Qualcuno ha “fatto pulizia” del vecchio selettore mentre messaggi firmati con esso erano ancora in transito, in coda per un nuovo tentativo o in attesa di inoltro. Quella posta è già firmata con s=old; eliminare old._domainkey rompe retroattivamente ognuno di quei messaggi.
3. La Sua interfaccia DNS ha alterato il target di un CNAME. Molti provider delegano tramite CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), e molti pannelli DNS aggiungono silenziosamente la Sua zona al target — memorizzando s1.domainkey.u123.esp.com.yourdomain.com, che non si risolve in nulla. Verifichi il target: dig CNAME s1._domainkey.yourdomain.com +short. La stessa trappola colpisce durante le migrazioni di strumenti — veda DKIM che fallisce dopo il cambio di strumenti email.
4. Il provider ha ruotato, la Sua zona no. Una chiave del provider incollata come record TXT statico (invece dei loro CNAME) resta orfana alla loro rotazione programmata — il firmatario passa a un selettore che Lei non ha mai pubblicato. Solo il 51,84% dei 261 milioni di domini del censimento presenta una chiave DKIM rintracciabile al momento della scansione (dati aggiornati al 2026-06-29).

Come sistemo “no key for signature”?

1. Esegua la scansione gratuita su defaults.exposed prima di toccare il DNS. Legge i Suoi record DKIM, SPF e DMARC dal vivo e mostra ciò che i destinatari vedono davvero — incluso se il selettore si risolve e se il target di un CNAME è stato alterato.
2. Pubblichi il selettore che il firmatario usa davvero — il valore s= dell’intestazione, non quello di un vecchio runbook. Recuperi il record dalla console di amministrazione del Suo provider (configurazione DKIM su Google Workspace · configurazione DKIM su Microsoft 365) e lo aggiunga esattamente a s._domainkey.yourdomain.com.
3. Preferisca la delega tramite CNAME all’incollare una chiave TXT. Se il Suo provider offre CNAME per DKIM, li usi: la chiave vive nella loro zona, quindi la ruotano senza che Lei tocchi di nuovo il DNS — la causa 4 diventa impossibile. Le piattaforme newsletter funzionano quasi tutte così; veda email di Mailchimp/Brevo/Klaviyo che falliscono DMARC.
4. Verifichi dall’esterno del Suo pannello. dig TXT s._domainkey.yourdomain.com +short (o dig CNAME … per i selettori delegati) da una macchina fuori dalla Sua rete. Che il pannello mostri il record non prova nulla se la zona serve qualcos’altro.
5. Riesegua la scansione e reinvii il messaggio di prova. Authentication-Results dovrebbe ora riportare dkim=pass. Poi lavori su tutto il resto che la scansione segnala nella pagina sistemare DKIM — una firma che passa ma non è allineata con il Suo dominio From fallisce comunque DMARC.

Come ruoto le chiavi DKIM senza causare questo errore?

La rotazione è il punto in cui le configurazioni funzionanti si rompono. La regola che lo previene: un selettore si elimina solo dopo che l’ultimo messaggio firmato con esso si è esaurito — mai al momento del passaggio. La posta firmata vive più a lungo di quanto pensa: le code di ritentativo girano per giorni, e i messaggi inoltrati vengono ri-verificati ogni volta che si spostano.

Con la delega tramite CNAME, il Suo provider esegue esattamente questo runbook nella propria zona e Lei non lo vede mai — l’argomento più forte a favore della delega.

Domande frequenti

“No key for signature” è un temperror o un permerror? Esistono entrambe le stringhe: temperror è una ricerca DNS fallita o andata in timeout — transitoria, spesso sparisce al nuovo tentativo — mentre permerror significa che il DNS ha risposto “nessun record”. Un temperror che si ripete presso più destinatari di solito si rivela anch’esso un record davvero mancante. Verifichi con dig e si fidi della risposta, non dell’etichetta.

Questo errore significa che qualcuno sta falsificando il mio dominio? No — chi falsifica non firmerebbe con il Suo selettore. Significa che la Sua stessa posta porta una firma che i destinatari non possono verificare, quindi conta come non firmata e DMARC si appoggia al solo SPF. L’autenticazione completa e allineata è rara: solo 10.092.481 di 261.086.232 domini (il 3,87%) completavano la triade SPF+DKIM+DMARC nel censimento Defaults.Exposed (dati aggiornati al 2026-06-29).

Posso semplicemente eliminare il vecchio selettore appena il nuovo funziona? Non subito. I messaggi firmati con esso sono ancora nelle code di ritentativo e nei percorsi di inoltro; eliminare la chiave li rompe retroattivamente. Mantenga il vecchio record almeno una settimana, osservi i Suoi report DMARC finché il vecchio selettore non smette di comparire, poi lo ritiri — idealmente con un p= vuoto anziché con l’eliminazione.

Il verificatore del mio provider dice che DKIM è configurato, ma i destinatari continuano a segnalare l’assenza della chiave. Come mai? Quasi sempre è la trappola del target CNAME: il Suo pannello DNS ha aggiunto la Sua zona al target (…esp.com.yourdomain.com), quindi il record esiste ma non punta a nulla. dig CNAME selector._domainkey.yourdomain.com +short mostra il target memorizzato alla lettera — lo confronti carattere per carattere con quanto richiesto dal provider.

Invii il report al titolare

Se sta sistemando questo per un cliente o per il Suo datore di lavoro, chiuda il cerchio con le prove. Riesegua la scansione gratuita una volta che il selettore si risolve e inoltri il report con il voto al titolare dell’azienda: datato, in linguaggio semplice, con DKIM ora verificato. È il documento che servirà per il rinnovo dell’assicurazione cyber e per il prossimo questionario di sicurezza dei fornitori — la prova di un controllo funzionante, non solo di un ticket chiuso.

Verifichi il Suo DKIM gratis

Veda se i Suoi selettori si risolvono — e cosa sistemare esattamente — in privato e visibile solo al titolare.

Verifichi il Suo dominio → · “DKIM signature not valid” → · Sistemare DKIM → · Configurare DKIM su Google Workspace → · Solo dati aggregati. Dati conservati e trattati nell’UE.