Penyewa dapat berisi beberapa merek, domain yang diperoleh, dan alamat staf tanpa menandatangani semuanya dengan cara yang sama. DKIM berfungsi dengan domain penandatanganan yang dibawa dalam setiap pesan, bukan dengan label penyewa di portal administrasi. Tetapkan identitas mana yang didukung layanan, lalu buktikan hasilnya untuk setiap domain yang penting.
Panduan ini menjelaskan alur kerja verifikasi netral penyedia. Ini tidak menyatakan bahwa produk atau langganan tertentu mendukung penandatanganan domain khusus. Dapatkan instruksi terkini untuk layanan dan rute sebenarnya sebelum menerbitkan catatan atau mengubah konfigurasinya.
Bangun inventaris domain dan rute
Catat yang terlihat Dari domain, pemilik bisnis, penyewa, aplikasi pengirim, domain DKIM d yang diharapkan, pemilih, pemilik DNS dan negara penandatanganan. Sertakan email web, SMTP yang diautentikasi, API aplikasi, akun yang didelegasikan, dan rute gateway apa pun yang benar-benar digunakan. Tes surat karyawan yang berhasil tidak menentukan bagaimana aplikasi faktur ditandatangani.
Pisahkan domain terverifikasi di penyewa dari domain yang dikonfigurasi untuk penandatanganan keluar. Pisahkan juga catatan DNS yang ada dari pengirim secara aktif menggunakan kunci pribadinya yang sesuai. Ini adalah negara bagian yang berbeda, dan baik pemeriksaan kepemilikan maupun kunci yang dipublikasikan tidak membuktikan bahwa pesan yang diterima memiliki tanda tangan yang valid.
Petakan identitas dalam surat yang diterima
Untuk setiap rute, kirim pesan terkontrol ke kotak surat eksternal yang dapat Anda periksa. Pertahankan bentuk mentahnya dan terpercaya penerimanya Authentication-Results. Baca d dan s dari masing-masing DKIM-Signature. RFC 6376 mendefinisikan nama pencarian sebagai pemilih di bawah _domainkey dari domain penandatanganan. Oleh karena itu, tanda tangan dengan d=brand.example dan s=tenant1 menunjuk ke tenant1._domainkey.brand.example .
Evaluasi verifikasi tanda tangan dan DMARC penyelarasan terpisah. Domain di d adalah identitas DKIM yang relevan untuk DMARC . Penyelarasan yang ketat memerlukan pencocokan domain yang tepat; penyelarasan santai membandingkan domain organisasi berdasarkan aturan penemuan yang berlaku. Memiliki kedua domain di penyewa komersial yang sama tidak membuat domain yang tidak terkait menjadi selaras. RFC 9989 bagian 3.2.10 dan 4.4 menjelaskan perbedaan tersebut.
Kerjakan melalui contoh dua merek
Inventaris ilustratif: penyewa mengirimkan email karyawan dari brand.example menggunakan d=brand.example dan email kampanye dari second.example menggunakan d=provider.example. Asumsikan kedua tanda tangan lolos. Yang pertama adalah penjajaran DKIM yang tepat. Yang kedua tidak menyediakan DKIM yang selaras untuk second.example hanya karena penyewa yang sama memiliki kedua alur kerja.
Tambahkan hasil terpisah untuk SPF daripada menyatakan pesan kedua sebagai kegagalan DMARC tanpa memeriksanya. Dengan kebijakan yang berlaku dan tidak ada kesalahan evaluasi yang belum terselesaikan, identitas SPF yang selaras dan diteruskan masih dapat memenuhi DMARC untuk pesan tersebut. Namun, RFC 9989 bagian 7.4 dan 8 memerlukan penerbitan domain p=reject tidak hanya mengandalkan SPF untuk izin DMARC -nya dan menerapkan tanda tangan DKIM yang valid. Perlakukan jalur DKIM yang tidak selaras sebagai kesenjangan penerapan kebijakan tersebut, bukan rancangan kebijakan penolakan yang menyeluruh. Contoh ini menunjukkan jalur DKIM yang hilang, bukan keputusan penerima yang lengkap. Ini adalah identitas sintetis dan hasil yang diasumsikan, bukan tes dari penyedia sebenarnya.
Konfigurasikan hanya identitas penandatanganan yang didukung
Tanyakan kepada penyedia cara mengaktifkan setiap domain, apakah alias mengikuti konfigurasi domain primer, dan apakah rute SMTP dan API berperilaku berbeda. Ikuti persisnya TXT atau CNAME instruksi. Dengan model CNAME , ikuti delegasi ke data verifikasi yang dikelola penyedia; jangan mengganti kunci publik yang ditebak atau menyalin target penyewa lain.
Gunakan pemilih terpisah jika layanan memerlukannya dan simpan catatan kepemilikan. Menggunakan kembali label pemilih di domain yang berbeda pada dasarnya bukanlah suatu tabrakan karena nama lengkap DNS berbeda. RFC 6376 bagian 3.6.2.2 memerlukan kunci catatan TXT menjadi unik untuk nama pemilih; beberapa data TXT pada nama pencarian tersebut memiliki hasil yang tidak ditentukan. Jangan publikasikan kunci pesaing di sana.
Tutup inventaris dengan bukti
Tandai setiap baris diverifikasi hanya jika baris tersebut memiliki sampel pesan bertanggal yang diterima, identitas yang diharapkan, hasil tanda tangan yang diamati, dan penilaian penyelarasan. Catat setiap rute yang tidak didukung sebagai batasan dengan pemilik dan alternatif, daripada menyembunyikannya di balik status diaktifkan penyewa.
Uji ulang setelah menambahkan domain, mengubah aturan perutean, atau memigrasikan merek. Sertakan catatan yang didelegasikan dalam offboarding sehingga otoritas penandatanganan dan ketergantungan penyedia tidak melampaui tujuannya. Hasil yang berguna adalah peta domain-ke-penandatanganan yang dapat dijelaskan, bukan tangkapan layar dari peralihan global.
Selesaikan satu baris bukti per rute
- Diharapkan: pemilik bisnis, Dari domain, rute aplikasi, domain penandatanganan, dan pemilih.
- Diterbitkan: nama DNS pemilih yang tepat, jenis catatan, dan target yang didelegasikan jika digunakan.
- Diamati: tanggal pesan diterima, setiap pasangan d=/s= dan hasil verifikasi terpercaya.
- Selaras: bandingkan identitas DKIM dan SPF yang lolos dengan Dari berdasarkan kebijakan yang berlaku.
- Keputusan: terverifikasi, tidak didukung atau tidak terselesaikan, dengan pemilik dan pengujian berikutnya.
- Pensiun: mencatat kapan rute berhenti ditandatangani, tunjangan antrian surat dan siapa yang menghapus delegasi yang sudah usang.