DKIM 'Body Hash Did Not Verify' — Apa yang Mengubah Pesan Anda, dan Cara Memperbaikinya (2026)

Diterbitkan 2026-07-08

Angka per 2026-06-29 · metodologi v7. Data sensus agregat dari 261 juta domain yang dinilai. Lihat cara kami menilai.

“Body hash did not verify” berarti tanda tangan DKIM Anda valid saat pesan meninggalkan Anda — dan sesuatu menulis ulang body pesan setelahnya. Tanda tangannya tidak rusak; pesannya yang dimodifikasi saat transit. Hanya 3.87% domain — 10,092,481 — yang menyelesaikan triad penuh SPF-DKIM-DMARC, menurut sensus Defaults.Exposed dari 261,086,232 domain (2026-06-29).

Perbaikannya adalah perburuan, kemudian keputusan. Temukan hop yang memodifikasi email Anda — gateway yang menambahkan penafian, appliance yang menulis ulang tautan, mailing list yang menambahkan footer. Kemudian tandatangani setelah hop itu, hentikan modifikasi, atau buat tanda tangan toleran terhadapnya — dalam urutan itu.

Apa arti “body hash did not verify” sebenarnya?

Tanda tangan DKIM (RFC 6376) membawa dua hash: bh=, hash dari body pesan saat ditandatangani, dan b=, yang menandatangani header ditambah body hash tersebut. Verifier menghitung ulang body hash dari pesan yang diterimanya; jika tidak cocok dengan bh=, verifikasi berhenti dengan string yang ditempel semua orang ke kotak pencarian — header penerima seperti:

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

Itu adalah string alasan yang didokumentasikan Microsoft; Gmail sering merender diagnosis yang sama sebagai dkim=neutral (body hash did not verify). Bagaimanapun, verdiktnya mempersempit masalah secara besar. Kunci DNS, selector, dan konfigurasi penandatanganan Anda semua baik-baik saja. Kriptografi telah melakukan tugasnya: body berubah antara penandatanganan dan verifikasi — satu baris yang ditambahkan, satu URL yang ditulis ulang, satu karakter yang di-re-encode sudah cukup. (Pesan berbeda — signature did not verify, no key for signature — berarti kegagalan berbeda; mulai dengan “DKIM signature not valid”.) Dan ini mendesak karena tanda tangan yang gagal tidak dapat memberi DMARC kelulusan yang selaras: kecuali SPF lulus dengan keselarasan pada pesan yang sama, email gagal DMARC sepenuhnya.

Apa yang mengubah pesan Anda? Tersangka biasa

Sesuatu dalam jalur pengiriman mengedit body setelah penandatangan Anda menyegelnya. Dalam praktik ini adalah salah satu dari empat hal:

Siapa yang memodifikasi	Apa yang mereka ubah	Tanda khas
Gateway keluar / smart host (Exchange transport rules, Mimecast, Proofpoint, Barracuda…)	Menambahkan penafian hukum, footer pemasaran, atau banner “EXTERNAL:” setelah server email sudah menandatangani	Setiap pesan di jalur itu gagal; pengiriman langsung yang melewati gateway lulus
Appliance keamanan / perlindungan tautan	Menulis ulang URL ke pengalihan pemindaian, menambahkan pembungkus pelacakan	Hanya pesan yang mengandung tautan yang gagal
Mailing list (Google Groups, Mailman…)	Menambahkan tag subjek dan footer daftar, terkadang merefloat body	Hanya email yang dikirim melalui daftar yang gagal
Forwarder / relay yang meng-re-encode MIME	Mentranscode charset, membungkus ulang baris — tidak terlihat manusia, fatal bagi hash	Kegagalan berklaster pada satu penerima atau alamat penerusan

Periksa baris yang dicetak tebal terlebih dahulu — server email menandatangani, perangkat edge mengedit, dan setiap pesan keluar dengan tanda tangan yang benar selama tiga puluh milidetik.

Bagaimana cara menemukan hop yang memodifikasi email saya?

Diagnosis diferensial — bandingkan jalur yang berfungsi dengan jalur yang gagal:

Kirim pesan uji langsung ke kotak surat yang Anda kendalikan di penerima besar (Gmail berfungsi dengan baik), melewati sebanyak mungkin rantai keluar Anda.
Kirim pesan kedua melalui jalur yang gagal — melalui gateway, melalui daftar, ke domain penerima yang terpengaruh.
Bandingkan baris Authentication-Results di kedua header lengkap. Pengiriman langsung dkim=pass, jalur gagal dkim=fail (atau dkim=neutral) dengan body hash did not verify: pengubah berada di antara dua jalur tersebut.
Lihat body yang diterima: penafian, banner, atau footer yang tidak Anda ketik? Tautan yang ditulis ulang ke domain pemindaian? Itulah hop Anda, teridentifikasi — dan rantai Received: menampilkan relay mana yang hanya muncul di jalur yang gagal.

Laporan agregat DMARC Anda menceritakan kisah yang sama dalam skala besar: sumber yang secara konsisten melaporkan kegagalan DKIM dengan kelulusan SPF biasanya adalah modifikasi-saat-transit di jalur Anda sendiri, bukan penyerang.

Bagaimana cara memperbaikinya?

Jalankan pemindaian gratis di defaults.exposed sebelum menyentuh apapun. Ini mengkonfirmasi kunci DKIM yang diterbitkan dan kebijakan DMARC Anda sudah baik, sehingga Anda men-debug satu masalah nyata — modifikasinya — bukan mengejar hantu di DNS. Halaman perbaiki DKIM mencakup pemeriksaan sisi record.
Tandatangani setelah hop yang memodifikasi. Perbaikan yang secara arsitektur benar: pindahkan penandatanganan DKIM ke perangkat terluar yang menyentuh pesan. Toko Exchange-plus-gateway harus menandatangani di gateway (Mimecast, Proofpoint dan sejenis semua mendukungnya) dan menonaktifkan penandatanganan di upstream. Jika Google Workspace atau Microsoft 365 adalah hop terakhir Anda, tandatangani di sana dan jangan biarkan apapun mengedit email setelahnya — lihat siapkan DKIM di Google Workspace atau Microsoft 365.
Atau hentikan modifikasinya. Hapus edit dari jalur transport: penafian di tanda tangan klien atau template alih-alih aturan transport; banner “EXTERNAL:” dibatasi untuk email masuk saja (menandai email keluar Anda sendiri sebagai eksternal adalah miskonfigurasi dua kali); email keluar terautentikasi dikecualikan dari penulisan ulang tautan.
Gunakan kanonisasi relaxed/relaxed (c=relaxed/relaxed). Kanonisasi body simple gagal pada satu baris yang dibungkus ulang; relaxed menoleransi perubahan spasi dan akhir baris. Jujur tentang batasannya: relaxed memaafkan pemformatan, tidak pernah konten — footer yang ditambahkan masih gagal, sebagaimana mestinya.
Uji ulang kedua jalur, kemudian pindai ulang. Kedua jalur sekarang harus menampilkan dkim=pass dengan domain Anda di d=, dan laporan pemindaian harus bersih.

Haruskah saya menggunakan tag l= agar DKIM mengabaikan konten yang ditambahkan?

Tidak — dan curigailah panduan mana pun yang menyarankannya. Tag l= hanya meng-hash N byte pertama dari body, sehingga footer yang ditambahkan tidak lagi merusak tanda tangan. Ini “berfungsi” dengan membiarkan akhir pesan Anda tidak ditandatangani: siapapun yang memegang pesan yang ditandatangani secara sah dapat menambahkan konten arbitrer dan tanda tangan valid Anda masih memverifikasi hasilnya. Itu adalah lubang pemalsuan yang menyamar sebagai perbaikan — penyalahgunaan praktis telah didemonstrasikan, dan beberapa penerima menghukum atau mengabaikan l= karena alasan ini. Selesaikan modifikasinya; jangan biarkan sebagian email Anda tidak ditandatangani.

Bagaimana dengan mailing list — bisakah saya memperbaikinya?

Sebagian besar tidak — dan mengetahui itu menghemat berminggu-minggu. Daftar yang menambahkan tag subjek atau footer secara desain merusak body hash Anda, dan Anda tidak mengendalikan daftar tersebut. Dua hal membantu:

Residu ini adalah persis mengapa peluncuran DMARC dilakukan secara bertahap. Berpindah dari p=none melalui p=quarantine dengan ramp pct=, sambil membaca laporan agregat, berarti pesan yang dirusak daftar dikarantina alih-alih dihancurkan saat Anda menilai dampaknya — subjek dari dari p=none ke p=reject tanpa kehilangan email sah.
ARC adalah mekanisme penerima, bukan milik Anda. Authenticated Received Chain membiarkan daftar membuktikan tampilan autentikasi saat tiba dan penerima memutuskan apakah mempercayainya. Tidak ada yang perlu Anda, pengirim, konfigurasi. Daftar yang dikelola dengan baik memitigasi dengan menulis ulang header From; yang dikelola buruk cukup merusak email Anda.

Penerusan adalah kasus yang berdekatan — secara andal merusak SPF tetapi hanya kadang-kadang DKIM, itulah mengapa DKIM yang selaras adalah leg tahan-penerusan Anda saat body selamat: lihat email yang diteruskan gagal SPF — mengapa Anda tidak bisa memperbaikinya.

Mengapa DKIM sering rusak padahal begitu sedikit domain yang memiliki stack penuh?

Karena DKIM adalah anak tengah yang rapuh dari triad: SPF adalah record DNS statis, DMARC adalah pernyataan kebijakan, tetapi DKIM harus bertahan dalam perjalanan. Hanya 51.84% domain yang dinilai yang menerbitkan kunci DKIM yang dapat ditemukan di DNS, menurut sensus Defaults.Exposed, dan hanya 10,092,481 domain — 3.87% dari 261,086,232 yang dinilai — yang menyimpan SPF, DKIM dan kebijakan DMARC yang menegakkan bersama-sama (model kematangan adopsi SPF menguraikan tangga tersebut). Mendapatkan perbaikan ini dengan benar adalah bagian tersulit dari bergabung dengan 3.87% tersebut.

Pertanyaan yang Sering Diajukan

Apakah “body hash did not verify” adalah tanda seseorang memalsukan domain saya? Biasanya tidak — spoofer biasanya tidak dapat menghasilkan tanda tangan DKIM Anda sama sekali, sehingga email mereka tidak menampilkan tanda tangan atau no key. Body hash yang gagal berarti pesan yang benar-benar ditandatangani oleh infrastruktur Anda diedit setelahnya. Periksa gateway Anda sendiri sebelum mengasumsikan penyerang.

SPF lulus pada pesan-pesan ini — apakah saya masih baik-baik saja? Untuk saat ini, mungkin: DMARC hanya butuh satu kelulusan yang selaras. Tetapi kelulusan SPF menguap begitu seseorang meneruskan pesan, dan jika tidak selaras dengan domain From Anda, tidak pernah dihitung untuk DMARC bagaimanapun. Dengan hanya 3.87% domain yang menyimpan triad penuh (sensus 2026-06-29 dari 261,086,232 domain), “satu kaki pincang” adalah kondisi normal — dan yang bisa diperbaiki.

Apakah beralih ke kanonisasi relaxed/relaxed akan memperbaiki masalah penafian saya? Tidak. Relaxed hanya menoleransi perubahan spasi dan pembungkusan baris. Penafian yang ditambahkan adalah perubahan konten, dan hash harus gagal padanya — itulah DKIM bekerja dengan benar. Pindahkan titik penandatanganan atau pindahkan penartianan.

Kegagalan hanya terjadi pada domain satu pelanggan. Mengapa? Sisi mereka hampir pasti memodifikasi email masuk — appliance keamanan yang menulis ulang tautan atau mencap banner sebelum verifier mereka berjalan, atau penerusan internal yang meng-re-encode body. Kirim mereka bagian diagnosis halaman ini; perbaikannya ada di gateway mereka, bukan di DNS Anda.

Kirimkan laporan kepada pemilik

Jika Anda memperbaiki ini untuk klien atau perusahaan, tutup dengan bukti. Setelah hop yang memodifikasi diperbaiki, jalankan ulang pemindaian gratis dan teruskan laporan yang dinilai kepada pemilik bisnis: bertanggal, bahasa mudah dipahami, DKIM dan DMARC berdiri di satu halaman. Itulah artefak yang mereka butuhkan untuk perpanjangan asuransi siber dan kuesioner pemasok berikutnya — bukti bahwa email yang meninggalkan perusahaan sekarang adalah email yang tiba.

Periksa domain Anda → · Panduan “DKIM signature not valid” → · Perbaiki DKIM → · Cara kami menilai → · Hanya data agregat. Data disimpan dan diproses di EU.