Defaults.Exposed

Defaults.ExposedPerbaikanGuides

DKIM "No Key for Signature": Perbaikan Selector dan Rotasi (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.

“No key for signature” berarti penerima melakukan query record DNS yang ditunjuk tanda tangan DKIM Anda — selector._domainkey.yourdomain — dan tidak menemukan kunci: belum pernah diterbitkan, atau dihapus saat rotasi. Terbitkan selector yang benar-benar digunakan penandatangan Anda. Hanya 10,092,481 domain — 3.87% — yang menyelesaikan triad SPF+DKIM+DMARC, menurut sensus Defaults.Exposed dari 261,086,232 domain yang dinilai.

Perbaikannya adalah satu record DNS, ditemukan dalam satu header. Baca tag s= dan d= dari header DKIM-Signature nyata untuk mengetahui selector yang digunakan email Anda, terbitkan (atau perbaiki) record yang tepat itu, dan pilih delegasi CNAME agar provider merotasi kunci untuk Anda. Kemudian rotasi menggunakan panduan di bawah ini — kesalahan ini biasanya berarti seseorang menghapus selector lama terlalu cepat.

Apa arti “dkim no key for signature”?

Setiap tanda tangan DKIM membawa dua tag yang memberi tahu penerima di mana mengambil kunci publik: d= (domain penandatangan) dan s= (selector). Penerima melakukan query satu nama DNS yang dibangun dari keduanya — s._domainkey.d — untuk kunci tersebut. “No key for signature” berarti query itu kembali kosong: tanda tangan ada, tetapi kunci yang dinamai tidak ada.

Kata-kata ini muncul di header Authentication-Results dan laporan agregat DMARC — frasa tepatnya bervariasi per penerima, tetapi dua variasi penting:

String hasil (fragmen, seperti yang diamati secara luas)Yang sebenarnya terjadiSementara?
dkim=temperror (no key for signature)Query DNS gagal atau habis waktu — penerima tidak bisa mendapatkan jawaban sama sekaliYa — percobaan ulang sering lulus; selidiki hanya jika persisten
dkim=permerror (no key for signature)Query DNS berhasil dan jawabannya “tidak ada record” — selector benar-benar tidak adaTidak — record hilang sampai Anda menerbitkannya

Temperror sekali adalah cuaca DNS. Permerror — atau temperror yang berulang di berbagai hari dan penerima — berarti record yang ditunjuk tanda tangan tidak ada di zona Anda. Itulah panduan ini.

Konsekuensinya: tanda tangan yang tidak dapat diverifikasi dianggap sebagai tidak ada DKIM sama sekali, sehingga DMARC jatuh kembali ke SPF saja — dan SPF rusak saat penerusan. Jika tanda tangan ada tetapi tidak valid daripada hilang (body hash, kunci rusak), itu adalah kegagalan berbeda — lihat “DKIM signature not valid”.

Bagaimana cara menemukan selector yang digunakan email saya?

Jangan menebak dari dokumentasi provider — baca dari pesan nyata:

  1. Kirim pesan dari sistem yang terpengaruh ke kotak surat yang Anda kendalikan (alamat Gmail berfungsi dengan baik).
  2. Buka sumber mentah (“Show original” di Gmail, “View message source” di Outlook).
  3. Temukan header DKIM-Signature: dan baca dua tag: s= adalah selector, d= adalah domain penandatangan. Contoh ilustrasi: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
  4. Record yang di-query penerima adalah s._domainkey.d — di sini, mail2026._domainkey.yourdomain.com. Periksa sendiri: dig TXT mail2026._domainkey.yourdomain.com +short. Jawaban kosong = kesalahan nyata untuk setiap penerima.
  5. Ulangi per sistem pengiriman. Sebuah pesan dapat membawa beberapa tanda tangan DKIM — provider kotak surat, alat newsletter, helpdesk — masing-masing dengan pasangan s=/d= dan record-nya sendiri. Perbaiki yang gagal, dan perhatikan d=-nya: hanya tanda tangan yang d=-nya cocok dengan domain From Anda yang membantu DMARC.

Mengapa record selector hilang?

Empat penyebab mencakup hampir semua kesalahan ini — periksa dalam urutan ini:

  1. Belum pernah diterbitkan. Penandatangan diaktifkan (atau default aktif) dengan selector yang tidak pernah ditambahkan ke DNS. Umum dengan alat dan gateway baru yang menandatangani secara tak terduga.
  2. Dihapus saat rotasi. Seseorang “membersihkan” selector lama sementara pesan yang ditandatangani masih dalam transit, antri untuk dicoba ulang, atau menunggu penerusan. Email itu sudah ditandatangani dengan s=old; menghapus old._domainkey secara retroaktif merusak semua pesan tersebut.
  3. UI DNS Anda merusak target CNAME. Banyak provider mendelegasikan melalui CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), dan banyak panel DNS secara diam-diam menambahkan zona Anda ke target — menyimpan s1.domainkey.u123.esp.com.yourdomain.com, yang tidak dapat di-resolve. Verifikasi target: dig CNAME s1._domainkey.yourdomain.com +short. Jebakan yang sama terjadi saat migrasi alat — lihat DKIM gagal setelah mengganti alat email.
  4. Provider merotasi, zona Anda tidak. Kunci provider yang ditempel sebagai record TXT statis (alih-alih CNAME mereka) diorpan oleh rotasi terjadwal mereka — penandatangan pindah ke selector yang belum pernah Anda terbitkan. Hanya 51.84% dari 261 juta domain dalam sensus yang menyajikan kunci DKIM yang dapat ditemukan saat pemindaian (data per 2026-06-29).

Bagaimana cara memperbaiki “no key for signature”?

  1. Jalankan pemindaian gratis di defaults.exposed sebelum menyentuh DNS. Sistem membaca DKIM, SPF dan DMARC langsung Anda dan menampilkan apa yang benar-benar dilihat penerima — termasuk apakah selector dapat di-resolve dan apakah target CNAME rusak.
  2. Terbitkan selector yang benar-benar digunakan penandatangan — nilai s= dari header, bukan yang ada di panduan lama. Dapatkan record dari konsol admin provider Anda (setup DKIM Google Workspace · setup DKIM Microsoft 365) dan tambahkan tepat di s._domainkey.yourdomain.com.
  3. Pilih delegasi CNAME daripada menempel kunci TXT. Jika provider Anda menawarkan DKIM CNAME, gunakan itu: kunci berada di zona mereka, sehingga mereka merotasinya tanpa Anda menyentuh DNS lagi — penyebab 4 menjadi tidak mungkin. Platform newsletter hampir semuanya bekerja seperti ini; lihat email Mailchimp/Brevo/Klaviyo gagal DMARC.
  4. Verifikasi dari luar panel Anda. dig TXT s._domainkey.yourdomain.com +short (atau dig CNAME … untuk selector yang didelegasikan) dari mesin di luar jaringan Anda. Panel yang menampilkan record tidak membuktikan apapun jika zona melayani sesuatu yang lain.
  5. Pindai ulang dan kirim ulang pesan uji. Authentication-Results seharusnya sekarang membaca dkim=pass. Kemudian kerjakan apapun yang ditandai pemindaian di halaman perbaiki DKIM — tanda tangan yang lulus tetapi tidak selaras dengan domain From masih gagal DMARC.

Bagaimana cara merotasi kunci DKIM tanpa menyebabkan kesalahan ini?

Rotasi adalah tempat setup yang berfungsi rusak. Aturan yang mencegahnya: selector hanya dihapus setelah pesan terakhir yang ditandatangani dengannya telah terkuras — tidak pernah saat cutover. Email yang ditandatangani hidup lebih lama dari yang Anda pikirkan: antrian percobaan ulang berjalan selama berhari-hari, dan pesan yang diteruskan diverifikasi ulang setiap kali bergerak.

LangkahTindakanGerbang sebelum langkah berikutnya
1. TambahkanTerbitkan selector baru (s2._domainkey…) bersama yang lamadig mengkonfirmasi ia dapat di-resolve dari luar
2. AlihkanArahkan penandatangan ke selector baruPesan uji menampilkan s=s2 dan dkim=pass
3. TungguBiarkan selector lama tetap diterbitkan sementara lalu lintas in-flight, antri dan diteruskan terkuras≥ 7 hari; pantau laporan agregat DMARC sampai selector lama berhenti muncul
4. PensiunHapus kunci lama — atau lebih baik, terbitkan ulang dengan tag p= kosong: “pensiun”, bukan “tidak pernah ada”Jangan pernah memulai ini saat cutover — penghapusan prematur adalah penyebab #1 “no key for signature”

Dengan delegasi CNAME, provider Anda menjalankan panduan ini persis di dalam zona mereka sendiri dan Anda tidak pernah melihatnya — argumen terkuat untuk mendelegasikan.

Pertanyaan yang Sering Diajukan

Apakah “no key for signature” adalah temperror atau permerror? Kedua string ada: temperror adalah lookup DNS yang gagal atau habis waktu — sementara, sering hilang saat dicoba ulang — sementara permerror berarti DNS menjawab “tidak ada record”. Temperror yang berulang di berbagai penerima biasanya juga ternyata adalah record yang benar-benar hilang. Periksa dengan dig dan percayai jawabannya, bukan labelnya.

Apakah kesalahan ini berarti seseorang memalsukan domain saya? Tidak — spoofer tidak akan menandatangani dengan selector Anda. Ini berarti email Anda sendiri membawa tanda tangan yang tidak dapat diverifikasi penerima, sehingga dianggap tidak ditandatangani dan DMARC bergantung pada SPF saja. Autentikasi penuh yang selaras jarang: hanya 10,092,481 dari 261,086,232 domain (3.87%) menyelesaikan triad SPF+DKIM+DMARC dalam sensus Defaults.Exposed (data per 2026-06-29).

Bisakah saya langsung menghapus selector lama setelah yang baru berfungsi? Tidak segera. Pesan yang ditandatangani dengannya masih dalam antrian percobaan ulang dan jalur penerusan; menghapus kunci yang ditunjuk secara retroaktif merusak pesan-pesan tersebut. Simpan record lama setidaknya satu minggu, pantau laporan DMARC Anda sampai selector lama berhenti muncul, kemudian pensiunkan — idealnya dengan p= kosong daripada penghapusan.

Pemeriksa provider saya mengatakan DKIM dikonfigurasi, tetapi penerima masih melaporkan tidak ada kunci. Bagaimana? Hampir selalu jebakan target CNAME: panel DNS Anda menambahkan zona ke target (…esp.com.yourdomain.com), sehingga record ada tetapi tidak menunjuk kemana-mana. dig CNAME selector._domainkey.yourdomain.com +short menampilkan target yang disimpan secara verbatim — bandingkan karakter demi karakter dengan apa yang diminta provider.

Kirimkan laporan kepada pemilik

Jika Anda memperbaiki ini untuk klien atau perusahaan, tutup dengan bukti. Jalankan ulang pemindaian gratis setelah selector dapat di-resolve dan teruskan laporan yang dinilai kepada pemilik bisnis: bertanggal, bahasa mudah dipahami, DKIM kini terverifikasi. Itulah artefak yang mereka butuhkan untuk perpanjangan asuransi siber dan kuesioner keamanan pemasok berikutnya — bukti kontrol yang berfungsi, bukan hanya tiket yang ditutup.

Periksa DKIM Anda gratis

Lihat apakah selector Anda dapat di-resolve — dan persis apa yang harus diperbaiki — secara privat dan hanya untuk pemilik.

Periksa domain Anda → · “DKIM signature not valid” → · Perbaiki DKIM → · Setup DKIM di Google Workspace → · Hanya data agregat. Data disimpan dan diproses di EU.