DKIM Gagal Setelah Mengganti Alat Email: Panduan Migrasi CNAME dan Selector (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 rusak setelah pergantian alat karena dua alasan mekanis: panel DNS Anda merusak target CNAME alat baru — biasanya dengan menambahkan zona Anda sendiri — atau selector alat lama dihapus sebelum emailnya terkuras. Hanya 3.87% domain — 10,092,481 — yang menyelesaikan triad SPF+DKIM+DMARC, menurut sensus Defaults.Exposed dari 261,086,232 domain yang dinilai.

Urutan perbaikan: pindai domain, kemudian periksa target yang disimpan setiap CNAME baru dengan dig — target yang berakhir dengan nama domain Anda sendiri adalah bukti kuat. Perbaiki record di nameserver autoritatif, konfirmasi alat baru menandatangani dan lulus sebelum merutekan email nyata melaluinya, dan pertahankan selector alat lama diterbitkan sampai lalu lintasnya terkuras.

Mengapa DKIM rusak ketika Anda mengganti alat?

Tidak ada yang berubah dari DKIM sendiri — selector Anda yang berubah. Alat lama menandatangani dengan selectornya; yang baru menandatangani dengan yang berbeda, biasanya didelegasikan melalui dua atau tiga record CNAME yang ditambahkan selama orientasi. Empat jebakan mencakup hampir setiap kegagalan DKIM pasca-migrasi:

Panel DNS Anda menambahkan zona ke target CNAME. Banyak panel memperlakukan nama host yang ditempel sebagai relatif dan diam-diam menyimpan target.provider.com.yourdomain.com alih-alih target.provider.com. Record ada, panel menampilkan centang hijau, dan ia me-resolve ke tidak ada.
Kebingungan trailing dot. Beberapa panel memerlukan trailing dot (target.provider.com.) untuk berarti “absolut — jangan tambahkan zona saya”; yang lain menolak dot sebagai tidak valid dan menangani absoluteness sendiri. Nilai yang sama yang ditempel benar di satu panel dan rusak di panel berikutnya.
Selector alat lama dihapus pada hari pergantian. Email yang sudah ditandatangani alat lama berada dalam antrian percobaan ulang dan jalur penerusan selama berhari-hari; menghapus selectornya — atau menutup akun lama, yang mematikan CNAME yang didelegasikan — secara retroaktif merusak email tersebut.
Anda memverifikasi di nameserver yang salah. Jika migrasi menyertakan perubahan nameserver, record yang diperbaiki mungkin ada di satu set NS sementara penerima masih mengquery yang lain.

Hanya 51.84% dari 261 juta domain dalam sensus yang menyajikan kunci DKIM yang dapat ditemukan saat pemindaian (data per 2026-06-29).

Migrasi yang sama biasanya meninggalkan serpihan SPF juga — 1,013,416 domain, sekitar 1 dari 138 dari yang mencoba SPF, menjalankan dua record v=spf1, tanda klasik bahwa pergantian provider menambahkan record alih-alih menggabungkan. Sisi migrasi itu memiliki panduan sendiri: SPF berhenti berfungsi setelah Anda mengganti provider email.

Bagaimana cara mengidentifikasi record CNAME yang rusak?

Jangan percaya panel — tanya DNS apa yang sebenarnya disimpan. Query target CNAME untuk setiap selector yang diberikan alat baru kepada Anda. Contoh ilustratif, meniru selector yang didelegasikan gaya SendGrid (bentuk target provider Anda akan berbeda):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

Provider meminta s1.domainkey.u1234567.wl123.sendgrid.net — tetapi target yang disimpan berakhir dengan .yourdomain.com. Panel menambahkan zona; nama itu me-resolve ke tidak ada, sehingga penerima tidak menemukan kunci. Versi yang sehat:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Trailing dot tunggal dalam output dig adalah normal — ini menandai nama yang sepenuhnya qualified.) Jika target benar, ikuti satu hop: dig TXT s1._domainkey.yourdomain.com +short harus mengembalikan kunci provider. Jawaban kosong dengan CNAME yang benar berarti masalahnya ada di sisi provider dari delegasi — selesaikan langkah verifikasi mereka, atau lihat DKIM “no key for signature” untuk diagnosis tingkat selector.

Runbook migrasi: sebelum, selama, sesudah

Kegagalan biasanya bukan recordnya — tapi urutannya. Migrasi DKIM salah pada saat cutover karena verifikasi terjadi setelah pergantian, ketika email nyata sudah gagal.

Fase	Yang harus dilakukan	Gerbang sebelum melanjutkan
Sebelum pergantian	Tambahkan CNAME DKIM alat baru (dan record bounce-domain), kemudian buktikan: `dig` setiap target CNAME yang disimpan dari luar jaringan Anda, selesaikan langkah verifikasi alat sendiri, dan kirim uji melalui alat baru ke kotak surat yang Anda kendalikan	Pesan uji menampilkan `dkim=pass` dengan `d=` = domain Anda — jangan pernah merutekan email nyata melalui alat yang belum diverifikasi
Hari pergantian	Pindahkan lalu lintas nyata ke alat baru. Jangan sentuh apapun milik alat lama: biarkan selector, CNAME, dan akun tetap hidup	Email alat baru lulus di penerima nyata; alat lama terus lulus untuk apapun yang masih mengalir melaluinya
Setelah email terkuras	Pantau laporan agregat DMARC sampai selector alat lama berhenti muncul (antrian percobaan ulang dan penerusan berjalan selama berhari-hari — tunggu seminggu atau lebih), kemudian pensiunkan record dan akunnya secara sengaja	Selector lama tidak ada dalam laporan ≥ 7 hari sebelum penghapusan

Baris yang dicetak tebal adalah tempat migrasi diselamatkan atau hilang: setiap pemeriksaan di dalamnya dapat dilakukan berhari-hari sebelum cutover, tanpa risiko pada email langsung. Mekanika pensiun selector — termasuk mengapa menerbitkan ulang dengan p= kosong lebih baik dari penghapusan — dibahas dalam runbook rotasi; tabel ini tentang pengurutan pergantian alat itu sendiri.

Bagaimana cara memperbaiki DKIM setelah pergantian?

Jalankan pemindaian gratis di defaults.exposed sebelum menyentuh DNS. Ini membaca record langsung Anda dan menampilkan apa yang benar-benar dilihat penerima — termasuk target CNAME yang mendapatkan zona ditambahkan dan selector yang tidak dapat di-resolve.
Daftarkan record DKIM yang diharapkan alat baru. Dari konsol adminnya — untuk provider kotak surat, panduan setup Google Workspace dan Microsoft 365 menunjukkan di mana; alat newsletter dan CRM mencantumkan CNAME mereka di bawah autentikasi domain (lihat email Mailchimp/Brevo/Klaviyo gagal DMARC).
Periksa nilai yang disimpan setiap record dengan dig CNAME <name> +short dan bandingkan karakter demi karakter dengan apa yang diminta alat. Target yang berakhir dengan domain Anda sendiri = zona ditambahkan; masukkan ulang, dan jika panel terus menambahkan, tambahkan trailing dot (atau hapus, jika panel menolak dot).
Verifikasi di nameserver autoritatif. dig +short NS yourdomain.com, kemudian ulangi pemeriksaan CNAME @<nameserver tersebut>. Jika migrasi mengubah nameserver, periksa kedua set — penerima mungkin masih mengquery yang lama sampai delegasi menyebar.
Jalankan ulang verifikasi alat dan kirim pesan uji. Header Authentication-Results harus menampilkan dkim=pass dengan d= sama dengan domain Anda — kelulusan pada domain default alat tidak selaras untuk DMARC.
Biarkan selector alat lama diterbitkan sampai emailnya terkuras, kemudian pensiunkan secara sengaja. Kemudian pindai ulang, dan kerjakan apapun lain yang ditandai di halaman perbaiki DKIM.

Pertanyaan yang Sering Diajukan

Apakah saya memerlukan trailing dot pada CNAME DKIM saya atau tidak? Ini sepenuhnya bergantung pada panel. Dot berarti “nama absolut — jangan tambahkan zona saya”; beberapa panel memerlukannya, beberapa menambahkannya untuk Anda, beberapa menolaknya. Satu-satunya tes yang penting adalah output dari dig CNAME <selector>._domainkey.yourdomain.com +short setelah disimpan: jika target berakhir dengan domain Anda sendiri, panel menambahkan zona dan Anda perlu dot (atau format input yang berbeda).

Bisakah saya menghapus record DKIM alat lama pada hari pergantian? Tidak. Email yang ditandatangani alat lama masih ada dalam antrian percobaan ulang dan jalur penerusan, dan menghapus kunci yang ditunjuknya secara retroaktif merusak pesan-pesan tersebut. Pertahankan selector lama aktif sampai berhenti muncul dalam laporan agregat DMARC Anda — seminggu atau lebih — dan jangan tutup akun lama sebelum itu juga.

Panel DNS saya dan alat baru keduanya mengatakan “verified”, tetapi penerima masih gagal DKIM. Bagaimana? Dua kasus umum: alat memverifikasi terhadap pemeriksaan yang di-cache sementara nameserver autoritatif melayani sesuatu yang lain (query mereka langsung dengan dig @<ns>), atau DKIM lulus tetapi pada domain penandatanganan default alat alih-alih domain Anda, sehingga DMARC masih gagal keselarasan. Pemindaian membedakan keduanya.

Bisakah record DKIM kedua alat ada bersama selama tumpang tindih? Ya — dan memang seharusnya. DKIM tidak memiliki aturan single-record: setiap selector adalah nama DNS tersendiri, sehingga record kedua alat hidup berdampingan tanpa konflik, yang membuat aturan pertahankan-selector-lama-sampai-email-terkuras bebas untuk diikuti. (SPF adalah kebalikannya — dua record v=spf1 membatalkannya, itulah mengapa panduan migrasi SPF adalah tentang menggabungkan.)

Kirimkan laporan kepada pemilik

Jika Anda menjalankan migrasi ini untuk klien atau perusahaan, tutup dengan bukti. Setelah alat baru menandatangani dan selaras, jalankan ulang pemindaian gratis dan teruskan laporan yang dinilai kepada pemilik bisnis: bukti bertanggal, bahasa mudah dipahami, bahwa pergantian meninggalkan domain yang terautentikasi sepenuhnya. Itulah artefak yang mereka butuhkan untuk perpanjangan asuransi siber dan kuesioner keamanan pemasok berikutnya — mengubah “migrasi sudah selesai” dari klaim menjadi dokumen.

Periksa DKIM Anda gratis

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

Periksa domain Anda → · SPF rusak setelah mengganti provider → · Perbaiki DKIM → · Siapkan DKIM di Google Workspace → · Hanya data agregat. Data disimpan dan diproses di EU.