Defaults.Exposed › Correzioni › Guides

'DKIM Signature Not Valid' — le cause, nell'ordine in cui verificarle (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 signature not valid” ha cinque cause comuni, da verificare preferibilmente in ordine: contenuto modificato in transito, record della chiave troncato, chiave pubblicata che non corrisponde al firmatario, selettore sbagliato e canonicalizzazione fragile. Solo 10.092.481 di 261.086.232 domini valutati (il 3,87%) possiede la triade completa SPF + DKIM + DMARC applicato, secondo il censimento Defaults.Exposed (2026-06-29).

L’ordine delle verifiche conta perché la causa più comune non sta affatto nel Suo DNS. Controlli prima cosa ha modificato il messaggio in transito, poi proceda verso l’interno: l’integrità del record della chiave, la corrispondenza con ciò che il Suo server di posta sta effettivamente usando per firmare, il selettore e infine le impostazioni di firma. La maggior parte delle firme non valide si risolve al passo uno o due.

Cosa significa davvero “DKIM signature not valid”?

Ogni messaggio firmato con DKIM porta un’intestazione DKIM-Signature che indica un dominio (d=), un selettore (s=), un hash del corpo del messaggio (bh=) e una firma crittografica sull’hash del corpo più le intestazioni selezionate (b=). Il destinatario recupera la Sua chiave pubblica dal DNS a <selector>._domainkey.<domain>, ricalcola entrambi gli hash e verifica la firma (RFC 6376). “Signature not valid” è il gergo dei verificatori e delle intestazioni per dire: quella verifica è stata eseguita ed è fallita — la chiave è stata trovata, ma i conti non sono tornati.

Quest’ultima precisazione è oro diagnostico. Un verificatore che non riesce a trovare la Sua chiave dice qualcosa di diverso — tipicamente un’intestazione come dkim=fail (no key for signature) — e quello è un problema di selettore, trattato in DKIM “no key for signature” — correzioni di selettore e rotazione. E un verificatore che ricalcola un hash del corpo diverso di solito lo dice esplicitamente: body hash did not verify — Microsoft lo riporta come dkim=fail (body hash did not verify), mentre Gmail spesso rende la stessa diagnosi come dkim=neutral (body hash did not verify). In entrambi i casi punta a una modifica del contenuto, trattata in “body hash did not verify” — cosa ha modificato il Suo messaggio. Legga la formulazione esatta nell’intestazione Authentication-Results prima di toccare qualsiasi cosa: Le dice quale delle cinque cause ha tra le mani.

Fare tutto questo correttamente è raro: solo il 51,84% dei domini valutati pubblica nel DNS una chiave DKIM rintracciabile, secondo il censimento Defaults.Exposed, e solo il 3,87% di 261 milioni di domini valutati combina SPF, DKIM e una policy DMARC applicata — la configurazione che le regole per i bulk sender ormai danno per scontata. Il quadro fase per fase è nel modello di maturità dell’adozione SPF.

Quali sono le cinque cause, in ordine?

La causa 1 è in grassetto perché rompe le firme su messaggi che erano stati firmati perfettamente. Un gateway di sicurezza aggiunge un disclaimer, un footer di conformità viene apposto dopo la firma, una mailing list aggiunge [listname] all’oggetto — il corpo o le intestazioni firmate cambiano, gli hash non corrispondono più e la firma risulta non valida senza alcuna colpa del Suo DNS. Se i fallimenti sono correlati a posta passata per un gateway, una lista o un passaggio di archiviazione, cominci da lì.

Come sistemo “DKIM signature not valid”?

1. Esegua la scansione gratuita su defaults.exposed prima di toccare il DNS. Mostra se il record della Sua chiave pubblicata è presente, ben formato e completo — separando “il Suo DNS è rotto” (cause 2–4) da “il Suo DNS è a posto, il messaggio viene modificato” (causa 1) in un solo passaggio.
2. Legga l’intestazione Authentication-Results di un messaggio che fallisce. body hash did not verify → causa 1, vada alla guida al body hash — i sospetti abituali sono footer di gateway e disclaimer, e la correzione è firmare dopo la modifica. no key for signature → causa 4, vada alla guida ai selettori. Un semplice fallimento della firma → prosegua.
3. Controlli se la chiave pubblicata è troncata. Interroghi <selector>._domainkey.<yourdomain> come TXT (dig TXT selector._domainkey.example.com). Una chiave pubblica RSA a 2048 bit è più lunga del limite di 255 caratteri di una singola stringa TXT, quindi va pubblicata come più stringhe tra virgolette che i destinatari concatenano — e le interfacce web dei provider DNS sono note per troncare silenziosamente l’incollato, alterare la suddivisione o iniettare spazi e virgolette nel valore p=. Confronti carattere per carattere con la chiave generata dal Suo firmatario; le nostre guide alla configurazione DKIM coprono le stranezze dei singoli provider.
4. Confermi che la chiave pubblicata corrisponda al firmatario. Dopo una rotazione delle chiavi, una migrazione di provider o una riconnessione dell’ESP, capita spesso che il firmatario abbia una nuova chiave privata mentre il DNS serve ancora la vecchia chiave pubblica — ogni firma viene verificata contro la chiave sbagliata e fallisce. Ricopi il record corrente dalla console di amministrazione del Suo provider. Meglio ancora: dove il provider offre la delega tramite CNAME, la usi — il provider ruota le chiavi dalla propria parte e questa intera classe di fallimenti scompare. E non elimini mai un vecchio selettore finché il traffico firmato con esso non si è esaurito.
5. Sistemi le impostazioni di firma, non solo il record. Imposti la canonicalizzazione su c=relaxed/relaxed, che tollera il re-impaginamento degli spazi e il ripiegamento delle intestazioni che i server intermedi fanno legittimamente; la canonicalizzazione simple fallisce per modifiche che un essere umano non riesce nemmeno a vedere. E non usi il tag l= di lunghezza del corpo: era pensato per lasciar passare i footer, ma permette a chiunque di accodare contenuto al Suo messaggio firmato senza rompere la firma — un vettore d’attacco reale — e comunque non sopravvive alla maggior parte delle modifiche dei gateway. Niente l= è la scelta sia più sicura sia più affidabile.
6. Riesegua la scansione, poi verifichi l’allineamento. Una firma valida aiuta DMARC solo se il dominio d= è allineato con il Suo dominio From — una firma che si convalida come d=yourcompany.gappssmtp.com passa DKIM e fallisce comunque DMARC. Se è il Suo caso, veda la trappola della firma predefinita, poi affronti tutto il resto che la scansione segnala nella pagina sistemare DKIM.

Domande frequenti

“DKIM signature not valid” è la stessa cosa di “body hash did not verify”? Il messaggio sul body hash è un sotto-caso specifico: il corpo è cambiato dopo la firma (footer, disclaimer, riscritture delle liste). “Signature not valid” è il verdetto ombrello per qualsiasi verifica fallita, incluse chiavi errate e modifiche alle intestazioni — motivo per cui il passo 2 qui sopra è leggere l’intestazione, e per cui il caso del body hash ha una guida dedicata.

Una firma DKIM non valida significa che la mia posta viene rifiutata? Non di per sé — i destinatari trattano una firma rotta come una firma assente. Il danno arriva tramite DMARC: se nemmeno SPF passa con allineamento, il messaggio fallisce DMARC e si applica la policy che ha pubblicato. Al censimento del 2026-06-29, solo il 3,87% di 261.086.232 domini valutati possiede insieme SPF, DKIM e una policy DMARC applicata — ma Gmail e Microsoft ormai si aspettano esattamente questo dai mittenti, quindi una gamba DKIM rotta costa in recapito ancora prima del rifiuto.

Devo usare una chiave DKIM a 1024 o a 2048 bit? 2048 bit — le chiavi a 1024 bit sono sotto le raccomandazioni crittografiche attuali e alcuni destinatari le penalizzano. L’inghippo è puramente operativo: una chiave a 2048 bit non sta in una singola stringa TXT da 255 caratteri, quindi va suddivisa correttamente (causa 2 qui sopra). La delega tramite CNAME al Suo provider aggira del tutto il problema della suddivisione.

Il mio DKIM passa su un verificatore ma DMARC continua a fallire — come mai? Quasi certamente allineamento: la firma si convalida, ma il suo dominio d= (ad esempio yourcompany.gappssmtp.com o yourtenant.onmicrosoft.com) non corrisponde al Suo dominio From, quindi DMARC non può usarla. Attivi la firma con dominio personalizzato del Suo provider — la procedura completa è nella guida alla trappola della firma predefinita.

Posso semplicemente disattivare DKIM se continua a fallire? No — dai mandati per i bulk sender del 2024, Gmail e Yahoo richiedono DKIM ai mittenti ad alto volume, e una policy DMARC applicata ha realisticamente bisogno di DKIM perché SPF da solo si rompe con l’inoltro. Sistemi la firma; le cause qui sopra si risolvono tutte in un pomeriggio.

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 dopo le Sue modifiche e inoltri il report con il voto al titolare dell’azienda: datato, in linguaggio semplice, con DKIM in verde. È il documento che gli servirà per il rinnovo della polizza cyber e per il prossimo questionario di sicurezza dei fornitori — la differenza tra “ho sistemato una cosa nel DNS” e un prima-e-dopo documentato che attesta che il dominio autentica la propria posta.

Verifichi il Suo dominio → · Guida “Body hash did not verify” → · Sistemare DKIM → · Come assegniamo i voti → · Solo dati aggregati. Dati conservati e trattati nell’UE.