Validasi DKIM: Praktik Terbaik Autentikasi Email
Burung
8 Apr 2017
1 min read
Poin Penting
DKIM (DomainKeys Identified Mail) adalah metode autentikasi email berbasis konten yang memverifikasi apakah pesan telah diubah setelah ditandatangani.
Berbeda dengan SPF, yang memvalidasi jalur pengiriman, DKIM memvalidasi konten pesan itu sendiri menggunakan tanda tangan kriptografi.
DKIM menggunakan dua kunci: kunci pribadi untuk menandatangani pesan keluar dan kunci publik yang dipublikasikan di DNS untuk penerima memvalidasi tanda tangan.
Tanda tangan DKIM mencakup hash dari header dan badan, pemilih, cap waktu, dan bidang identitas — semua yang harus direproduksi dan diverifikasi oleh penerima.
Validasi DKIM bergantung pada penerimaan seluruh pesan terlebih dahulu, yang berarti kegagalan dapat terjadi di kemudian hari dalam proses.
Memecahkan masalah validasi DKIM yang gagal seringkali sulit karena pengirim dan penerima tidak dapat mereproduksi lingkungan penandatanganan/verifikasi satu sama lain.
Bahkan ketika DKIM gagal, biasanya tidak langsung menyebabkan masalah kotak masuk dengan sendirinya kecuali dikombinasikan dengan sinyal reputasi negatif lainnya.
Sorotan Tanya jawab
Apa sebenarnya yang dilakukan DKIM?
DKIM melampirkan tanda tangan kriptografi pada email, memungkinkan server penerima untuk mengonfirmasi apakah konten pesan telah dimodifikasi setelah dikirim.
Apa perbedaan DKIM dan SPF?
SPF memvalidasi siapa yang diizinkan untuk mengirim email untuk sebuah domain (berbasis jalur).
DKIM memvalidasi apakah konten tetap utuh (berbasis konten).
Keduanya memiliki tujuan yang berbeda dan saling melengkapi.
Apa yang ada di dalam header DKIM-Signature?
Bidang kunci meliputi:
v= versi
a= algoritma
c= aturan kanonisasi
d= domain penandatanganan
s= pemilih
h= header yang disertakan dalam tanda tangan
bh= hash tubuh
b= data tanda tangan yang sebenarnya
Setiap bagian berkontribusi pada bagaimana tanda tangan divalidasi.
Bagaimana server penerima memvalidasi DKIM?
Menarik nilai d= dan s=.
Mencari kunci publik di:
selector._domainkey.domain
Regenerasi header dan body hash.
membandingkan mereka dengan nilai bh= dan b= di email.
Jika cocok, pesan lolos DKIM.
Apa yang menyebabkan DKIM gagal?
Pesan diubah dalam perjalanan (bahkan perubahan spasi jika menggunakan kanonikasi ketat)
Kunci publik yang salah atau hilang di DNS
Kesalahan format DNS
Pemilih dihapus atau diputar dengan salah
Identitas yang tidak cocok (i= harus sama dengan domain atau subdomain dari d=)
Mengapa kegagalan DKIM bisa sulit untuk dipecahkan?
Sebab penandatangan dan validator beroperasi di lingkungan yang sama sekali berbeda — tidak ada pihak yang dapat membangun kembali kondisi hashing atau status tanda tangan pihak lainnya.
Ini membuat kegagalan "hash mismatch" yang tidak jelas menjadi yang paling frustrasi untuk didiagnosis.
Apakah kegagalan DKIM berarti email akan masuk ke folder spam?
Tidak selalu.
DKIM hanyalah salah satu sinyal. Jika domain memiliki reputasi yang kuat dan melewati pemeriksaan lainnya (penyelarasan SPF, DMARC, tingkat keluhan yang rendah), kegagalan DKIM yang terisolasi biasanya tidak mempengaruhi pengiriman ke kotak masuk dengan sendirinya.
Mengapa menggunakan DKIM sama sekali?
Melindungi integritas pesan
Membangun reputasi domain
Memungkinkan penyelarasan DMARC
Memungkinkan penyedia kotak surat membedakan pengirim yang sah dari penipu
DKIM dianggap sebagai praktik terbaik bagi semua pengirim email yang serius.
Ketika kita berbicara tentang “Autentikasi Email”, kita merujuk pada teknik yang memberikan kepada penerima pesan tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber yang diklaim. Ide di balik teknik-teknik tersebut adalah untuk mencapai tingkat pertahanan terhadap email palsu, seperti phishing dan spoofing, email yang dapat mengikis kepercayaan penerima dalam menerima email. Meskipun demikian, tindakan mengirim email yang terautentikasi tidak menyatakan bahwa email tersebut baik atau diinginkan; itu hanya berarti bahwa email tersebut sedemikian rupa sehingga reputasi untuk pihak yang terautentikasi dapat diperoleh secara andal dan digunakan dalam keputusan penerimaan dan penempatan email.
Ada dua bentuk autentikasi email yang digunakan saat ini:
Kerangka Kebijakan Pengirim (SPF)
Kunci Domain Identifikasi Email (DKIM)
Dalam pos hari ini, saya akan membahas apa itu DKIM dan bagaimana cara kerjanya.
Ketika kita berbicara tentang “Autentikasi Email”, kita merujuk pada teknik yang memberikan kepada penerima pesan tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber yang diklaim. Ide di balik teknik-teknik tersebut adalah untuk mencapai tingkat pertahanan terhadap email palsu, seperti phishing dan spoofing, email yang dapat mengikis kepercayaan penerima dalam menerima email. Meskipun demikian, tindakan mengirim email yang terautentikasi tidak menyatakan bahwa email tersebut baik atau diinginkan; itu hanya berarti bahwa email tersebut sedemikian rupa sehingga reputasi untuk pihak yang terautentikasi dapat diperoleh secara andal dan digunakan dalam keputusan penerimaan dan penempatan email.
Ada dua bentuk autentikasi email yang digunakan saat ini:
Kerangka Kebijakan Pengirim (SPF)
Kunci Domain Identifikasi Email (DKIM)
Dalam pos hari ini, saya akan membahas apa itu DKIM dan bagaimana cara kerjanya.
Ketika kita berbicara tentang “Autentikasi Email”, kita merujuk pada teknik yang memberikan kepada penerima pesan tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber yang diklaim. Ide di balik teknik-teknik tersebut adalah untuk mencapai tingkat pertahanan terhadap email palsu, seperti phishing dan spoofing, email yang dapat mengikis kepercayaan penerima dalam menerima email. Meskipun demikian, tindakan mengirim email yang terautentikasi tidak menyatakan bahwa email tersebut baik atau diinginkan; itu hanya berarti bahwa email tersebut sedemikian rupa sehingga reputasi untuk pihak yang terautentikasi dapat diperoleh secara andal dan digunakan dalam keputusan penerimaan dan penempatan email.
Ada dua bentuk autentikasi email yang digunakan saat ini:
Kerangka Kebijakan Pengirim (SPF)
Kunci Domain Identifikasi Email (DKIM)
Dalam pos hari ini, saya akan membahas apa itu DKIM dan bagaimana cara kerjanya.
Tinjauan DKIM
Berbeda dengan rekan autentikasinya SPF, yang memberikan cara bagi domain untuk mengizinkan host mengirim email atas namanya, DKIM memberikan cara bagi entitas (domain, organisasi, orang, dll.) untuk mengambil tanggung jawab untuk sebuah pesan, terlepas dari entitas yang sebenarnya mengirim pesan tersebut. Meskipun dalam banyak kasus entitas yang bertanggung jawab dan entitas pengirim akan sama, atau setidaknya sangat terkait, dengan DKIM tidak ada persyaratan agar ini begitu.
Tujuan saya untuk Anda dengan posting ini adalah agar Anda belajar dan memahami konsep-konsep berikut tentang DKIM:
DKIM adalah autentikasi yang “berbasis konten”, tidak seperti SPF yang “berbasis jalur”.
Entitas yang bertanggung jawab menyatakan tanggung jawabnya dengan “menandatangani” pesan menggunakan sepasang hash kriptografi yang dimasukkan dalam header pesan.
Validasi DKIM dilakukan oleh domain penerima yang mencoba menghasilkan dua hash yang sama.
Validasi DKIM tidak dapat diselesaikan dalam banyak kasus sampai pesan penuh telah ditransmisikan oleh server pengirim.
Kegagalan validasi bisa sulit untuk dipecahkan.
Berbeda dengan rekan autentikasinya SPF, yang memberikan cara bagi domain untuk mengizinkan host mengirim email atas namanya, DKIM memberikan cara bagi entitas (domain, organisasi, orang, dll.) untuk mengambil tanggung jawab untuk sebuah pesan, terlepas dari entitas yang sebenarnya mengirim pesan tersebut. Meskipun dalam banyak kasus entitas yang bertanggung jawab dan entitas pengirim akan sama, atau setidaknya sangat terkait, dengan DKIM tidak ada persyaratan agar ini begitu.
Tujuan saya untuk Anda dengan posting ini adalah agar Anda belajar dan memahami konsep-konsep berikut tentang DKIM:
DKIM adalah autentikasi yang “berbasis konten”, tidak seperti SPF yang “berbasis jalur”.
Entitas yang bertanggung jawab menyatakan tanggung jawabnya dengan “menandatangani” pesan menggunakan sepasang hash kriptografi yang dimasukkan dalam header pesan.
Validasi DKIM dilakukan oleh domain penerima yang mencoba menghasilkan dua hash yang sama.
Validasi DKIM tidak dapat diselesaikan dalam banyak kasus sampai pesan penuh telah ditransmisikan oleh server pengirim.
Kegagalan validasi bisa sulit untuk dipecahkan.
Berbeda dengan rekan autentikasinya SPF, yang memberikan cara bagi domain untuk mengizinkan host mengirim email atas namanya, DKIM memberikan cara bagi entitas (domain, organisasi, orang, dll.) untuk mengambil tanggung jawab untuk sebuah pesan, terlepas dari entitas yang sebenarnya mengirim pesan tersebut. Meskipun dalam banyak kasus entitas yang bertanggung jawab dan entitas pengirim akan sama, atau setidaknya sangat terkait, dengan DKIM tidak ada persyaratan agar ini begitu.
Tujuan saya untuk Anda dengan posting ini adalah agar Anda belajar dan memahami konsep-konsep berikut tentang DKIM:
DKIM adalah autentikasi yang “berbasis konten”, tidak seperti SPF yang “berbasis jalur”.
Entitas yang bertanggung jawab menyatakan tanggung jawabnya dengan “menandatangani” pesan menggunakan sepasang hash kriptografi yang dimasukkan dalam header pesan.
Validasi DKIM dilakukan oleh domain penerima yang mencoba menghasilkan dua hash yang sama.
Validasi DKIM tidak dapat diselesaikan dalam banyak kasus sampai pesan penuh telah ditransmisikan oleh server pengirim.
Kegagalan validasi bisa sulit untuk dipecahkan.
Autentikasi Berbasis Konten
DKIM disebut sebagai autentikasi "berbasis konten", bukan "berbasis jalur", karena apakah sebuah pesan lulus validasi DKIM atau tidak hanya didasarkan pada apakah konten telah berubah antara saat ditandatangani dan saat validasi dicoba.
DKIM disebut sebagai autentikasi "berbasis konten", bukan "berbasis jalur", karena apakah sebuah pesan lulus validasi DKIM atau tidak hanya didasarkan pada apakah konten telah berubah antara saat ditandatangani dan saat validasi dicoba.
DKIM disebut sebagai autentikasi "berbasis konten", bukan "berbasis jalur", karena apakah sebuah pesan lulus validasi DKIM atau tidak hanya didasarkan pada apakah konten telah berubah antara saat ditandatangani dan saat validasi dicoba.
Penandatanganan dan Validasi DKIM
Organisasi yang ingin menandatangani email dengan DKIM akan terlebih dahulu menghasilkan dua kunci kriptografi. Salah satu kunci disimpan secara pribadi dan tersedia untuk server pengirim untuk penandatanganan email, dan yang lainnya akan dipublikasikan di DNS untuk digunakan oleh domain penerima dalam upaya untuk memvalidasi tanda tangan. Metode untuk menghasilkan kunci ini dan menginstalnya bergantung pada platform dan di luar ruang lingkup pos ini, meskipun nanti saya akan menggambarkan penerbitan kunci DKIM publik di DNS.
Organisasi yang ingin menandatangani email dengan DKIM akan terlebih dahulu menghasilkan dua kunci kriptografi. Salah satu kunci disimpan secara pribadi dan tersedia untuk server pengirim untuk penandatanganan email, dan yang lainnya akan dipublikasikan di DNS untuk digunakan oleh domain penerima dalam upaya untuk memvalidasi tanda tangan. Metode untuk menghasilkan kunci ini dan menginstalnya bergantung pada platform dan di luar ruang lingkup pos ini, meskipun nanti saya akan menggambarkan penerbitan kunci DKIM publik di DNS.
Organisasi yang ingin menandatangani email dengan DKIM akan terlebih dahulu menghasilkan dua kunci kriptografi. Salah satu kunci disimpan secara pribadi dan tersedia untuk server pengirim untuk penandatanganan email, dan yang lainnya akan dipublikasikan di DNS untuk digunakan oleh domain penerima dalam upaya untuk memvalidasi tanda tangan. Metode untuk menghasilkan kunci ini dan menginstalnya bergantung pada platform dan di luar ruang lingkup pos ini, meskipun nanti saya akan menggambarkan penerbitan kunci DKIM publik di DNS.
Header DKIM-Signature
Untuk memulai pemahaman kita tentang DKIM, mari kita pertama-tama melihat header DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
Header DKIM-Signature adalah serangkaian pasangan kunci-nilai, beberapa lebih menarik bagi pembaca daripada yang lain, tetapi saya akan menjelaskan semuanya di sini.
Pertama, kita akan melihat bagian yang sebagian besar menarik perhatian pembaca:
v=1; – Menentukan versi DKIM (1 adalah satu-satunya nilai yang valid)
a=rsa-sha256; – Algoritma yang digunakan untuk membangun hash kriptografi
c=relaxed/relaxed; – Ada dua set aturan mengenai penghapusan spasi kosong di header dan body yang dapat diterapkan saat membuat hash dalam tanda tangan DKIM; aturan ini disebut "aturan kanonisasi" (makanya kuncinya adalah c) dan set aturannya adalah "relaxed" atau "strict".
t=1454417737; – Timestamp ketika tanda tangan dibuat.
Tiga bagian header ini berisi informasi tanda tangan yang sebenarnya:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Ini adalah hash dari body pesan.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Ini adalah daftar header yang digunakan untuk membuat data tanda tangan yang ditunjukkan di bawah.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Ini adalah data tanda tangan DKIM yang sebenarnya
Tiga bagian ini paling menarik bagi server penerima yang akan memvalidasi tanda tangan:
d=welcome.foo.com; – Ini mengidentifikasi domain yang menandatangani pesan
s=notices; – Selector; domain dapat memiliki beberapa selector yang mereka gunakan saat menandatangani pesan.
i=@welcome.foo.com; – Ini adalah identitas atas nama siapa pesan tersebut ditandatangani. Secara sintaksis, ini akan terlihat seperti alamat email, dan mungkin bahkan salah satunya; bagian lokal dari alamat email dapat kosong, seperti dalam contoh ini, dan bagian domain harus sama dengan, atau subdomain dari, domain di bagian d= dari tanda tangan.
Alasan bagian-bagian ini menarik bagi server penerima adalah bahwa mereka memberikan informasi yang diperlukan untuk membantu penerima memvalidasi tanda tangan.
Field | Arti | Bagaimana Penerima Menggunakannya |
|---|---|---|
v= | Versi DKIM (selalu 1) | Mengonfirmasi format tanda tangan |
a= | Algoritma hashing + penandatanganan (misalnya, rsa-sha256) | Memastikan validator mereproduksi tanda tangan dengan benar |
c= | Aturan kanonisasi (header/body) | Menormalkan spasi sebelum hashing |
t= | Timestamp pembuatan tanda tangan | Digunakan untuk pemeriksaan kesegaran dan pencegahan pengulangan |
bh= | Body hash | Penerima menghasilkan ini kembali untuk mengonfirmasi integritas body pesan |
h= | Daftar field header yang ditandatangani | Memastikan header yang digunakan dalam penandatanganan tersedia dan tidak dimodifikasi |
b= | Tanda tangan DKIM yang sebenarnya | Penerima memverifikasi tanda tangan ini terhadap kunci publik |
d= | Domain penandatangan | Digunakan untuk menemukan kunci publik DNS penandatangan |
s= | Selector | Digabungkan dengan domain untuk membentuk: selector._domainkey.domain |
i= | Identitas penandatangan | Harus sama atau subdomain dari d=, mengidentifikasi entitas penandatangan |
Untuk memulai pemahaman kita tentang DKIM, mari kita pertama-tama melihat header DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
Header DKIM-Signature adalah serangkaian pasangan kunci-nilai, beberapa lebih menarik bagi pembaca daripada yang lain, tetapi saya akan menjelaskan semuanya di sini.
Pertama, kita akan melihat bagian yang sebagian besar menarik perhatian pembaca:
v=1; – Menentukan versi DKIM (1 adalah satu-satunya nilai yang valid)
a=rsa-sha256; – Algoritma yang digunakan untuk membangun hash kriptografi
c=relaxed/relaxed; – Ada dua set aturan mengenai penghapusan spasi kosong di header dan body yang dapat diterapkan saat membuat hash dalam tanda tangan DKIM; aturan ini disebut "aturan kanonisasi" (makanya kuncinya adalah c) dan set aturannya adalah "relaxed" atau "strict".
t=1454417737; – Timestamp ketika tanda tangan dibuat.
Tiga bagian header ini berisi informasi tanda tangan yang sebenarnya:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Ini adalah hash dari body pesan.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Ini adalah daftar header yang digunakan untuk membuat data tanda tangan yang ditunjukkan di bawah.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Ini adalah data tanda tangan DKIM yang sebenarnya
Tiga bagian ini paling menarik bagi server penerima yang akan memvalidasi tanda tangan:
d=welcome.foo.com; – Ini mengidentifikasi domain yang menandatangani pesan
s=notices; – Selector; domain dapat memiliki beberapa selector yang mereka gunakan saat menandatangani pesan.
i=@welcome.foo.com; – Ini adalah identitas atas nama siapa pesan tersebut ditandatangani. Secara sintaksis, ini akan terlihat seperti alamat email, dan mungkin bahkan salah satunya; bagian lokal dari alamat email dapat kosong, seperti dalam contoh ini, dan bagian domain harus sama dengan, atau subdomain dari, domain di bagian d= dari tanda tangan.
Alasan bagian-bagian ini menarik bagi server penerima adalah bahwa mereka memberikan informasi yang diperlukan untuk membantu penerima memvalidasi tanda tangan.
Field | Arti | Bagaimana Penerima Menggunakannya |
|---|---|---|
v= | Versi DKIM (selalu 1) | Mengonfirmasi format tanda tangan |
a= | Algoritma hashing + penandatanganan (misalnya, rsa-sha256) | Memastikan validator mereproduksi tanda tangan dengan benar |
c= | Aturan kanonisasi (header/body) | Menormalkan spasi sebelum hashing |
t= | Timestamp pembuatan tanda tangan | Digunakan untuk pemeriksaan kesegaran dan pencegahan pengulangan |
bh= | Body hash | Penerima menghasilkan ini kembali untuk mengonfirmasi integritas body pesan |
h= | Daftar field header yang ditandatangani | Memastikan header yang digunakan dalam penandatanganan tersedia dan tidak dimodifikasi |
b= | Tanda tangan DKIM yang sebenarnya | Penerima memverifikasi tanda tangan ini terhadap kunci publik |
d= | Domain penandatangan | Digunakan untuk menemukan kunci publik DNS penandatangan |
s= | Selector | Digabungkan dengan domain untuk membentuk: selector._domainkey.domain |
i= | Identitas penandatangan | Harus sama atau subdomain dari d=, mengidentifikasi entitas penandatangan |
Untuk memulai pemahaman kita tentang DKIM, mari kita pertama-tama melihat header DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
Header DKIM-Signature adalah serangkaian pasangan kunci-nilai, beberapa lebih menarik bagi pembaca daripada yang lain, tetapi saya akan menjelaskan semuanya di sini.
Pertama, kita akan melihat bagian yang sebagian besar menarik perhatian pembaca:
v=1; – Menentukan versi DKIM (1 adalah satu-satunya nilai yang valid)
a=rsa-sha256; – Algoritma yang digunakan untuk membangun hash kriptografi
c=relaxed/relaxed; – Ada dua set aturan mengenai penghapusan spasi kosong di header dan body yang dapat diterapkan saat membuat hash dalam tanda tangan DKIM; aturan ini disebut "aturan kanonisasi" (makanya kuncinya adalah c) dan set aturannya adalah "relaxed" atau "strict".
t=1454417737; – Timestamp ketika tanda tangan dibuat.
Tiga bagian header ini berisi informasi tanda tangan yang sebenarnya:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Ini adalah hash dari body pesan.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Ini adalah daftar header yang digunakan untuk membuat data tanda tangan yang ditunjukkan di bawah.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Ini adalah data tanda tangan DKIM yang sebenarnya
Tiga bagian ini paling menarik bagi server penerima yang akan memvalidasi tanda tangan:
d=welcome.foo.com; – Ini mengidentifikasi domain yang menandatangani pesan
s=notices; – Selector; domain dapat memiliki beberapa selector yang mereka gunakan saat menandatangani pesan.
i=@welcome.foo.com; – Ini adalah identitas atas nama siapa pesan tersebut ditandatangani. Secara sintaksis, ini akan terlihat seperti alamat email, dan mungkin bahkan salah satunya; bagian lokal dari alamat email dapat kosong, seperti dalam contoh ini, dan bagian domain harus sama dengan, atau subdomain dari, domain di bagian d= dari tanda tangan.
Alasan bagian-bagian ini menarik bagi server penerima adalah bahwa mereka memberikan informasi yang diperlukan untuk membantu penerima memvalidasi tanda tangan.
Field | Arti | Bagaimana Penerima Menggunakannya |
|---|---|---|
v= | Versi DKIM (selalu 1) | Mengonfirmasi format tanda tangan |
a= | Algoritma hashing + penandatanganan (misalnya, rsa-sha256) | Memastikan validator mereproduksi tanda tangan dengan benar |
c= | Aturan kanonisasi (header/body) | Menormalkan spasi sebelum hashing |
t= | Timestamp pembuatan tanda tangan | Digunakan untuk pemeriksaan kesegaran dan pencegahan pengulangan |
bh= | Body hash | Penerima menghasilkan ini kembali untuk mengonfirmasi integritas body pesan |
h= | Daftar field header yang ditandatangani | Memastikan header yang digunakan dalam penandatanganan tersedia dan tidak dimodifikasi |
b= | Tanda tangan DKIM yang sebenarnya | Penerima memverifikasi tanda tangan ini terhadap kunci publik |
d= | Domain penandatangan | Digunakan untuk menemukan kunci publik DNS penandatangan |
s= | Selector | Digabungkan dengan domain untuk membentuk: selector._domainkey.domain |
i= | Identitas penandatangan | Harus sama atau subdomain dari d=, mengidentifikasi entitas penandatangan |
Validasi DKIM
Selain persyaratan yang disebutkan bahwa domain i= harus sama dengan atau merupakan sub-domain dari domain d=, bit d= dan s= digunakan oleh validator untuk mencari kunci publik DKIM penanda di DNS. Kunci tersebut adalah catatan TXT di DNS, dan selalu ditemukan di lokasi selector._domainkey.domain. Jadi, dalam contoh kita di sini, dengan s=notices dan d=welcome.foo.com, kunci publik DKIM dapat ditemukan di DNS di notices._domainkey.welcome.foo.com, dan mungkin terlihat seperti ini:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Validator menggunakan kunci tersebut (bit p=) untuk menghasilkan kumpulan hash pesan mereka sendiri; jika hash tersebut cocok, maka pesan tidak berubah selama perjalanan, dan oleh karena itu pesan dapat berkontribusi pada, dan mungkin mendapatkan manfaat dari, reputasi apa pun yang diterapkan untuk penanda pesan.
Selain persyaratan yang disebutkan bahwa domain i= harus sama dengan atau merupakan sub-domain dari domain d=, bit d= dan s= digunakan oleh validator untuk mencari kunci publik DKIM penanda di DNS. Kunci tersebut adalah catatan TXT di DNS, dan selalu ditemukan di lokasi selector._domainkey.domain. Jadi, dalam contoh kita di sini, dengan s=notices dan d=welcome.foo.com, kunci publik DKIM dapat ditemukan di DNS di notices._domainkey.welcome.foo.com, dan mungkin terlihat seperti ini:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Validator menggunakan kunci tersebut (bit p=) untuk menghasilkan kumpulan hash pesan mereka sendiri; jika hash tersebut cocok, maka pesan tidak berubah selama perjalanan, dan oleh karena itu pesan dapat berkontribusi pada, dan mungkin mendapatkan manfaat dari, reputasi apa pun yang diterapkan untuk penanda pesan.
Selain persyaratan yang disebutkan bahwa domain i= harus sama dengan atau merupakan sub-domain dari domain d=, bit d= dan s= digunakan oleh validator untuk mencari kunci publik DKIM penanda di DNS. Kunci tersebut adalah catatan TXT di DNS, dan selalu ditemukan di lokasi selector._domainkey.domain. Jadi, dalam contoh kita di sini, dengan s=notices dan d=welcome.foo.com, kunci publik DKIM dapat ditemukan di DNS di notices._domainkey.welcome.foo.com, dan mungkin terlihat seperti ini:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Validator menggunakan kunci tersebut (bit p=) untuk menghasilkan kumpulan hash pesan mereka sendiri; jika hash tersebut cocok, maka pesan tidak berubah selama perjalanan, dan oleh karena itu pesan dapat berkontribusi pada, dan mungkin mendapatkan manfaat dari, reputasi apa pun yang diterapkan untuk penanda pesan.
Kegagalan Validasi dan Pemecahan Masalah
Saya telah menyebutkan di atas bahwa kegagalan DKIM dapat sulit untuk dipecahkan, dan saya akan menjelaskan mengapa hal itu terjadi di sini.
Beberapa kegagalan validasi DKIM memiliki penyebab yang jelas, seperti pesan yang tidak ditandatangani, atau kunci publik domain penandatangan yang tidak ditemukan di DNS atau tidak benar secara sintaktis, atau mungkin pesan telah jelas diubah dalam perjalanan. Ketika jenis kegagalan ini terjadi, mudah untuk menemukan masalah dan merekomendasikan solusi. Namun yang sulit, dan yang menyebabkan pengalaman dukungan paling frustasi, adalah kasus di mana pesan telah ditandatangani, kunci publik ada di DNS, dan pesan tidak jelas diubah, tetapi validator melaporkan bahwa tanda tangan gagal untuk divalidasi.
Alasan mengapa ini sulit untuk dipecahkan adalah karena tidak ada cara nyata bagi kedua belah pihak untuk mereproduksi kondisi di mana pesan ditandatangani dan divalidasi. Pesan memiliki di header DKIM-Signature-nya hash yang dihasilkan oleh penandatangan pada waktu penandatanganan, tetapi validator kemungkinan tidak memiliki akses ke infrastruktur penandatangan dan sehingga tidak dapat mencoba untuk mereproduksi tanda tangan di bawah kondisi penandatangan. Dengan cara yang sama, penandatangan kemungkinan tidak memiliki akses ke infrastruktur validator dan oleh karena itu tidak memiliki cara untuk mencoba memvalidasi pesan dengan cara yang dilakukan validator.
Kegagalan seperti yang saya gambarkan di sini adalah kejadian yang jarang terjadi, dan kegagalan validasi DKIM sendiri biasanya tidak berdampak pada penempatan pengiriman. Sementara DKIM menangani autentikasi pesan, mengimplementasikan teknik validasi email yang komprehensif memastikan Anda mengirim ke alamat yang sah yang benar-benar dapat menerima dan mengautentikasi pesan Anda. Berdasarkan pengalaman saya, kegagalan semacam itu menghasilkan lebih banyak tiket dukungan daripada jenis masalah DKIM lainnya.
Saya telah menyebutkan di atas bahwa kegagalan DKIM dapat sulit untuk dipecahkan, dan saya akan menjelaskan mengapa hal itu terjadi di sini.
Beberapa kegagalan validasi DKIM memiliki penyebab yang jelas, seperti pesan yang tidak ditandatangani, atau kunci publik domain penandatangan yang tidak ditemukan di DNS atau tidak benar secara sintaktis, atau mungkin pesan telah jelas diubah dalam perjalanan. Ketika jenis kegagalan ini terjadi, mudah untuk menemukan masalah dan merekomendasikan solusi. Namun yang sulit, dan yang menyebabkan pengalaman dukungan paling frustasi, adalah kasus di mana pesan telah ditandatangani, kunci publik ada di DNS, dan pesan tidak jelas diubah, tetapi validator melaporkan bahwa tanda tangan gagal untuk divalidasi.
Alasan mengapa ini sulit untuk dipecahkan adalah karena tidak ada cara nyata bagi kedua belah pihak untuk mereproduksi kondisi di mana pesan ditandatangani dan divalidasi. Pesan memiliki di header DKIM-Signature-nya hash yang dihasilkan oleh penandatangan pada waktu penandatanganan, tetapi validator kemungkinan tidak memiliki akses ke infrastruktur penandatangan dan sehingga tidak dapat mencoba untuk mereproduksi tanda tangan di bawah kondisi penandatangan. Dengan cara yang sama, penandatangan kemungkinan tidak memiliki akses ke infrastruktur validator dan oleh karena itu tidak memiliki cara untuk mencoba memvalidasi pesan dengan cara yang dilakukan validator.
Kegagalan seperti yang saya gambarkan di sini adalah kejadian yang jarang terjadi, dan kegagalan validasi DKIM sendiri biasanya tidak berdampak pada penempatan pengiriman. Sementara DKIM menangani autentikasi pesan, mengimplementasikan teknik validasi email yang komprehensif memastikan Anda mengirim ke alamat yang sah yang benar-benar dapat menerima dan mengautentikasi pesan Anda. Berdasarkan pengalaman saya, kegagalan semacam itu menghasilkan lebih banyak tiket dukungan daripada jenis masalah DKIM lainnya.
Saya telah menyebutkan di atas bahwa kegagalan DKIM dapat sulit untuk dipecahkan, dan saya akan menjelaskan mengapa hal itu terjadi di sini.
Beberapa kegagalan validasi DKIM memiliki penyebab yang jelas, seperti pesan yang tidak ditandatangani, atau kunci publik domain penandatangan yang tidak ditemukan di DNS atau tidak benar secara sintaktis, atau mungkin pesan telah jelas diubah dalam perjalanan. Ketika jenis kegagalan ini terjadi, mudah untuk menemukan masalah dan merekomendasikan solusi. Namun yang sulit, dan yang menyebabkan pengalaman dukungan paling frustasi, adalah kasus di mana pesan telah ditandatangani, kunci publik ada di DNS, dan pesan tidak jelas diubah, tetapi validator melaporkan bahwa tanda tangan gagal untuk divalidasi.
Alasan mengapa ini sulit untuk dipecahkan adalah karena tidak ada cara nyata bagi kedua belah pihak untuk mereproduksi kondisi di mana pesan ditandatangani dan divalidasi. Pesan memiliki di header DKIM-Signature-nya hash yang dihasilkan oleh penandatangan pada waktu penandatanganan, tetapi validator kemungkinan tidak memiliki akses ke infrastruktur penandatangan dan sehingga tidak dapat mencoba untuk mereproduksi tanda tangan di bawah kondisi penandatangan. Dengan cara yang sama, penandatangan kemungkinan tidak memiliki akses ke infrastruktur validator dan oleh karena itu tidak memiliki cara untuk mencoba memvalidasi pesan dengan cara yang dilakukan validator.
Kegagalan seperti yang saya gambarkan di sini adalah kejadian yang jarang terjadi, dan kegagalan validasi DKIM sendiri biasanya tidak berdampak pada penempatan pengiriman. Sementara DKIM menangani autentikasi pesan, mengimplementasikan teknik validasi email yang komprehensif memastikan Anda mengirim ke alamat yang sah yang benar-benar dapat menerima dan mengautentikasi pesan Anda. Berdasarkan pengalaman saya, kegagalan semacam itu menghasilkan lebih banyak tiket dukungan daripada jenis masalah DKIM lainnya.
