DKIM body hash did not verify significa che l’hash calcolato dal destinatario sul corpo del messaggio non coincide con il valore `bh=` nella firma DKIM. Il contenuto è stato modificato dopo la firma oppure la firma è stata generata in modo errato.
Questa guida approfondisce DKIM body hash did not verify con verifiche progressive e reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.
Che cosa significa
DKIM firma header selezionati e il corpo secondo una canonicalization definita in `c=`. Modifiche apparentemente minime, come footer, riscrittura HTML o conversione delle linee, possono invalidare la firma.
Il record DNS può essere perfettamente disponibile: key not found e body hash mismatch sono errori differenti e richiedono diagnosi diverse.
Come riconoscere il problema
- Authentication-Results mostra dkim=fail body hash did not verify.
- Il selector e la chiave DNS vengono trovati.
- Messaggi diretti passano ma inoltrati falliscono.
- Un gateway aggiunge disclaimer o footer.
- Solo messaggi HTML o con allegati mostrano il problema.
Cause più frequenti
1. Footer aggiunto dopo la firma
Gateway o mailing list modifica il corpo. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
2. Riscrittura HTML
Antivirus, antispam o sistema di tracking altera link e markup. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
3. Conversione line ending o encoding
Un relay modifica la rappresentazione. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
4. Firma generata troppo presto
L’applicazione firma prima delle trasformazioni finali. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
5. Canonicalization non adatta
La modalità simple è sensibile a modifiche. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
6. Messaggio corrotto
Trasferimento o software produce un corpo differente. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
Diagnosi passo per passo
- Conserva il messaggio originale `.eml`. Non inoltrarlo come testo. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Leggi DKIM-Signature. Controlla d=, s=, c=, bh= e h=. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Confronta percorso diretto e inoltrato. Individua il relay che modifica. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Controlla footer e disclaimer. Verifica quando vengono aggiunti. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Esamina gateway e antivirus. Cerca riscrittura link o contenuto. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Invia un messaggio semplice. Solo testo, poi HTML e allegato. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Confronta header Received. Localizza il punto della trasformazione. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
Metodo sicuro di diagnosi
Prima di modificare la configurazione, registra URL o servizio coinvolto, messaggio completo, data e ora, ultima modifica nota, client o rete e risultato ottenuto con un secondo strumento. Questa fotografia iniziale permette di confrontare i test e di tornare alla configurazione precedente quando una modifica non produce il risultato atteso.
Applica una sola correzione alla volta. Dopo ogni intervento ripeti esattamente la stessa operazione e controlla i log dello stesso intervallo temporale. Modificare contemporaneamente DNS, cache, PHP, plugin, proxy e firewall elimina la possibilità di attribuire il risultato a una causa precisa.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin, Site Health e WP-CLI; per DNS interroga nameserver autoritativi e resolver pubblici; per la posta confronta Webmail, intestazioni originali e Track Delivery. Cache, TTL e code possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, esegui una seconda prova con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Verifica inoltre che TLS, autenticazione, WAF, permessi e controlli antispam restino attivi: una correzione che disabilita stabilmente le protezioni non è una soluzione definitiva.
Verifica prolungata dopo la correzione
Conserva temporaneamente backup, valori precedenti ed estratti dei log. Ripeti il controllo dopo il normale ciclo di cache, cron, coda o TTL. Se l’anomalia ricompare a intervalli regolari, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, processi pianificati e servizi esterni.
Documenta il risultato finale con data, comando o schermata utilizzata e condizione verificata. Questa nota evita interventi duplicati e rende più rapida una futura analisi da parte dell’assistenza.
Procedura di risoluzione
- Firma dopo tutte le modifiche. Il DKIM signer deve essere l’ultimo componente che altera il corpo. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Sposta footer prima della firma. Configura gateway e applicazione. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Evita riscritture non necessarie. Disabilita solo la funzione responsabile, non la sicurezza globale. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Usa canonicalization appropriata. `relaxed` tollera alcune differenze di spaziatura. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Configura il provider di invio. Usa la sua firma DKIM allineata. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Mantieni una firma aggiuntiva. Un relay può firmare nuovamente dopo la modifica. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Ritesta con messaggi reali. Controlla Authentication-Results su più destinatari. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Come raccogliere prove utili
Quando riproduci il problema, conserva soltanto i dati tecnici necessari: codice di risposta, URL priva di token, orario con fuso, request ID, nome del client, dimensione del file o del messaggio e una breve descrizione dell’operazione. Evita screenshot parziali quando puoi esportare il testo originale, perché header, log e messaggi completi permettono una diagnosi più precisa.
Prima di chiudere il controllo, confronta il comportamento con una configurazione nota e funzionante. Per una API usa un payload minimo; per WordPress prova una funzione core senza plugin aggiuntivi; per DNS interroga direttamente i nameserver; per la posta usa Webmail e conserva il file `.eml`. Questo confronto riduce le ipotesi e impedisce modifiche inutili.
Controlli finali
- DKIM passa.
- Corpo non modificato dopo firma.
- Footer presente correttamente.
- Selector disponibile.
- DMARC allineato.
Prevenzione
- Ordine dei gateway documentato.
- Firma finale.
- Test dopo modifiche footer.
- Monitoraggio DKIM.
- Conservazione `.eml`.
Errori da evitare
- Non cambiare il record DKIM se la chiave viene trovata.
- Non affidarti a screenshot.
- Non rimuovere antivirus globalmente.
- Non inoltrare il messaggio per analizzarlo.
- Non confondere bh mismatch e selector missing.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:
- file `.eml`
- dominio e selector
- Authentication-Results
- percorso e gateway
- orario
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Domande frequenti su DKIM body hash did not verify
Il record DNS è sbagliato?
Non necessariamente; il messaggio indica che la chiave è stata usata ma il corpo non coincide.
Un footer può rompere DKIM?
Sì, se viene aggiunto dopo la firma.
Forwarding rompe sempre DKIM?
No, soltanto se modifica parti firmate.
Che cos’è canonicalization relaxed?
Una modalità che tollera alcune differenze non sostanziali di formattazione.
Perché serve il file `.eml`?
Conserva header e corpo originali necessari per verificare la firma.