Tema

Alat populer

Cek DKIM

Cek record DKIM sebuah domain seperti cara server email penerima menemukannya, atau tempel email untuk menguji tanda tangannya: selector mana yang menjawab, siapa yang menandatangani, sekuat apa tiap kunci, dan apakah aligned dengan DMARC.

Sumber: 140 selector umum dari 67 penyedia email, ditanyakan lewat Google Public DNS (di belakangnya Cloudflare) · pengecekan kunci menurut RFC 6376 dan RFC 8301 · email diverifikasi di browser Anda · tidak ada data tentang Anda yang disimpan

Menanyakan 140 selector yang dipakai penyedia email di selector._domainkey. plus domain, karena DNS tidak bisa mendaftarkannya

Coba

Cara cek record DKIM (DKIM check)

Ketik domain di atas: pemeriksa DKIM ini menanyakan 140 selector yang dipakai penyedia email, menampilkan setiap kunci yang ditemukan beserta ukuran dan penyedianya, dan berterus terang jika tidak menemukan apa pun. Tahu selector-nya? Pilih Domain + selector dan selector itu dicek lebih dulu.

Secara manual Anda butuh selector, karena DNS tidak bisa mendaftarkannya: dig +short TXT selector._domainkey.example.com, atau nslookup -type=TXT dengan nama yang sama di Windows. Selector adalah s= di DKIM-Signature email mana pun (RFC 6376 §3.6.2.1).

dig menampilkan teksnya, bukan artinya: ia tidak mendekode ukuran kunci, tidak mengikuti CNAME penyedia, dan tidak membedakan slot cadangan dari yang rusak. Itulah tambahan dari DKIM record checker ini.

dig +short TXT selector._domainkey.example.com

Setiap string TXT di nama itu: gabungkan untuk membaca kuncinya.

Yang ditampilkan dig, dan yang tidak

terminal

$ dig +short TXT 20251104._domainkey.google.com 1

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ…" "…k2A8ZfpQIDAQAB"2

$ dig +short TXT 20251104._domainkey.google.com | tr -d '" \n' | sed 's/.*p=//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1 3

Public-Key: (2048 bit)

$ dig +short TXT selector1._domainkey.microsoft.com 4

selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com.

  1. 1Namanya selector._domainkey.domainTanpa selector, tidak ada jawaban: DNS tidak punya perintah “daftar semua kunci”.
  2. 2Dua string, satu recordSatu string TXT memuat 255 byte, jadi kunci 2048 bit dipecah; penerima menggabungkannya tanpa apa pun di antaranya.
  3. 3Ukuran asli kunciopenssl mendekode p=: 2048 bit adalah yang diminta RFC 8301.
  4. 4CNAME ke penyediaTidak ada TXT di baliknya: slot cadangan Microsoft 365, bukan kesalahan.
Kunci google.com dan selector1 milik microsoft.com seperti dijawab DNS Cloudflare pada 25 Oktober 2026.

Membaca hasil: penyisiran selector

Jawabannya datang lebih dulu, sebagai satu kalimat. Di bawahnya siapa yang menandatangani dan kuncinya sendiri, tiap tag diwarnai tepat di atas karakternya dengan ukuran kunci pada skala RFC 8301; di latar navy, setiap selector yang ditanyakan, supaya Anda tahu apa saja yang dicoba.

Tanpa nilai: kunci yang dipensiunkan atau selector cadangan kosong milik penyedia itu normal, dan “tidak ditemukan di selector umum” tidak pernah berarti “tidak ada DKIM”.

Cek DKIM untuk github.com: dua belas kunci dari enam penyedia, penyisiran selector, dan pengukur ukuran kunciCek DKIM untuk github.com: dua belas kunci dari enam penyedia, penyisiran selector, dan pengukur ukuran kunciKesimpulanSatu kalimat: berapa kunci, dan apa yang perlu dilakukan.Siapa yang menandatanganiSatu kartu per penyedia, ditemukan lewat CNAME atau selector yang didokumentasikan. Tiap chip selector membuka kuncinya.KuncinyaTiap tag diwarnai di atas karakternya, dan ukuran kunci pada skala RFC 8301.Penyisiran selectorSetiap nama yang ditanyakan, menyala saat menjawab: hijau kunci, kuning 1024 bit, garis putus-putus slot cadangan.Alignment DMARCApakah kunci dengan d= domain ini aligned dengan kebijakan DMARC-nya.
Hasil cek DKIM github.com: kesimpulan, siapa yang menandatangani, kunci yang dipecah per tag beserta ukurannya, dan di latar navy setiap selector yang ditanyakan. Pilih sebuah angka untuk melihat apa yang ditunjukkan tiap bagian.

Apa itu DKIM? Pengertian dan cara kerjanya

DKIM adalah tanda tangan yang ditambahkan server pengirim ke setiap pesan (DomainKeys Identified Mail), yang dicek penerima dengan kunci publik yang dipublikasikan domain di DNS (RFC 6376). Tanda tangan yang valid membuktikan dua hal: domain di d= menandatanganinya, dan bagian yang ditandatangani tidak berubah sejak itu.

Pengirim meng-hash isi pesan ke bh= dan menandatangani header pilihan plus hash itu dengan kunci privatnya menjadi b=. Penerima membaca d= dan s=, mengambil kunci di s._domainkey.d, lalu mengulang keduanya. Satu byte yang berubah di isi, atau di header yang ditandatangani, dan hasilnya gagal.

DKIM tidak mengatur apa yang harus dilakukan saat gagal, dan domain mana pun bisa menandatangani. Itu tugas DMARC: ia meminta tanda tangan yang lolos dengan d= yang cocok dengan domain From:.

Satu pesan, ditandatangani di pengirim dan dicek di penerima

Server example.commenandatangani dengan kunci privatnya
pesan, beserta DKIM-Signature-nya
PenerimaGmail, Outlook.com, Yahoo…

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=dnsrobot-sample; h=from:from:to:subject:…; bh=fohb/a+auh1W9cUN…; b=fF0aMr3Uo+mbgG…

dnsrobot-sample._domainkey.example.com TXT?"v=DKIM1; k=rsa; p=MIIBIjANBgkq…"RSA 2048

Pesan seperti saat dikirim

  • Hash isi cocok dengan bh=
  • Tanda tangan header terverifikasi

dkim=pass header.d=example.com

Pesan yang sama, Subject-nya diubah di perjalanan

  • Hash isi cocok dengan bh=
  • Tanda tangan header tidak terverifikasi

dkim=fail (signature-mismatch)

Kedua hasil dihitung engine, dari email contoh di halaman ini dan email yang sama dengan Subject yang diubah setelah ditandatangani. RFC 6376 §3.7, RFC 8301.

Apa itu selector DKIM, dan bagaimana menemukan milik saya?

Selector adalah nama satu kunci DKIM: s= di tanda tangan, dan label pertama dari nama DNS tempat kunci berada (s1._domainkey.github.com). Sebuah domain boleh punya sebanyak yang ia mau: satu per penyedia, per server, per tahun (RFC 6376 §3.1).

Untuk menemukan milik Anda, buka email apa pun yang dikirim domain itu dan lihat versi aslinya: di Gmail, Lainnya (⋮) › Tampilkan versi asli menampilkan DKIM-Signature, dan s= di dalamnya adalah selector. Atau tempel email ke Verifikasi email di atas.

Kebanyakan penyedia memakai nama tetap, jadi penyisiran menemukannya. Amazon SES, Postmark, SparkPost, dan HubSpot membuat satu nama per akun, yang hanya bisa diketahui dari email atau dasbor penyedia.

Dari tanda tangan ke kunci, dan nama yang dipakai penyedia

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=s1; …

s1._domainkey.github.comCNAME s1.domainkey.u51742174.wl175.sendgrid.netRSA 2048

Google Workspacegoogleadmin bisa mengubah prefiks
Microsoft 365selector1 · selector2CNAME ke tenant; satu aktif, satu cadangan
Twilio SendGrids1 · s2CNAME ke u<id>.wl<n>.sendgrid.net
Mailchimpk2 · k3CNAME ke dkim2/dkim3.mcsv.net
Fastmailfm1 · fm2 · fm3tiga CNAME, satu terisi pada satu waktu
Proton Mailprotonmail · 2 · 3CNAME ke domains.proton.ch
Amazon SES3 token acakmasing-masing 32 karakter acak: tidak bisa ditebak
Postmark20240101000000pmtanggal dan “pm”: tidak bisa ditebak
SparkPostscph + MMYYscph dan bulan kunci dibuat
HubSpoths1-<HubID>nomor akun Anda
s1 milik github.com seperti dijawab DNS Cloudflare pada 25 Oktober 2026. Nama penyedia dari dokumentasi mereka sendiri (67 penyedia, 140 selector dalam penyisiran).

Format record DKIM: setiap tag dijelaskan

Record DKIM adalah record TXT berisi pasangan tag=value yang dipisahkan titik koma; hanya p=, kunci publik, yang wajib. v=DKIM1 opsional tetapi, jika ada, harus di awal (RFC 6376 §3.6.1).

k= menyebut jenis kunci (rsa kecuali tertulis ed25519), t= membawa flag (y pengujian, s strict), h= membatasi hash dan s= membatasi layanan. p= kosong mencabut kunci dengan sengaja.

Nama tag peka huruf besar-kecil dan tag yang berulang membuat record tidak valid. Tag yang tidak dikenal diabaikan.

Record, tag demi tag

v=DKIM1; k=rsa; t=s; h=sha256; p=MIIBIjANBgkqhkiG9w…IDAQAB

TagMengaturNilaiBawaanCatatan
v=VersiDKIM1DKIM1disarankan; di awal jika ada
k=Jenis kuncirsa · ed25519rsajenis tak dikenal: kunci diabaikan
p=Kunci publik (base64)kuncinya, atau kosongwajibkosong = dicabut
t=Flagy pengujian · s stricttidak aday: diperlakukan sebagai tanpa tanda tangan
h=Hash yang diizinkansha256 (sha1 dilarang)semuahanya sha1 gagal (RFC 8301)
s=Jenis layanan* · email*hanya layanan lain: diabaikan
n=Catatan untuk manusiateks apa pun–tidak pernah dibaca perangkat lunak

Sepanjang apa p=, dan berapa string TXT yang dibutuhkan

RSA 1024216 karakter · 1 string TXT
RSA 2048392 karakter · 2 string TXT
RSA 3072564 karakter · 3 string TXT
RSA 4096736 karakter · 3 string TXT
Ed2551944 karakter · 1 string TXT

batas string TXT 255 byte (dengan menghitung “v=DKIM1; k=rsa; p=”)

Panjang p= adalah kunci SubjectPublicKeyInfo yang diukur. yahoo.com memublikasikan kunci 2048 bit-nya dalam 4 string: pemecahan apa pun boleh, karena penerima menggabungkannya tanpa apa pun di antaranya (RFC 6376 §3.6.2.2).

Kunci DKIM 1024 vs 2048 bit, dan cara merotasinya

Pakai RSA 2048 bit. RFC 8301 tetap mewajibkan verifikator menerima kunci 1024 bit, tetapi meminta penanda tangan memakai minimal 2048, dan meminta verifikator menolak kunci di bawah 1024 bit. M3AAWG menyebut 1024 bit “di ambang serangan” dan melaporkan kunci 512 bit dibobol dalam sekitar 72 jam dengan biaya sekitar $75.

Kunci Ed25519 berukuran kecil (44 karakter p=), dan demi kompatibilitas mundur RFC 8463 mengizinkan penanda tangan menambahkan tanda tangan RSA di sampingnya: dua selector, dua tanda tangan (RFC 8463).

Rotasi dilakukan dengan memublikasikan kunci baru di selector baru, mengalihkan penandatanganan, menyimpan kunci lama 7 sampai 30 hari untuk email yang masih di perjalanan, lalu mengosongkan p=-nya. M3AAWG menyarankan setiap enam bulan. Penyedia seperti Fastmail dan Microsoft 365 melakukannya untuk Anda lewat selector cadangan.

Posisi kunci asli pada skala RFC 8301

GagalValid, rotasi ke 2048BaikBisa gagal di sebagian penerima
  • microsoft.com · selector2
  • github.com · k1
  • google.com · 20251104
  • fastmail.com · fm2
  • archlinux.org · dkim-rsa
  • archlinux.org · dkim-ed25519 (Ed25519)

Rotasi tanpa celah (M3AAWG)

  1. Hari 0Publikasikan kunci baru di selector baru
  2. Hari 1+Alihkan penandatanganan ke sana
  3. +7–30 hariSimpan kunci lama untuk email di perjalanan
  4. LaluKosongkan p= lama; jangan pakai ulang namanya
fastmail.comfm1p= kosongfm22.048fm3p= kosongtiga CNAME, satu terisi: rotasi adalah perubahan DNS di sisi Fastmail
Ukuran kunci dibaca dari DNS pada 25 Oktober 2026, didekode dari tiap p=. RFC 8301 §3.2; M3AAWG DKIM Key Rotation Best Common Practices (2019).

Mengapa DKIM gagal? Hash isi, penerusan, dan milis

DKIM gagal saat byte yang ditandatangani berubah, saat kunci tidak ditemukan, atau saat kunci tidak cocok dengan tanda tangan. Penerusan yang tidak mengubah pesan menjaga DKIM tetap utuh (tidak seperti SPF); milis biasanya merusaknya, karena menambahkan footer atau menandai subjek.

Verifikator di halaman ini mengecek hash isi dan tanda tangan header secara terpisah, jadi ia bisa membedakan footer yang ditambahkan di perjalanan dari pemalsuan.

Hash isi tidak terverifikasi

Sebuah milis menambahkan footer 153 byte. Header-nya masih terverifikasi dengan kunci project.example, jadi ini bukan pemalsuan.

Perbaikan Milis yang menjaga isi tetap utuh, atau ARC (RFC 8617) agar penerima berikutnya melihat hasil aslinya.

body-hash-mismatch

Tanda tangan tidak terverifikasi

Sebuah header yang ditandatangani berubah setelah ditandatangani (milis menambahkan namanya ke Subject), atau selector kini berisi kunci yang berbeda.

Perbaikan Jangan menulis ulang header yang ditandatangani; publikasikan kunci baru di selector baru, bukan menggantinya.

signature-mismatch

Tidak ada kunci untuk tanda tangan

s=2023old._domainkey.shop.example adalah NXDOMAIN: selector dihapus saat email yang ditandatangani dengannya masih di perjalanan.

Perbaikan Biarkan kunci lama terpublikasi 7–30 hari setelah beralih; kosongkan p=, jangan dihapus.

key-not-found

Penerusan: peneruskan yang menyampaikan pesan tanpa perubahan menjaga DKIM tetap valid, itulah mengapa DMARC biasanya tetap lolos saat diteruskan lewat DKIM meski SPF gagal.

DKIM vs SPF vs DMARC

SPF menyebut server mana yang boleh mengirim untuk sebuah domain, DKIM membuktikan sebuah domain menandatangani pesan dan pesan itu tidak berubah, dan DMARC mengikat keduanya ke alamat From: lalu menentukan apa yang dilakukan saat gagal.

Ketiganya menjawab pertanyaan berbeda, jadi Anda butuh ketiganya: Gmail dan Yahoo mewajibkan SPF dan DKIM dari pengirim massal, plus record DMARC, dan RFC 9989 meminta domain dengan p=reject menandatangani DKIM, bukan mengandalkan SPF.

Tiga record, tiga pertanyaan

Tiga record, tiga pertanyaanSPFDKIMDMARC
Yang dibuktikanServer ini boleh mengirim untuk domain MAIL FROMDomain d= menandatangani; bagian yang ditandatangani tidak berubahFrom: cocok dengan domain yang lolos SPF atau DKIM
LetaknyaTXT di github.comTXT di s1._domainkey.github.comTXT di _dmarc.github.com
github.com hari iniv=spf1 … ~all12 kunci, 6 penyediap=quarantine; sp=reject
Bertahan saat diteruskanTidak: IP peneruskan tidak tercantumYa, jika pesan tiba tanpa diubahYa, lewat pass DKIM yang aligned
Rusak saatlayanan pengirim baru belum ada di recordisi atau header yang ditandatangani berubahkeduanya tidak lolos untuk domain From:

Pemeriksa Rekaman SPFCek DMARC

Record github.com seperti dibaca pada 25 Oktober 2026.

Cara membaca header DKIM-Signature di sebuah email

Buka pesan asli dan temukan header DKIM-Signature: d= adalah penanda tangan, s= kunci mana, h= mendaftar header yang ditandatangani, dan bh= serta b= adalah dua hash yang dicek penerima.

Putusan penerima ada di header terpisah yang ditambahkan saat tiba: Authentication-Results: … dkim=pass header.d=example.com header.s=dnsrobot-sample. Halaman Show original Gmail (dalam bahasa Inggris) meringkasnya sebagai “DKIM: 'PASS' with domain example.com”.

Sebuah pesan bisa membawa beberapa tanda tangan, satu per penanda tangan (domain Anda dan layanan email Anda, atau milis). Satu tanda tangan yang lolos dengan d= yang aligned sudah cukup untuk DMARC.

Tanda tangan email contoh, tag demi tag

v=11; a=rsa-sha2562; c=relaxed/relaxed3; d=example.com4; s=dnsrobot-sample5; t=17928331206; h=from:from:to:subject:date:message-id:mim…7; bh=fohb/a+auh1W9c…8; b=fF0aMr3Uo+mbgG…9

  1. 1Versi v=selalu 1
  2. 2Algoritma a=rsa-sha256 (atau ed25519-sha256)
  3. 3Kanonikalisasi c=relaxed mentolerir pelipatan ulang
  4. 4Domain penanda tangan d=dibandingkan dengan From: untuk DMARC
  5. 5Selector s=kunci di s._domainkey.d
  6. 6Waktu tanda tangan t=Waktu Unix: 24 Okt 2026, 09.12
  7. 7Header yang ditandatangani h=from dua kali = oversigned
  8. 8Hash isi bh=SHA-256 dari isi kanonik
  9. 9Tanda tangan b=atas header h= dan field ini

Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=dnsrobot-sample

Email contoh buatan yang dimuat halaman ini (example.com, kunci yang dibuat untuknya), diverifikasi oleh engine.

Cek DKIM: pertanyaan yang sering diajukan

Apa itu record DKIM?

Record DKIM adalah record TXT yang memublikasikan kunci publik sebuah domain di selector._domainkey.domain, seperti google._domainkey.example.com. Isinya pasangan tag=value: p= adalah kunci base64 dan wajib, k= jenis kunci, t= flag. Penerima mengambilnya untuk mengecek DKIM-Signature pada email masuk. Sebuah domain boleh memublikasikan banyak, biasanya satu per layanan pengirim.

Bagaimana menemukan selector DKIM saya?

Buka email apa pun yang dikirim domain itu, lihat pesan aslinya, dan temukan header DKIM-Signature: nilai setelah s= adalah selector, dan d= adalah domainnya. Di Gmail gunakan Lainnya (⋮) › Tampilkan versi asli; di Outlook di web, View › View message source. Atau tempel email ke Verifikasi email di atas, yang membaca s= dan d= untuk Anda.

Mengapa pemeriksa tidak menemukan kunci padahal email saya ditandatangani?

Karena DNS tidak bisa mendaftarkan selector: kunci hanya ditemukan dengan menanyakan nama persisnya. Pemeriksa menanyakan 140 nama yang dipakai penyedia; jika Anda menandatangani dengan nama lain (Amazon SES dan Postmark membuat satu per akun), penyisiran tidak bisa melihatnya. Tambahkan selector dari s= sebuah email dan ia dicek lebih dulu, atau verifikasi email.

Apakah kunci DKIM 1024 bit masih aman dipakai?

Masih berfungsi: RFC 8301 mewajibkan verifikator menerima kunci RSA 1024 sampai 4096 bit, dan Gmail serta Yahoo menetapkan 1024 bit sebagai batas minimum. Tetapi RFC 8301 meminta penanda tangan memakai minimal 2048 bit, dan M3AAWG menyebut 1024 di ambang serangan. Rencanakan rotasi: Microsoft 365 dan Google Workspace sama-sama menawarkan kunci 2048 bit. RFC 8301 meminta verifikator menolak kunci di bawah 1024 bit.

Apa arti p= kosong?

p= kosong berarti kunci dicabut: tanda tangan dengan selector itu gagal, persis seperti kuncinya tidak ada. Biasanya itu disengaja. Google menyimpan selector lamanya yang bertanggal dengan cara ini, dan Fastmail serta Microsoft 365 menyimpan selector cadangan kosong untuk dirotasi. Itu hanya masalah jika itu selector yang dipakai email Anda hari ini.

Apa arti t=y di record DKIM?

t=y menandai kunci sedang diuji: penerima sebaiknya memperlakukan email yang ditandatangani dengannya seperti email tanpa tanda tangan, bahkan saat tanda tangannya terverifikasi. Ini untuk pengaturan awal dan sering terlupa. t=s berbeda: artinya strict, jadi i= di tanda tangan harus persis domain penanda tangan, bukan subdomain. Sebagian layanan email memasang t=s pada kunci mereka; kunci SendGrid untuk github.com memakainya.

Mengapa DKIM gagal dengan “body hash did not verify”?

Isi yang di-hash penerima tidak cocok dengan nilai bh= di tanda tangan, jadi isi berubah setelah ditandatangani. Milis yang menambah footer, gateway keamanan yang menulis ulang tautan, dan disclaimer yang ditambahkan server semuanya bisa menyebabkannya. Jika tanda tangan header masih terverifikasi, pesannya asli tetapi dimodifikasi; verifikator halaman ini mengecek keduanya terpisah.

Apakah DKIM tetap bertahan saat email diteruskan?

Biasanya, ya. Peneruskan yang menyampaikan pesan tanpa perubahan menjaga tanda tangan tetap valid, karena DKIM menandatangani isi, bukan jalurnya. Itulah bedanya dengan SPF, yang gagal di alamat IP peneruskan. Peneruskan yang mengubah pesan, seperti milis yang menambah footer atau tag subjek, merusak DKIM; ARC memungkinkan mereka menjamin hasil aslinya.

Apakah saya butuh DKIM jika sudah punya SPF?

Ya. SPF rusak saat email diteruskan dan hanya mencakup alamat MAIL FROM yang tersembunyi, sedangkan DKIM bertahan saat diteruskan dan bisa aligned dengan domain From: yang dicek DMARC. Gmail dan Yahoo mewajibkan keduanya dari pengirim massal, Outlook.com sejak Mei 2025, dan RFC 9989 meminta domain dengan p=reject menandatangani emailnya dengan DKIM.

Seberapa sering kunci DKIM harus dirotasi?

M3AAWG menyarankan minimal setiap enam bulan. Publikasikan kunci baru di selector baru, alihkan penandatanganan ke sana, biarkan kunci lama terpublikasi 7 sampai 30 hari agar email di perjalanan tetap terverifikasi, lalu kosongkan p=-nya, jangan dihapus. Jangan pernah memakai ulang nama selector. Penyedia hosting dengan selector CNAME merotasi kunci untuk Anda.

Apakah email saya diunggah saat saya memverifikasinya di sini?

Tidak. Validator DKIM ini mengecek email di browser Anda: DNS publik hanya ditanya nama kunci (s._domainkey.d), dan dnsrobot.net hanya ditanya kebijakan DMARC domain From dan domain penanda tangan. Satu-satunya pengecualian adalah tanda tangan Ed25519 yang tidak bisa dicek browser: halaman lalu bertanya dulu sebelum mengirim email sekali ke server kami, yang mengeceknya di memori dan tidak menyimpan apa pun.

Bisakah saya memakai kunci DKIM Ed25519?

Bisa. RFC 8463 mendefinisikannya dan mewajibkan verifikator mendukungnya. Demi kompatibilitas mundur, publikasikan di selector sendiri di samping kunci RSA dan tandatangani setiap pesan dua kali, seperti yang dilakukan archlinux.org dengan dkim-ed25519 dan dkim-rsa: penerima yang tidak bisa memverifikasi Ed25519 tetap punya tanda tangan RSA. Microsoft 365 dan Google Workspace hanya menawarkan kunci RSA.

Ada yang kurang?Usulkan fitur atau alat baru

Alat email dan DNS terkait