Defaults.Exposed › Correzioni › Guides

DKIM 'Body Hash Did Not Verify' — Cosa ha modificato il Suo messaggio, e come rimediare (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.

“Body hash did not verify” significa che la Sua firma DKIM era valida quando il messaggio è partito — e qualcosa ha riscritto il corpo del messaggio dopo. La firma non è rotta; il messaggio è stato modificato in transito. 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 (2026-06-29).

Il rimedio è una caccia, poi una decisione. Trovi il nodo che modifica la Sua posta — un gateway che aggiunge un disclaimer, un’appliance che riscrive i link, una mailing list che aggiunge un piè di pagina. Poi firmi dopo quel nodo, elimini la modifica, oppure renda la firma tollerante — in quest’ordine.

Cosa significa davvero “body hash did not verify”?

Una firma DKIM (RFC 6376) trasporta due hash: bh=, un hash del corpo del messaggio al momento della firma, e b=, che firma le intestazioni più quell’hash del corpo. Il verificatore ricalcola l’hash del corpo dal messaggio ricevuto; se non corrisponde a bh=, la verifica si ferma con la stringa che tutti incollano in un motore di ricerca — un’intestazione del destinatario come:

Authentication-Results: …; dkim=fail (body hash did not verify)

È la stringa di motivazione documentata da Microsoft; Gmail spesso rende la stessa diagnosi come dkim=neutral (body hash did not verify). In entrambi i casi, il verdetto restringe enormemente il problema. La Sua chiave DNS, il selettore e la configurazione di firma sono tutti a posto. La crittografia ha fatto il suo lavoro: il corpo è cambiato fra firma e verifica — basta una riga aggiunta, un URL riscritto, un carattere ricodificato. (Un messaggio diverso — signature did not verify, no key for signature — indica un guasto diverso; parta da “DKIM signature not valid”.) Ed è urgente perché una firma fallita non può dare a DMARC un pass allineato: a meno che l’SPF non passi con allineamento sullo stesso messaggio, la posta fallisce DMARC del tutto.

Cosa ha modificato il Suo messaggio? I soliti sospetti

Qualcosa lungo il percorso di consegna ha modificato il corpo dopo che il Suo firmatario lo aveva sigillato. In pratica è una di queste quattro cose:

Controlli per prima la riga in grassetto — il server di posta firma, il dispositivo di bordo modifica, e ogni messaggio parte con una firma che è stata vera per trenta millisecondi.

Come trovo il nodo che sta modificando la mia posta?

Diagnosi differenziale — confronti un percorso che funziona con quello che fallisce:

1. Invii un messaggio di prova diretto a una casella sotto il Suo controllo presso un grande destinatario (Gmail va benissimo), aggirando quanto più possibile la Sua catena in uscita.
2. Invii un secondo messaggio lungo il percorso che fallisce — attraverso il gateway, attraverso la lista, verso il dominio del destinatario interessato.
3. Confronti le righe Authentication-Results nelle intestazioni complete di entrambi. Invio diretto dkim=pass, percorso che fallisce dkim=fail (o dkim=neutral) con body hash did not verify: il modificatore vive fra quelle due rotte.
4. Guardi il corpo ricevuto: un disclaimer, un banner o un piè di pagina che non ha scritto Lei? Link riscritti verso un dominio di scansione? Ecco il Suo nodo, con nome e cognome — e la catena Received: mostra quale relay compare solo nel percorso che fallisce.

I Suoi report aggregati DMARC raccontano la stessa storia su scala: una sorgente che riporta con costanza DKIM fail con SPF pass è di solito modifica-in-transito sulla Sua stessa rotta, non un attaccante.

Come lo sistemo?

1. Esegua la scansione gratuita su defaults.exposed prima di toccare qualsiasi cosa. Conferma che le chiavi DKIM pubblicate e la politica DMARC sono in ordine, così sta facendo debug dell’unico problema reale — la modifica — senza inseguire fantasmi nel DNS. La pagina sistemare DKIM copre i controlli lato record.
2. Firmi dopo il nodo che modifica. La correzione architetturalmente corretta: sposti la firma DKIM sul dispositivo più esterno che tocca il messaggio. Chi ha Exchange più gateway dovrebbe firmare sul gateway (Mimecast, Proofpoint e simili lo supportano tutti) e disattivare la firma a monte. Se il Suo ultimo nodo è Google Workspace o Microsoft 365, firmi lì e non lasci che nulla modifichi la posta dopo — veda configurare DKIM su Google Workspace o Microsoft 365.
3. Oppure elimini la modifica. Tolga l’intervento dal percorso di trasporto: disclaimer nella firma del client o nel modello invece che in una regola di trasporto; banner “EXTERNAL:” limitato alla sola posta in entrata (etichettare come esterna la propria posta in uscita è una configurazione errata due volte); posta in uscita autenticata esentata dalla riscrittura dei link.
4. Usi la canonicalizzazione relaxed/relaxed (c=relaxed/relaxed). La canonicalizzazione del corpo simple fallisce su una singola riga riavvolta; relaxed tollera i cambi di spaziatura e di fine riga. Siamo onesti sul limite: relaxed perdona la formattazione, mai il contenuto — un piè di pagina aggiunto fallisce comunque, com’è giusto.
5. Ripeta il test su entrambi i percorsi, poi riesegua la scansione. Entrambe le rotte dovrebbero ora mostrare dkim=pass con il Suo dominio in d=, e il report della scansione dovrebbe risultare pulito.

Dovrei usare il tag l= per far ignorare a DKIM il contenuto aggiunto?

No — e diffidi di qualsiasi guida che lo suggerisce. Il tag l= calcola l’hash solo sui primi N byte del corpo, così un piè di pagina aggiunto non rompe più la firma. “Funziona” lasciando la fine del Suo messaggio non firmata: chiunque abbia in mano un messaggio legittimo firmato può aggiungere contenuto arbitrario e la Sua firma valida verifica comunque sul risultato. È una falla di spoofing travestita da soluzione — l’abuso pratico è stato dimostrato, e alcuni destinatari penalizzano o ignorano l= esattamente per questo motivo. Risolva la modifica; non lasci senza firma una parte della Sua posta.

E le mailing list — quelle si possono sistemare?

Per lo più no — e saperlo Le risparmia settimane. Una lista che aggiunge un’etichetta all’oggetto o un piè di pagina rompe il Suo hash del corpo per costruzione, e la lista non la controlla Lei. Due cose aiutano:

• Questo residuo è esattamente il motivo per cui il rollout DMARC è a tappe. Passare da p=none attraverso p=quarantine con una rampa pct=, leggendo i report aggregati, significa che i messaggi manipolati dalle liste finiscono in quarantena invece di essere distrutti mentre Lei ne valuta l’impatto — l’argomento di da p=none a p=reject senza perdere email legittime.
• ARC è il meccanismo del destinatario, non il Suo. Authenticated Received Chain permette alla lista di attestare com’era l’autenticazione all’arrivo e al destinatario di decidere se fidarsi. Non c’è nulla che Lei, come mittente, debba configurare. Le liste gestite bene mitigano riscrivendo l’intestazione From; quelle gestite male rompono la Sua posta e basta.

L’inoltro è il caso adiacente — rompe l’SPF in modo affidabile ma il DKIM solo a volte, motivo per cui un DKIM allineato è la Sua gamba a prova di inoltro quando il corpo sopravvive: veda le email inoltrate falliscono l’SPF — perché non può risolverlo.

Perché DKIM si rompe così spesso quando così pochi domini hanno persino la pila completa?

Perché DKIM è il figlio di mezzo fragile della triade: SPF è un record DNS statico, DMARC una dichiarazione di politica, ma DKIM deve sopravvivere al viaggio. Solo il 51,84% dei domini valutati pubblica una chiave DKIM rintracciabile nel DNS, secondo il censimento Defaults.Exposed, e solo 10.092.481 domini — il 3,87% dei 261.086.232 valutati — tengono insieme SPF, DKIM e una politica DMARC applicata (il modello di maturità dell’adozione SPF scompone la scala). Riuscire in questa correzione è la parte più difficile dell’entrare in quel 3,87%.

Domande frequenti

“Body hash did not verify” è segno che qualcuno sta falsificando il mio dominio? Di solito no — chi falsifica in genere non può produrre affatto la Sua firma DKIM, quindi la sua posta non mostra alcuna firma oppure no key. Un hash del corpo fallito significa che un messaggio genuinamente firmato dalla Sua infrastruttura è stato modificato dopo. Controlli il Suo gateway prima di presumere un attaccante.

L’SPF passa su questi messaggi — sono comunque a posto? Per ora, forse: a DMARC basta un solo pass allineato. Ma il pass dell’SPF evapora nel momento in cui qualcuno inoltra il messaggio, e se non è allineato al Suo dominio From non è mai contato per DMARC comunque. Con solo il 3,87% dei domini in possesso della triade completa (censimento 2026-06-29 su 261.086.232 domini), “una gamba che zoppica” è lo stato normale — e quello risolvibile.

Passare alla canonicalizzazione relaxed/relaxed risolverà il mio problema di disclaimer? No. Relaxed tollera solo i cambi di spaziatura e di ritorno a capo. Un disclaimer aggiunto è una modifica di contenuto, e l’hash deve fallire su di essa — è DKIM che funziona correttamente. Sposti il punto di firma o sposti il disclaimer.

Il fallimento avviene solo verso il dominio di un cliente. Perché? Quasi certamente il loro lato modifica la posta in entrata — un’appliance di sicurezza che riscrive i link o applica banner prima che giri il loro verificatore, oppure un inoltro interno che ricodifica il corpo. Mandi loro la sezione di diagnosi di questa pagina; la correzione sta sul loro gateway, non nel Suo DNS.

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. Una volta sistemato il nodo che modificava, riesegua la scansione gratuita e inoltri il report con il voto al titolare dell’azienda: datato, in linguaggio semplice, con DKIM e DMARC in ordine su una sola pagina. È il documento che gli servirà per il rinnovo dell’assicurazione cyber e per il prossimo questionario dei fornitori — la prova che la posta che esce dall’azienda è ora la posta che arriva.

Controlli il Suo dominio → · Guida “DKIM signature not valid” → · Sistemare DKIM → · Come assegniamo i voti → · Solo dati aggregati. Dati conservati e trattati nell’UE.