Validasi DKIM: Praktik Terbaik Otentikasi Email
Burung
8 Apr 2017
1 min read
Intisari Utama
DKIM (DomainKeys Identified Mail) adalah metode autentikasi email berbasis konten yang memverifikasi apakah sebuah pesan telah diubah setelah ditandatangani.
Tidak seperti SPF, yang memvalidasi jalur pengiriman, DKIM memvalidasi konten pesan itu sendiri menggunakan tanda tangan kriptografi.
DKIM menggunakan dua kunci: kunci privat untuk menandatangani pesan keluar dan kunci publik yang diterbitkan di DNS untuk penerima agar memvalidasi tanda tangan.
Sebuah tanda tangan DKIM mencakup hash dari header dan badan, selector, stempel waktu, dan bidang identitas — semuanya harus direproduksi dan diverifikasi oleh penerima.
Validasi DKIM bergantung pada penerimaan seluruh pesan terlebih dahulu, yang berarti kegagalan dapat terjadi di tahap akhir proses.
Pemecahan masalah validasi DKIM yang gagal sering kali sulit karena pengirim dan penerima tidak dapat mereproduksi lingkungan penandatanganan/verifikasi satu sama lain.
Bahkan ketika DKIM gagal, biasanya tidak langsung menyebabkan masalah masuk kotak masuk dengan sendirinya kecuali digabungkan dengan sinyal reputasi negatif lainnya.
Sorotan Q&A
Apa yang sebenarnya dilakukan DKIM?
DKIM memasang tanda tangan kriptografi pada email, memungkinkan server penerima untuk mengonfirmasi apakah konten pesan telah dimodifikasi setelah dikirim.
Bagaimana DKIM berbeda dari SPF?
SPF memvalidasi siapa yang diizinkan untuk mengirim email untuk sebuah domain (berdasar jalur).
DKIM memvalidasi apakah konten tetap utuh (berdasar konten).
Keduanya memiliki tujuan yang berbeda dan saling melengkapi satu sama lain.
Apa isi header DKIM-Signature?
Bidang kunci meliputi:
v= version
a= algoritma
c= aturan kanonisasi
d= domain penandatanganan
s= pemilih
h= header yang disertakan dalam tanda tangan
bh= hash tubuh
b= data tanda tangan sebenarnya
Setiap bagian berkontribusi pada cara tanda tangan divalidasi.
Bagaimana server penerima memvalidasi DKIM?
Ekstrak nilai d= dan s=.
Mencari kunci publik di:
selector._domainkey.domain
Regenerasi hash header dan body.
Membandingkannya dengan nilai bh= dan b= dalam email.
Jika cocok, pesan melewati DKIM.
Apa yang menyebabkan DKIM gagal?
Pesan diubah dalam perjalanan (bahkan perubahan spasi jika menggunakan kanonisasi ketat)
Kunci publik yang salah atau hilang dalam DNS
Kesalahan format DNS
Selector dihapus atau diputar secara tidak benar
Identitas tidak cocok (i= harus sama dengan domain atau subdomain dari d=)
Mengapa kegagalan DKIM bisa sulit untuk diatasi?
Karena penandatangan dan validator beroperasi di lingkungan yang sepenuhnya berbeda — tidak ada pihak yang dapat merekonstruksi kondisi hashing atau status tanda tangan pihak lain.
Ini membuat kegagalan "hash mismatch" yang tidak jelas menjadi yang paling membuat frustrasi untuk didiagnosis.
Apakah kegagalan DKIM berarti email akan masuk ke spam?
Tidak selalu.
DKIM hanyalah salah satu sinyal. Jika domain memiliki reputasi yang kuat dan lulus pemeriksaan lainnya (SPF, DMARC alignment, tingkat keluhan rendah), kegagalan DKIM yang terisolasi biasanya tidak berdampak pada inboxing mereka sendiri.
Mengapa menggunakan DKIM sama sekali?
Melindungi integritas pesan
Membangun reputasi domain
Memungkinkan penyelarasan DMARC
Membantu penyedia kotak surat membedakan pengirim yang sah dari pemalsu
DKIM dianggap sebagai praktik terbaik untuk semua pengirim email serius.
Ketika kita berbicara tentang "Email Authentication", kita mengacu pada teknik yang memberikan kepada penerima pesan beberapa tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber yang diklaim. Ide di balik teknik-teknik tersebut adalah untuk mencapai beberapa tingkat pertahanan terhadap email penipuan, seperti phishing dan spoofing, email yang dapat merusak kepercayaan penerima dalam menerima email. Meskipun demikian, tindakan mengirim email yang diautentikasi tidak menegaskan bahwa email itu baik atau diinginkan; itu hanya berarti bahwa email tersebut sedemikian rupa sehingga reputasi untuk pihak yang diautentikasi dapat dibangun dan digunakan secara andal dalam keputusan penerimaan dan penempatan email.
Ada dua bentuk autentikasi email yang digunakan saat ini:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Dalam postingan hari ini, saya akan membahas apa itu DKIM dan bagaimana cara kerjanya.
Ketika kita berbicara tentang "Email Authentication", kita mengacu pada teknik yang memberikan kepada penerima pesan beberapa tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber yang diklaim. Ide di balik teknik-teknik tersebut adalah untuk mencapai beberapa tingkat pertahanan terhadap email penipuan, seperti phishing dan spoofing, email yang dapat merusak kepercayaan penerima dalam menerima email. Meskipun demikian, tindakan mengirim email yang diautentikasi tidak menegaskan bahwa email itu baik atau diinginkan; itu hanya berarti bahwa email tersebut sedemikian rupa sehingga reputasi untuk pihak yang diautentikasi dapat dibangun dan digunakan secara andal dalam keputusan penerimaan dan penempatan email.
Ada dua bentuk autentikasi email yang digunakan saat ini:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Dalam postingan hari ini, saya akan membahas apa itu DKIM dan bagaimana cara kerjanya.
Ketika kita berbicara tentang "Email Authentication", kita mengacu pada teknik yang memberikan kepada penerima pesan beberapa tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber yang diklaim. Ide di balik teknik-teknik tersebut adalah untuk mencapai beberapa tingkat pertahanan terhadap email penipuan, seperti phishing dan spoofing, email yang dapat merusak kepercayaan penerima dalam menerima email. Meskipun demikian, tindakan mengirim email yang diautentikasi tidak menegaskan bahwa email itu baik atau diinginkan; itu hanya berarti bahwa email tersebut sedemikian rupa sehingga reputasi untuk pihak yang diautentikasi dapat dibangun dan digunakan secara andal dalam keputusan penerimaan dan penempatan email.
Ada dua bentuk autentikasi email yang digunakan saat ini:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Dalam postingan hari ini, saya akan membahas apa itu DKIM dan bagaimana cara kerjanya.
Ikhtisar DKIM
Berbeda dengan rekan autentikasinya, SPF, yang menyediakan cara bagi sebuah domain untuk mengotorisasi host guna mengirim email atas namanya, DKIM menyediakan cara bagi suatu entitas (domain, organisasi, individu, dll.) untuk mengambil tanggung jawab atas sebuah pesan, terlepas dari entitas yang sebenarnya mengirim pesan tersebut. Meskipun dalam banyak kasus entitas yang bertanggung jawab dan entitas yang mengirim akan sama, atau setidaknya terhubung erat, dengan DKIM tidak ada persyaratan bahwa hal ini harus demikian.
Tujuan saya untuk Anda dengan posting ini adalah Anda belajar dan memahami konsep-konsep berikut tentang DKIM:
DKIM adalah autentikasi berbasis konten, berbeda dengan 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 hingga pesan lengkap telah ditransmisikan oleh server pengirim.
Kegagalan validasi dapat sulit untuk diatasi.
Berbeda dengan rekan autentikasinya, SPF, yang menyediakan cara bagi sebuah domain untuk mengotorisasi host guna mengirim email atas namanya, DKIM menyediakan cara bagi suatu entitas (domain, organisasi, individu, dll.) untuk mengambil tanggung jawab atas sebuah pesan, terlepas dari entitas yang sebenarnya mengirim pesan tersebut. Meskipun dalam banyak kasus entitas yang bertanggung jawab dan entitas yang mengirim akan sama, atau setidaknya terhubung erat, dengan DKIM tidak ada persyaratan bahwa hal ini harus demikian.
Tujuan saya untuk Anda dengan posting ini adalah Anda belajar dan memahami konsep-konsep berikut tentang DKIM:
DKIM adalah autentikasi berbasis konten, berbeda dengan 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 hingga pesan lengkap telah ditransmisikan oleh server pengirim.
Kegagalan validasi dapat sulit untuk diatasi.
Berbeda dengan rekan autentikasinya, SPF, yang menyediakan cara bagi sebuah domain untuk mengotorisasi host guna mengirim email atas namanya, DKIM menyediakan cara bagi suatu entitas (domain, organisasi, individu, dll.) untuk mengambil tanggung jawab atas sebuah pesan, terlepas dari entitas yang sebenarnya mengirim pesan tersebut. Meskipun dalam banyak kasus entitas yang bertanggung jawab dan entitas yang mengirim akan sama, atau setidaknya terhubung erat, dengan DKIM tidak ada persyaratan bahwa hal ini harus demikian.
Tujuan saya untuk Anda dengan posting ini adalah Anda belajar dan memahami konsep-konsep berikut tentang DKIM:
DKIM adalah autentikasi berbasis konten, berbeda dengan 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 hingga pesan lengkap telah ditransmisikan oleh server pengirim.
Kegagalan validasi dapat sulit untuk diatasi.
“Content-Based” Authentication
DKIM disebut sebagai otentikasi "berbasis konten", bukan "berbasis jalur", karena apakah sebuah pesan lolos validasi DKIM didasarkan sepenuhnya pada apakah konten tersebut telah berubah antara waktu ditandatangani dan waktu validasi dilakukan.
DKIM disebut sebagai otentikasi "berbasis konten", bukan "berbasis jalur", karena apakah sebuah pesan lolos validasi DKIM didasarkan sepenuhnya pada apakah konten tersebut telah berubah antara waktu ditandatangani dan waktu validasi dilakukan.
DKIM disebut sebagai otentikasi "berbasis konten", bukan "berbasis jalur", karena apakah sebuah pesan lolos validasi DKIM didasarkan sepenuhnya pada apakah konten tersebut telah berubah antara waktu ditandatangani dan waktu validasi dilakukan.
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 guna penandatanganan email, dan yang lainnya dibuat publik di DNS untuk digunakan oleh domain penerima dalam upaya memvalidasi tanda tangan tersebut. Metode untuk menghasilkan kunci-kunci ini dan menginstalnya bergantung pada platform dan di luar cakupan pos ini, meskipun nantinya saya akan menjelaskan 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 guna penandatanganan email, dan yang lainnya dibuat publik di DNS untuk digunakan oleh domain penerima dalam upaya memvalidasi tanda tangan tersebut. Metode untuk menghasilkan kunci-kunci ini dan menginstalnya bergantung pada platform dan di luar cakupan pos ini, meskipun nantinya saya akan menjelaskan 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 guna penandatanganan email, dan yang lainnya dibuat publik di DNS untuk digunakan oleh domain penerima dalam upaya memvalidasi tanda tangan tersebut. Metode untuk menghasilkan kunci-kunci ini dan menginstalnya bergantung pada platform dan di luar cakupan pos ini, meskipun nantinya saya akan menjelaskan penerbitan kunci DKIM publik di DNS.
Header DKIM-Signature
Untuk memulai pemahaman kita tentang DKIM, mari kita pertama 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 di antaranya lebih menarik bagi pembaca daripada yang lain, tetapi saya akan menjelaskan semuanya di sini.
Pertama, kita akan melihat kunci-nilai yang sebagian besar memiliki ketertarikan dangkal bagi pembaca:
v=1; – Menentukan versi DKIM (1 adalah satu-satunya nilai yang valid)
a=rsa-sha256; – Algoritma yang digunakan untuk menyusun hash kriptografis
c=relaxed/relaxed; – Ada dua set aturan mengenai penghapusan whitespace di header dan body yang dapat diterapkan ketika membuat hash dalam tanda tangan DKIM; aturan ini disebut “aturan kanonisasi” (maka kunci c) dan set aturannya adalah "relaxed" atau "strict".
t=1454417737; – Timestamp kapan tanda tangan dibuat.
Tiga bagian header ini mengandung 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 banyak selector yang mereka gunakan ketika menandatangani pesan.
i=@welcome.foo.com; – Ini adalah identitas atas nama siapa pesan itu ditandatangani. Secara sintaksis, ini akan terlihat seperti alamat email, dan mungkin memang satu; bagian lokal dari alamat email ini bisa kosong, seperti dalam contoh ini, dan bagian domain harus sama, atau subdomain dari, domain dalam bagian d= dari tanda tangan.
Alasan bagian ini menarik bagi server penerima adalah karena mereka memberikan informasi yang diperlukan untuk membantu penerima memvalidasi tanda tangan.
Untuk memulai pemahaman kita tentang DKIM, mari kita pertama 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 di antaranya lebih menarik bagi pembaca daripada yang lain, tetapi saya akan menjelaskan semuanya di sini.
Pertama, kita akan melihat kunci-nilai yang sebagian besar memiliki ketertarikan dangkal bagi pembaca:
v=1; – Menentukan versi DKIM (1 adalah satu-satunya nilai yang valid)
a=rsa-sha256; – Algoritma yang digunakan untuk menyusun hash kriptografis
c=relaxed/relaxed; – Ada dua set aturan mengenai penghapusan whitespace di header dan body yang dapat diterapkan ketika membuat hash dalam tanda tangan DKIM; aturan ini disebut “aturan kanonisasi” (maka kunci c) dan set aturannya adalah "relaxed" atau "strict".
t=1454417737; – Timestamp kapan tanda tangan dibuat.
Tiga bagian header ini mengandung 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 banyak selector yang mereka gunakan ketika menandatangani pesan.
i=@welcome.foo.com; – Ini adalah identitas atas nama siapa pesan itu ditandatangani. Secara sintaksis, ini akan terlihat seperti alamat email, dan mungkin memang satu; bagian lokal dari alamat email ini bisa kosong, seperti dalam contoh ini, dan bagian domain harus sama, atau subdomain dari, domain dalam bagian d= dari tanda tangan.
Alasan bagian ini menarik bagi server penerima adalah karena mereka memberikan informasi yang diperlukan untuk membantu penerima memvalidasi tanda tangan.
Untuk memulai pemahaman kita tentang DKIM, mari kita pertama 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 di antaranya lebih menarik bagi pembaca daripada yang lain, tetapi saya akan menjelaskan semuanya di sini.
Pertama, kita akan melihat kunci-nilai yang sebagian besar memiliki ketertarikan dangkal bagi pembaca:
v=1; – Menentukan versi DKIM (1 adalah satu-satunya nilai yang valid)
a=rsa-sha256; – Algoritma yang digunakan untuk menyusun hash kriptografis
c=relaxed/relaxed; – Ada dua set aturan mengenai penghapusan whitespace di header dan body yang dapat diterapkan ketika membuat hash dalam tanda tangan DKIM; aturan ini disebut “aturan kanonisasi” (maka kunci c) dan set aturannya adalah "relaxed" atau "strict".
t=1454417737; – Timestamp kapan tanda tangan dibuat.
Tiga bagian header ini mengandung 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 banyak selector yang mereka gunakan ketika menandatangani pesan.
i=@welcome.foo.com; – Ini adalah identitas atas nama siapa pesan itu ditandatangani. Secara sintaksis, ini akan terlihat seperti alamat email, dan mungkin memang satu; bagian lokal dari alamat email ini bisa kosong, seperti dalam contoh ini, dan bagian domain harus sama, atau subdomain dari, domain dalam bagian d= dari tanda tangan.
Alasan bagian ini menarik bagi server penerima adalah karena mereka memberikan informasi yang diperlukan untuk membantu penerima memvalidasi tanda tangan.
DKIM Validation
Selain persyaratan yang disebutkan bahwa domain i= harus sama dengan atau sub-domain dari domain d=, bit d= dan s= digunakan oleh validator untuk mencari kunci DKIM publik penandatangan di DNS. Kuncinya 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 DKIM publik akan 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 serangkaian hash dari pesan; jika hash tersebut cocok, maka pesan tersebut tidak diubah selama pengiriman, dan dengan demikian pesan tersebut dapat berkontribusi pada, dan mungkin mendapatkan manfaat dari, reputasi apa pun yang ada untuk penandatangan pesan tersebut.
Selain persyaratan yang disebutkan bahwa domain i= harus sama dengan atau sub-domain dari domain d=, bit d= dan s= digunakan oleh validator untuk mencari kunci DKIM publik penandatangan di DNS. Kuncinya 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 DKIM publik akan 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 serangkaian hash dari pesan; jika hash tersebut cocok, maka pesan tersebut tidak diubah selama pengiriman, dan dengan demikian pesan tersebut dapat berkontribusi pada, dan mungkin mendapatkan manfaat dari, reputasi apa pun yang ada untuk penandatangan pesan tersebut.
Selain persyaratan yang disebutkan bahwa domain i= harus sama dengan atau sub-domain dari domain d=, bit d= dan s= digunakan oleh validator untuk mencari kunci DKIM publik penandatangan di DNS. Kuncinya 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 DKIM publik akan 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 serangkaian hash dari pesan; jika hash tersebut cocok, maka pesan tersebut tidak diubah selama pengiriman, dan dengan demikian pesan tersebut dapat berkontribusi pada, dan mungkin mendapatkan manfaat dari, reputasi apa pun yang ada untuk penandatangan pesan tersebut.
Gagal Validasi dan Pemecahan Masalah
Saya menyebutkan sebelumnya bahwa kegagalan DKIM dapat sulit untuk diatasi, dan saya akan menjelaskan mengapa demikian di sini.
Beberapa kegagalan validasi DKIM memiliki penyebab yang jelas, seperti pesan yang tidak ditandatangani, atau kunci publik domain penandatangan tidak ditemukan di DNS atau tidak secara sintaksis benar, atau mungkin pesan diubah secara jelas selama transit. Ketika kegagalan semacam itu terjadi, mudah untuk mengetahui masalahnya dan merekomendasikan solusi. Namun, yang sulit dan yang menyebabkan pengalaman dukungan paling membuat frustrasi adalah kasus di mana pesan ditandatangani, kunci publik ada di DNS, dan pesan tidak diubah secara jelas, tetapi validator melaporkan bahwa tanda tangan gagal divalidasi.
Alasan mengapa hal ini sulit untuk diatasi adalah karena tidak ada cara nyata bagi kedua pihak untuk mereproduksi kondisi di mana pesan ditandatangani dan divalidasi. Pesan memiliki dalam header DKIM-Signature hash yang dihasilkan oleh penandatangan pada saat penandatanganan, tetapi validator mungkin tidak memiliki akses ke infrastruktur penandatangan dan tidak dapat mencoba mereproduksi tanda tangan dalam kondisi penandatangan. Demikian pula, penandatangan kemungkinan tidak memiliki akses ke infrastruktur validator dan tidak memiliki cara untuk mencoba memvalidasi pesan dengan cara yang dilakukan oleh validator.
Kegagalan seperti yang saya jelaskan di sini jarang terjadi, dan kegagalan validasi DKIM biasanya tidak berdampak pada penempatan pengiriman. Sementara DKIM menangani autentikasi pesan, menerapkan teknik validasi email yang komprehensif memastikan Anda mengirim ke alamat yang sah yang benar-benar dapat menerima dan mengautentikasi pesan Anda. Dalam pengalaman saya, kegagalan semacam itu lebih memicu tiket dukungan dibandingkan masalah DKIM lain apa pun.
Saya menyebutkan sebelumnya bahwa kegagalan DKIM dapat sulit untuk diatasi, dan saya akan menjelaskan mengapa demikian di sini.
Beberapa kegagalan validasi DKIM memiliki penyebab yang jelas, seperti pesan yang tidak ditandatangani, atau kunci publik domain penandatangan tidak ditemukan di DNS atau tidak secara sintaksis benar, atau mungkin pesan diubah secara jelas selama transit. Ketika kegagalan semacam itu terjadi, mudah untuk mengetahui masalahnya dan merekomendasikan solusi. Namun, yang sulit dan yang menyebabkan pengalaman dukungan paling membuat frustrasi adalah kasus di mana pesan ditandatangani, kunci publik ada di DNS, dan pesan tidak diubah secara jelas, tetapi validator melaporkan bahwa tanda tangan gagal divalidasi.
Alasan mengapa hal ini sulit untuk diatasi adalah karena tidak ada cara nyata bagi kedua pihak untuk mereproduksi kondisi di mana pesan ditandatangani dan divalidasi. Pesan memiliki dalam header DKIM-Signature hash yang dihasilkan oleh penandatangan pada saat penandatanganan, tetapi validator mungkin tidak memiliki akses ke infrastruktur penandatangan dan tidak dapat mencoba mereproduksi tanda tangan dalam kondisi penandatangan. Demikian pula, penandatangan kemungkinan tidak memiliki akses ke infrastruktur validator dan tidak memiliki cara untuk mencoba memvalidasi pesan dengan cara yang dilakukan oleh validator.
Kegagalan seperti yang saya jelaskan di sini jarang terjadi, dan kegagalan validasi DKIM biasanya tidak berdampak pada penempatan pengiriman. Sementara DKIM menangani autentikasi pesan, menerapkan teknik validasi email yang komprehensif memastikan Anda mengirim ke alamat yang sah yang benar-benar dapat menerima dan mengautentikasi pesan Anda. Dalam pengalaman saya, kegagalan semacam itu lebih memicu tiket dukungan dibandingkan masalah DKIM lain apa pun.
Saya menyebutkan sebelumnya bahwa kegagalan DKIM dapat sulit untuk diatasi, dan saya akan menjelaskan mengapa demikian di sini.
Beberapa kegagalan validasi DKIM memiliki penyebab yang jelas, seperti pesan yang tidak ditandatangani, atau kunci publik domain penandatangan tidak ditemukan di DNS atau tidak secara sintaksis benar, atau mungkin pesan diubah secara jelas selama transit. Ketika kegagalan semacam itu terjadi, mudah untuk mengetahui masalahnya dan merekomendasikan solusi. Namun, yang sulit dan yang menyebabkan pengalaman dukungan paling membuat frustrasi adalah kasus di mana pesan ditandatangani, kunci publik ada di DNS, dan pesan tidak diubah secara jelas, tetapi validator melaporkan bahwa tanda tangan gagal divalidasi.
Alasan mengapa hal ini sulit untuk diatasi adalah karena tidak ada cara nyata bagi kedua pihak untuk mereproduksi kondisi di mana pesan ditandatangani dan divalidasi. Pesan memiliki dalam header DKIM-Signature hash yang dihasilkan oleh penandatangan pada saat penandatanganan, tetapi validator mungkin tidak memiliki akses ke infrastruktur penandatangan dan tidak dapat mencoba mereproduksi tanda tangan dalam kondisi penandatangan. Demikian pula, penandatangan kemungkinan tidak memiliki akses ke infrastruktur validator dan tidak memiliki cara untuk mencoba memvalidasi pesan dengan cara yang dilakukan oleh validator.
Kegagalan seperti yang saya jelaskan di sini jarang terjadi, dan kegagalan validasi DKIM biasanya tidak berdampak pada penempatan pengiriman. Sementara DKIM menangani autentikasi pesan, menerapkan teknik validasi email yang komprehensif memastikan Anda mengirim ke alamat yang sah yang benar-benar dapat menerima dan mengautentikasi pesan Anda. Dalam pengalaman saya, kegagalan semacam itu lebih memicu tiket dukungan dibandingkan masalah DKIM lain apa pun.
