Protokol SMTP (Simple Mail Transfer Protocol) yang mengantarkan email dari server pengirim ke server penerima dirancang pada awal 1980-an, saat internet masih berupa jaringan tertutup antar-institusi yang saling percaya. Kolom pengirim pada header email bisa diisi bebas oleh siapa saja yang terhubung ke server SMTP, tanpa mekanisme bawaan yang memverifikasi apakah pengirim benar-benar berhak memakai alamat tersebut.

Celah itulah yang lantas dimanfaatkan pelaku pemalsuan email untuk mengirim pesan seolah-olah berasal dari domain resmi sebuah perusahaan atau bank. DKIM adalah salah satu jawaban atas masalah tersebut: mekanisme yang membubuhkan tanda tangan digital pada setiap pesan keluar, sehingga server penerima bisa memastikan pesan benar berasal dari domain yang mengaku mengirimnya dan isinya tidak diubah di tengah jalan.

Artikel ini membedah isi header tanda tangan DKIM tag demi tag, menjelaskan kenapa selector-nya tidak bisa ditebak sembarangan, dan menunjukkan data nyata soal panjang kunci yang masih dipakai sejumlah penyedia layanan email besar hari ini.

Apa Itu DKIM?

DKIM adalah singkatan dari DomainKeys Identified Mail, sebuah standar otentikasi email yang membubuhkan tanda tangan digital pada header setiap pesan keluar. Tanda tangan ini dibuat memakai kunci privat yang hanya dimiliki server pengirim, lalu diverifikasi oleh siapa pun yang punya kunci publik pasangannya. Kunci publik itu sendiri dipublikasikan lewat catatan DNS (Domain Name System) milik domain pengirim, sehingga siapa pun bisa mengambilnya tanpa perlu pertukaran kunci manual.

Fungsi DKIM sebenarnya ada dua, dan keduanya sering tertukar. Pertama, ia membuktikan integritas pesan: kalau ada satu karakter saja yang berubah antara saat dikirim dan diterima, tanda tangannya otomatis tidak valid. Kedua, ia membuktikan otorisasi: domain yang tercantum di tanda tangan memang mengizinkan pesan tersebut dikirim atas namanya. DKIM tidak memeriksa domain yang tertulis di kolom From yang tampil ke pembaca — tugas itu baru masuk saat DKIM disandingkan dengan DMARC, yang dibahas di bagian berikutnya.

Standar ini lahir dari penggabungan dua pendekatan yang berkembang terpisah pada pertengahan 2000-an: DomainKeys milik Yahoo dan Identified Internet Mail milik Cisco. Keduanya disatukan menjadi satu spesifikasi dan diterbitkan sebagai RFC 4871 pada 2007, lalu diperbarui menjadi RFC 6376 pada 2011 sebagai standar yang berlaku hingga sekarang.

Cara Kerja DKIM: Dari Penandatanganan Sampai Verifikasi

Proses DKIM berjalan dalam dua sisi yang terpisah waktu dan tempat. Di sisi pengirim, server mail (atau MTA, Mail Transfer Agent) menghitung nilai hash dari isi pesan dan sebagian header terpilih, lalu mengenkripsi hash tersebut memakai kunci privat. Hasil enkripsi itulah yang menjadi tanda tangan digital, ditempelkan sebagai header baru bernama DKIM-Signature sebelum pesan dikirim lewat SMTP seperti biasa.

Di sisi penerima, prosesnya dibalik. Server penerima membaca header DKIM-Signature, mengambil nama domain dan nama selector yang tertulis di sana, lalu melakukan pencarian DNS untuk mengambil kunci publik yang sepasang. Kunci publik itu dipakai mendekripsi tanda tangan, hasilnya dibandingkan dengan hash yang dihitung ulang dari pesan yang baru saja diterima. Kalau keduanya cocok, DKIM dinyatakan lolos.

Cara kerja DKIM: pengirim menandatangani pesan dengan kunci privat, penerima mengambil kunci publik lewat DNS lalu memverifikasi tanda tangan.Cara kerja DKIM: pengirim menandatangani pesan dengan kunci privat, penerima mengambil kunci publik lewat DNS lalu memverifikasi tanda tangan.

Perlu diperhatikan, DKIM tidak mengubah cara pesan dikirim maupun diantar. Ia hanya menambahkan satu header dan satu catatan DNS tambahan — seluruh infrastruktur SMTP yang sudah ada tetap bekerja seperti biasa.

Membedah Header DKIM-Signature Tag demi Tag

Header DKIM-Signature bukan sekadar untaian karakter acak. Ia tersusun dari pasangan tag dan nilai yang masing-masing punya arti spesifik. Contoh sederhananya:

Code
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tokoanda.com;
 s=mail2024; t=1755321600; h=from:to:subject:date;
 bh=9jZ9x2VqK...=; b=Q3Fj8pR...==

Berikut arti tiap tag yang paling sering muncul:

  1. v=: Versi spesifikasi DKIM yang dipakai. Sampai saat ini nilainya selalu 1.
  2. a=: Algoritma tanda tangan. Standar saat ini adalah rsa-sha256; algoritma lama rsa-sha1 sudah tidak boleh dipakai lagi karena SHA-1 dianggap rentan.
  3. c=: Metode canonicalization, aturan menormalkan pesan sebelum dihitung hash-nya — sumber kegagalan verifikasi paling umum, dijelaskan di bawah.
  4. d=: Domain yang menandatangani pesan, dipakai server penerima untuk mencari kunci publik.
  5. s=: Selector, nama unik yang membedakan satu kunci DKIM dari kunci lain milik domain yang sama.
  6. t=: Waktu pesan ditandatangani, dalam format Unix timestamp.
  7. h=: Daftar header yang ikut dihitung dalam tanda tangan, dipisah titik dua. Header yang tidak disebut di sini bebas diubah tanpa membatalkan tanda tangan.
  8. bh=: Hash dari isi pesan (body hash), dalam format base64.
  9. b=: Tanda tangan digital itu sendiri, hasil enkripsi hash memakai kunci privat, juga dalam format base64.

Tag c= sering luput dari penjelasan, padahal ini alasan paling umum kenapa DKIM tiba-tiba gagal padahal tidak ada yang sengaja diubah. Nilainya terdiri dari dua bagian dipisah garis miring: canonicalization header dan body. Mode simple bersifat ketat — perubahan spasi atau baris baru sekecil apa pun langsung membatalkan tanda tangan. Mode relaxed lebih toleran, mengizinkan variasi spasi dan line-folding yang lazim terjadi saat pesan melewati beberapa server relay atau ditambahi footer oleh mailing list. Kombinasi yang paling umum dipakai penyedia email modern adalah relaxed/relaxed atau relaxed/simple, karena simple/simple gampang gagal hanya gara-gara pesan diteruskan lewat perangkat perantara yang menormalkan whitespace.

Kenapa Selector DKIM Tidak Bisa Ditebak

Nilai selector pada tag s= menentukan di mana kunci publik dicari, dengan format lokasi DNS <selector>._domainkey.<domain>. Selector inilah yang membuat sebuah domain bisa punya beberapa kunci DKIM sekaligus — misalnya satu untuk email transaksional dan satu lagi untuk newsletter dari penyedia pihak ketiga — tanpa saling bertabrakan.

Konsep ini yang sering luput dipahami: DKIM tidak punya alamat tetap seperti SPF (selalu di root TXT record domain) atau DMARC (selalu di _dmarc.namadomain.com). Nama selector-nya bebas ditentukan siapa pun yang memasang DKIM, sehingga tidak ada satu lokasi baku yang bisa langsung dituju.

Untuk membuktikannya, kami mencoba mencari catatan DKIM pada sekitar 500 kombinasi domain dan selector: belasan domain besar Indonesia lintas sektor perbankan, e-commerce, pemerintahan, media, telekomunikasi, dan pendidikan, dipasangkan dengan belasan nama selector yang paling umum dipakai berbagai platform (seperti google, selector1, selector2, k1, s1, default), ditambah domain sejumlah penyedia layanan pengiriman email global di bawah nama selector khas platform masing-masing. Hasilnya nihil di seluruh kombinasi tersebut, termasuk pada domain milik penyedia layanan email itu sendiri.

Supaya yakin metode pencariannya benar dan bukan resolver yang bermasalah, kami mengulangi pencarian yang sama pada domain infrastruktur pengiriman aktual dari penyedia yang sama — bukan domain pemasarannya — dan ketiganya langsung ditemukan tanpa masalah: s1._domainkey.sendgrid.net, k1._domainkey.mailchimpapp.net, dan mandrill._domainkey.mandrillapp.com. Artinya, nihilnya pencarian pada domain besar Indonesia bukan berarti domain-domain itu tidak memakai DKIM — kemungkinan besar mereka memakai selector kustom di luar daftar yang kami coba. Justru itulah intinya: selector bukan sesuatu yang bisa ditebak dari nama domain, sekalipun untuk domain yang sudah pasti mengirim volume email tinggi. Satu-satunya cara mendapatkan nilai selector yang benar adalah membuka header pesan yang benar-benar diterima dari domain tersebut, lalu membaca tag s= pada header DKIM-Signature-nya — caranya dijelaskan di bagian "Cara Memeriksa DKIM Sudah Aktif".

DKIM, SPF, dan DMARC: Tiga Lapis yang Saling Melengkapi

Ketiga istilah ini sering disebut berbarengan karena memang saling melengkapi, bukan saling menggantikan.

  1. SPF (Sender Policy Framework): mendaftar server mana saja yang berhak mengirim email atas nama sebuah domain, dipublikasikan di root TXT record domain tersebut.
  2. DKIM: membuktikan integritas pesan dan otorisasi domain penandatangan lewat tanda tangan digital, seperti dijelaskan di bagian-bagian sebelumnya.
  3. DMARC: menumpang hasil SPF dan DKIM, menuntut keselarasan domain dengan kolom From yang tampil ke pembaca, lalu memberi instruksi tegas kepada penerima soal apa yang harus dilakukan bila pemeriksaan gagal. Penjelasan lengkap soal DMARC, termasuk cara membaca laporan agregat yang dikirimkannya, sudah kami bahas di artikel DMARC adalah.

DKIM sendirian tidak cukup mencegah pemalsuan pengirim, karena DKIM tidak memaksa domain penandatangan pada tag d= sama dengan domain yang tertulis di kolom From. Sebuah pesan bisa saja lolos DKIM dengan domain yang sah milik penyedia layanan lain, sementara kolom From-nya dipalsukan meniru domain perusahaan Anda — pola yang jamak dipakai pelaku email spoofing. DMARC-lah yang menutup celah ini lewat pemeriksaan keselarasan atau alignment.

Tiga lapis otentikasi email: SPF memeriksa server pengirim, DKIM memeriksa tanda tangan pesan, DMARC menyelaraskan keduanya dengan header From.Tiga lapis otentikasi email: SPF memeriksa server pengirim, DKIM memeriksa tanda tangan pesan, DMARC menyelaraskan keduanya dengan header From.

Keterbatasan DKIM

  1. Tidak mengenkripsi isi pesan: DKIM hanya menandatangani, bukan menyembunyikan konten. Pesan tetap bisa dibaca siapa saja yang menyadap lalu lintas SMTP tanpa TLS di tengah jalan.
  2. Rentan replay attack: karena tanda tangan hanya membuktikan pesan tidak diubah — bukan membuktikan pesan hanya boleh dikirim sekali — pesan yang sudah sah tetap lolos verifikasi walau dikirim ulang berkali-kali ke penerima lain oleh pihak yang tidak berwenang.
  3. Tidak menjamin kolom From yang tampil ke pembaca: seperti dijelaskan di bagian sebelumnya, DKIM bisa lolos dengan domain penandatangan yang berbeda dari alamat yang terlihat penerima. Perlindungan penuh baru didapat setelah DMARC dipasang dan diarahkan ke kebijakan yang tegas.
  4. Panjang kunci lama masih beredar: RFC 8301 merekomendasikan panjang kunci RSA minimal 2048-bit untuk DKIM sejak 2018, dan melarang kunci di bawah 1024-bit sama sekali. Namun saat kami mengecek langsung tiga catatan DKIM milik infrastruktur pengiriman email besar dunia, hasilnya beragam: kunci s1._domainkey.sendgrid.net sudah memakai 2048-bit, sementara k1._domainkey.mailchimpapp.net dan mandrill._domainkey.mandrillapp.com masih memakai 1024-bit. Rekomendasi itu sudah berjalan lebih dari lima tahun, tapi belum sepenuhnya jadi praktik baku bahkan di kalangan penyedia layanan besar — kalau Anda pernah melihat peringatan "DKIM public key size is less than 2048 bits" di Microsoft 365, itulah yang sedang ditegur.

Cara Memasang DKIM

Memasang DKIM selalu melalui tiga langkah yang sama, apa pun platform email yang dipakai: membuat pasangan kunci privat-publik, menerbitkan kunci publik sebagai TXT record di DNS dengan selector tertentu, lalu mengaktifkan penandatanganan di sisi server pengirim. Berikut langkahnya di tiga platform yang paling sering dicari.

Memasang DKIM di Google Workspace

Buka Admin console, masuk ke menu Apps > Google Workspace > Gmail > Authenticate email. Pilih domain yang ingin diaktifkan, lalu klik Generate new record. Pilih panjang kunci 2048-bit, dan Google akan menampilkan nama host (biasanya berformat google._domainkey) beserta nilai TXT yang harus ditambahkan. Setelah record itu dipasang di DNS dan sudah ter-propagasi, kembali ke Admin console dan klik Start authentication untuk mengaktifkan penandatanganan.

Memasang DKIM di Microsoft 365

Lewat Microsoft Defender portal, masuk ke Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Pilih domain yang dituju, dan Microsoft akan menampilkan dua record CNAME (biasanya dengan selector selector1 dan selector2) yang mengarah ke subdomain onmicrosoft.com milik organisasi Anda. Setelah kedua CNAME itu ditambahkan ke DNS, tombol Enable di halaman yang sama akan aktif dan bisa ditekan.

Memasang DKIM di cPanel

Kalau domain Anda memakai layanan hosting berbasis cPanel, DKIM biasanya sudah dibuatkan otomatis lewat menu Email Deliverability begitu domain ditambahkan. Buka menu tersebut, pilih domain yang ingin diperiksa, dan cPanel akan menampilkan status DKIM beserta SPF-nya. Kalau statusnya belum "Valid Configuration", klik Manage lalu Install the suggested record untuk menerbitkan record yang direkomendasikan langsung ke zona DNS domain. Kalau domain Anda memakai layanan email hosting Indowebsite, langkah ini biasanya sudah tersedia lewat cPanel tanpa perlu konfigurasi manual tambahan. Panduan langkah demi langkah dengan tangkapan layar tersedia di tutorial memasang DKIM dan SPF di cPanel.

Setelah DKIM aktif, sebagian besar penyedia menyarankan rotasi kunci secara berkala, misalnya setiap 6 sampai 12 bulan. Caranya cukup menerbitkan kunci baru dengan nama selector baru berdampingan dengan yang lama, menunggu beberapa hari sampai semua sistem pengirim beralih memakainya, baru kemudian mencabut selector lama dari DNS. Rotasi ini membatasi dampak kalau suatu saat kunci privat pernah bocor tanpa disadari.

Cara Memeriksa DKIM Sudah Aktif

Cara paling pasti memeriksa DKIM adalah membaca header lengkap dari email yang benar-benar diterima, bukan menebak dari nama domain. Di Gmail, buka email yang dicurigai, klik ikon titik tiga di pojok kanan atas pesan, lalu pilih Tampilkan asli (Show original). Cari header DKIM-Signature, lalu catat nilai tag s= (selector) dan d= (domain).

Setelah kedua nilai itu didapat, jalankan pencarian DNS memakai selector dan domain yang sebenarnya:

Bash
dig +short TXT mail2024._domainkey.tokoanda.com

Kalau perintah di atas mengembalikan teks yang diawali v=DKIM1; k=rsa; p=..., kunci publiknya memang diterbitkan dan bisa dibaca server penerima. Kalau hasilnya kosong, DKIM belum aktif untuk selector dan domain tersebut, atau ada kesalahan penulisan pada record DNS-nya. Sebagai alternatif tanpa command line, layanan seperti MXToolbox punya alat pengecek DKIM yang menerima selector dan domain lalu menampilkan hasil serupa lewat antarmuka web.

Arti Kode Hasil Verifikasi DKIM

Server penerima biasanya mencatat hasil verifikasi DKIM di header Authentication-Results. Berikut arti tiap kode yang mungkin muncul:

  1. pass: tanda tangan valid dan cocok dengan kunci publik yang diterbitkan. Ini hasil yang diharapkan.
  2. fail: tanda tangan ada, tetapi tidak valid. Penyebab paling umum adalah isi pesan berubah setelah ditandatangani — misalnya mailing list yang menyisipkan footer, atau kunci di DNS sudah diganti tapi pesan lama masih memakai kunci lama.
  3. neutral: header DKIM-Signature ada, tetapi domain tidak menerbitkan kebijakan yang bisa dievaluasi lebih lanjut, atau tag di dalamnya tidak lengkap.
  4. policy: tanda tangan valid secara teknis, tetapi tidak memenuhi kebijakan tambahan yang ditetapkan penerima, misalnya pembatasan algoritma tertentu.
  5. permerror: kegagalan permanen. Biasanya berarti record DNS-nya tidak ditemukan sama sekali — selector salah ketik, atau TXT record belum sempat dipasang atau di-propagasi.
  6. temperror: kegagalan sementara, umumnya karena DNS lookup timeout. Verifikasi bisa dicoba ulang nanti dan biasanya berhasil dengan sendirinya.
  7. none: pesan sama sekali tidak memiliki header DKIM-Signature, artinya domain pengirim belum mengaktifkan DKIM.

FAQ

Apa itu DKIM dalam konteks mail server? Di sisi mail server, DKIM adalah modul tambahan pada MTA yang menandatangani setiap pesan keluar secara otomatis dan memverifikasi tanda tangan pada setiap pesan masuk, tanpa campur tangan manual.

Apa itu SPF, DKIM, dan DMARC? Tiga mekanisme otentikasi email yang saling melengkapi: SPF memeriksa server pengirim, DKIM memeriksa keutuhan pesan lewat tanda tangan digital, dan DMARC menyelaraskan hasil keduanya dengan alamat yang tampil ke pembaca.

Apa itu catatan DNS DKIM? TXT record berisi kunci publik, diterbitkan di lokasi <selector>._domainkey.<domain>. Server penerima mengambilnya untuk memverifikasi tanda tangan digital pada pesan yang diterima.

Kesimpulan

DKIM adalah lapisan otentikasi email yang membubuhkan tanda tangan digital pada setiap pesan keluar, membuktikan pesan tidak diubah dan benar berasal dari domain yang mengaku mengirimnya. Kunci publiknya diterbitkan di DNS pada lokasi yang ditentukan selector — bukan alamat tetap seperti SPF atau DMARC, sehingga selector yang benar hanya bisa didapat dari header email asli.

DKIM sebaiknya tidak berdiri sendiri. Disandingkan dengan SPF dan DMARC, ketiganya menutup celah yang tidak bisa diselesaikan satu per satu: SPF menjaga server pengirim, DKIM menjaga keutuhan pesan, dan DMARC menyelaraskan keduanya dengan apa yang benar-benar dilihat penerima. Untuk kunci yang baru dibuat, pastikan panjangnya minimal 2048-bit sesuai RFC 8301 — bukan sekadar standar minimum, karena seperti ditunjukkan pengecekan di atas, sejumlah infrastruktur pengiriman email besar pun masih ada yang belum ke sana.

Semoga artikel ini membantu.