Defaults.Exposed › Perbaikan › Guides
'DKIM Signature Not Valid' — Penyebab-penyebabnya, dalam Urutan Pemeriksaan (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.
“DKIM signature not valid” memiliki lima penyebab umum, paling baik diperiksa secara berurutan: konten yang dimodifikasi saat transit, record kunci yang terpotong, kunci yang diterbitkan tidak cocok dengan penandatangan, selector yang salah, dan kanonisasi yang rapuh. Hanya 10,092,481 dari 261,086,232 domain yang dinilai (3.87%) yang menyimpan triad penuh SPF + DKIM + DMARC-menegakkan, menurut sensus Defaults.Exposed (2026-06-29).
Urutan perbaikan penting karena penyebab paling umum tidak ada di DNS Anda sama sekali. Periksa apa yang mengubah pesan saat transit terlebih dahulu, kemudian bekerja ke dalam: integritas record kunci, apakah cocok dengan apa yang benar-benar digunakan server email Anda untuk menandatangani, selector, dan akhirnya pengaturan penandatanganan. Sebagian besar tanda tangan yang tidak valid diperbaiki di langkah satu atau dua.
Apa arti “DKIM signature not valid” sebenarnya?
Setiap pesan yang ditandatangani DKIM membawa header DKIM-Signature yang menamai domain (d=), selector (s=), hash dari body pesan (bh=), dan tanda tangan kriptografi atas body hash ditambah header yang dipilih (b=). Penerima mengambil kunci publik Anda dari DNS di <selector>._domainkey.<domain>, menghitung ulang kedua hash, dan memeriksa tanda tangan (RFC 6376). “Signature not valid” adalah ungkapan pemeriksa dan header untuk: verifikasi itu berjalan dan gagal — kunci ditemukan, tetapi matematikanya tidak cocok.
Klausa terakhir itulah yang bernilai diagnostik. Verifier yang tidak dapat menemukan kunci Anda mengatakan sesuatu yang berbeda — biasanya header seperti dkim=fail (no key for signature) — dan itu adalah masalah selector, yang dibahas di DKIM “no key for signature” — perbaikan selector dan rotasi. Dan verifier yang menghitung ulang body hash yang berbeda biasanya mengatakan secara eksplisit: body hash did not verify — Microsoft melaporkannya sebagai dkim=fail (body hash did not verify), sementara Gmail sering merender diagnosis yang sama sebagai dkim=neutral (body hash did not verify). Bagaimanapun menunjuk ke modifikasi konten, yang dibahas di “body hash did not verify” — apa yang mengubah pesan Anda. Baca kata-kata tepat dalam header Authentication-Results sebelum menyentuh apapun: itu memberi tahu Anda penyebab mana dari lima penyebab yang Anda hadapi.
Mendapatkan ini dengan benar jarang: hanya 51.84% domain yang dinilai menerbitkan kunci DKIM yang dapat ditemukan di DNS, menurut sensus Defaults.Exposed, dan hanya 3.87% dari 261 juta domain yang dinilai menggabungkan SPF, DKIM dan kebijakan DMARC yang menegakkan — konfigurasi yang kini diasumsikan oleh aturan pengirim massal. Gambar tahap demi tahap ada di model kematangan adopsi SPF.
Apa lima penyebabnya, secara berurutan?
| # | Penyebab | Tandanya | Perbaikan |
|---|---|---|---|
| 1 | Konten dimodifikasi saat transit — footer gateway, penafian hukum, tag subjek mailing-list | body hash did not verify di Authentication-Results; email eksternal gagal, email langsung lulus | Tandatangani setelah modifikasi, atau hentikan modifikasi — lihat panduan body-hash |
| 2 | Kunci panjang yang terpotong atau rusak | p= yang diterbitkan secara terlihat lebih pendek dari kunci yang Anda hasilkan; setiap penerima gagal | Terbitkan ulang kunci RSA 2048-bit sebagai string TXT yang dipecah dengan benar |
| 3 | Kunci yang diterbitkan tidak cocok dengan penandatangan | Kegagalan dimulai tepat setelah rotasi, migrasi, atau pergantian provider | Salin ulang record terkini dari konsol provider; pilih delegasi CNAME |
| 4 | Selector yang salah atau hilang | no key for signature — lookup itu sendiri gagal | Terbitkan selector yang benar-benar digunakan penandatangan — lihat panduan selector |
| 5 | Kanonisasi yang rapuh atau tag l= | Kegagalan intermiten pada pesan yang diformat ulang secara sepele | c=relaxed/relaxed; hapus l= sepenuhnya |
Penyebab 1 dicetak tebal karena merusak tanda tangan pada pesan yang ditandatangani dengan sempurna. Gateway keamanan menambahkan penafian, footer kepatuhan dicap setelah penandatanganan, mailing list menambahkan [listname] ke subjek — body atau header yang ditandatangani berubah, hash tidak lagi cocok, dan tanda tangan tidak valid tanpa kesalahan DNS Anda. Jika kegagalan berkorelasi dengan email yang melewati gateway, daftar, atau hop pengarsipan, mulailah di sana.
Bagaimana cara memperbaiki “DKIM signature not valid”?
- Jalankan pemindaian gratis di defaults.exposed sebelum menyentuh DNS. Ini menampilkan apakah record kunci yang diterbitkan ada, terbentuk dengan baik dan lengkap — memisahkan “DNS Anda rusak” (penyebab 2–4) dari “DNS Anda baik-baik saja, pesan sedang diubah” (penyebab 1) dalam satu langkah.
- Baca header
Authentication-Resultsdari pesan yang gagal.body hash did not verify→ penyebab 1, pergi ke panduan body-hash — tersangka biasa adalah footer dan penafian gateway, dan perbaikannya adalah menandatangani setelah modifikasi.no key for signature→ penyebab 4, pergi ke panduan selector. Kegagalan tanda tangan biasa → lanjutkan. - Periksa kunci yang diterbitkan untuk pemotongan. Cari
<selector>._domainkey.<yourdomain>sebagai TXT (dig TXT selector._domainkey.example.com). Kunci publik RSA 2048-bit lebih panjang dari batas 255 karakter satu string TXT, sehingga harus diterbitkan sebagai beberapa string yang dikutip yang digabungkan penerima — dan UI web panel DNS terkenal karena secara diam-diam memotong tempelan, merusak pemisahan, atau menyisipkan spasi dan tanda kutip ke dalam nilaip=. Bandingkan karakter demi karakter dengan kunci yang dihasilkan penandatangan Anda; panduan setup DKIM kami mencakup keanehan per provider. - Konfirmasi kunci yang diterbitkan cocok dengan penandatangan. Setelah rotasi kunci, migrasi provider, atau koneksi ulang ESP, umum bagi penandatangan untuk menyimpan kunci privat baru sementara DNS masih melayani kunci publik lama — setiap tanda tangan diverifikasi terhadap kunci yang salah dan gagal. Salin ulang record terkini dari konsol admin provider Anda. Lebih baik: di mana provider menawarkan delegasi CNAME, gunakan — provider merotasi kunci di sisi mereka dan seluruh kelas kegagalan ini hilang. Dan jangan pernah menghapus selector lama sampai lalu lintas yang ditandatangani dengannya telah terkuras.
- Perbaiki pengaturan penandatanganan, bukan hanya recordnya. Atur kanonisasi ke
c=relaxed/relaxed, yang mentoleransi pembungkusan ulang spasi dan re-folding header yang dilakukan server perantara secara sah; kanonisasisimplegagal pada perubahan yang bahkan tidak terlihat manusia. Dan jangan gunakan tagl=body-length: dimaksudkan untuk membiarkan footer masuk, tetapi membiarkan siapapun menambahkan konten ke pesan yang ditandatangani tanpa merusak tanda tangan — vektor serangan nyata — dan masih tidak bertahan sebagian besar modifikasi gateway. Tidak adal=adalah pilihan yang lebih aman sekaligus lebih andal. - Pindai ulang, kemudian periksa keselarasan. Tanda tangan yang valid hanya membantu DMARC jika domain
d=selaras dengan domain From Anda — tanda tangan yang tervalidasi sebagaid=yourcompany.gappssmtp.comlulus DKIM dan masih gagal DMARC. Jika itu Anda, lihat jebakan tanda tangan default, kemudian kerjakan apapun yang ditandai pemindaian di halaman perbaiki DKIM.
Pertanyaan yang Sering Diajukan
Apakah “DKIM signature not valid” sama dengan “body hash did not verify”? Pesan body-hash adalah sub-kasus spesifik: body berubah setelah penandatanganan (footer, penafian, penulisan ulang daftar). “Signature not valid” adalah verdict payung untuk verifikasi yang gagal, termasuk kunci buruk dan perubahan header — itulah mengapa langkah 2 di atas adalah membaca header, dan mengapa kasus body-hash memiliki panduannya sendiri.
Apakah tanda tangan DKIM yang tidak valid berarti email saya ditolak? Tidak dengan sendirinya — penerima memperlakukan tanda tangan yang rusak seperti yang hilang. Kerusakan terjadi melalui DMARC: jika SPF juga tidak lulus dengan keselarasan, pesan gagal DMARC dan kebijakan yang diterbitkan berlaku. Per sensus 2026-06-29, hanya 3.87% dari 261,086,232 domain yang dinilai yang menyimpan SPF, DKIM dan kebijakan DMARC yang menegakkan bersama-sama — tetapi Gmail dan Microsoft kini mengharapkan tepat itu dari pengirim, sehingga leg DKIM yang rusak merugikan deliverability bahkan sebelum penolakan.
Haruskah saya menggunakan kunci DKIM 1024-bit atau 2048-bit? 2048-bit — kunci 1024-bit berada di bawah rekomendasi kriptografi saat ini dan beberapa penerima menilainya lebih rendah. Satu-satunya tantangannya adalah operasional: kunci 2048-bit tidak muat dalam satu string TXT 255 karakter, sehingga harus dipecah dengan benar (penyebab 2 di atas). Delegasi CNAME ke provider Anda melewati masalah pemecahan sepenuhnya.
DKIM saya lulus di pemeriksa tetapi DMARC masih gagal — bagaimana?
Hampir pasti keselarasan: tanda tangan tervalidasi, tetapi domain d=-nya (misalnya, yourcompany.gappssmtp.com atau yourtenant.onmicrosoft.com) tidak cocok dengan domain From Anda, sehingga DMARC tidak dapat menggunakannya. Aktifkan penandatanganan domain kustom provider Anda — panduan lengkapnya ada di panduan jebakan tanda tangan default.
Bisakah saya mematikan DKIM jika terus gagal? Tidak — sejak mandat pengirim massal 2024, Gmail dan Yahoo memerlukan DKIM untuk pengirim volume, dan kebijakan DMARC yang menegakkan secara realistis membutuhkan DKIM karena SPF saja rusak saat penerusan. Perbaiki tanda tangan; penyebab di atas semuanya dapat diperbaiki dalam satu sore.
Kirimkan laporan kepada pemilik
Jika Anda memperbaiki ini untuk klien atau perusahaan, tutup dengan bukti. Jalankan ulang pemindaian gratis setelah perubahan Anda dan teruskan laporan yang dinilai kepada pemilik bisnis: bertanggal, bahasa mudah dipahami, DKIM menampilkan hijau. Itulah artefak yang mereka butuhkan untuk perpanjangan asuransi siber dan kuesioner keamanan pemasok berikutnya — perbedaan antara “saya memperbaiki sesuatu di DNS” dan dokumentasi sebelum-dan-sesudah yang terdokumentasi yang mengatakan domain mengautentikasi emailnya.
Periksa domain Anda → · Panduan “Body hash did not verify” → · Perbaiki DKIM → · Cara kami menilai → · Hanya data agregat. Data disimpan dan diproses di EU.