Mendelegasikan subdomain dapat membuat layanan pengiriman lebih mudah dioperasikan, namun juga mendistribusikan kontrol atas identitas organisasi. Sebuah berguna DKIM desain memberi nama pemilik DNS , penjaga kunci pribadi, dan pemilik bisnis secara terpisah. Ini juga menyatakan dengan tepat apa yang didelegasikan dan bagaimana delegasi tersebut akan berakhir.
Jangan memulai dengan menerbitkan catatan yang membatasi atau berasumsi subdomain hanya mengirim email. Tetapkan tujuan saat ini dan yang dimaksudkan, termasuk penerimaan, penggunaan aplikasi, dan ketergantungan yang diwariskan. Konfigurasi DKIM saja tidak menentukan apakah namespace harus menerima pesan, melayani situs web, atau tetap tidak aktif.
Tentukan batas delegasi
Bedakan tingkat pemilih CNAME dari delegasi seluruh zona DNS menggunakan catatan NS. A pemilih CNAME mengarahkan pencarian tertentu ke data verifikasi yang dikelola penyedia di bawah RFC 1034 §3.6.2. Delegasi zona memberikan tanggung jawab otoritatif atas nama-nama di dalam zona tersebut, dengan tunduk pada pemotongan zona lebih lanjut, berdasarkan RFC 1034 §4.2; cakupannya dapat mencakup catatan yang tidak terkait dengan DKIM . Tinjau otoritas yang lebih luas tersebut sebelum memperlakukan kedua mekanisme tersebut sebagai sesuatu yang dapat dipertukarkan.
Catat nama pencarian pemilih lengkap, zona target atau otoritatif, domain yang dituju, dan akun penyedia. RFC 6376 §3.1 menjelaskan kasus penggunaan pemilih dan RFC 6376 §3.6.2.1 mendefinisikan pencarian kunci. Itu tidak menentukan izin di panel kontrol penyedia tertentu. Dapatkan instruksi terkini dari penyedia dan pemilik yang bertanggung jawab atas izin tersebut.
Tetapkan tiga jenis kepemilikan
Pemilik bisnis mengetahui pesan mana yang harus terus berfungsi. Pemilik DNS dapat menerbitkan atau menghapus pencarian atau delegasi. Penjaga kunci mengontrol kunci penandatanganan pribadi, baik itu sistem internal atau penyedia terkelola. Satu tim dapat memegang beberapa peran, namun setiap tanggung jawab harus jelas.
Tanyakan siapa yang dapat merotasi kunci, mengubah domain penandatanganan, mengekspor bukti, dan menonaktifkan akun pengirim. Data verifikasi publik bukan kunci penandatanganan pribadi. Jangan pernah meminta kunci pribadi penyedia hanya untuk membuktikannya sebuah rekor benar; gunakan kontrol terdokumentasi dan verifikasi pesan yang diterima.
Kerjakan melalui contoh yang tercakup
Desain ilustrasi: receipts.mail.example ditetapkan ke layanan penagihan, dengan tanda tangan yang didukung menggunakan d=receipts.mail.example dan pemilih bill1. Organisasi mempertahankan DNS induknya, sementara penyedia mengontrol materi verifikasi yang dicapai oleh bill1._domainkey.receipts.mail.example . Catat pemilik penagihan, pemilik perubahan DNS , dan penjaga kunci penyedia dengan nama persisnya.
Jika domain Dari yang terlihat adalah receipts.mail.example , identitasnya sama persis. Jika Dari malah menggunakan mail.example , nilai konfigurasinya penyelarasan mode di bawah RFC 9989 §3.2.10 dan penemuan domain organisasi di bawah RFC 9989 §4.10.2; jangan berasumsi keselarasan yang ketat. Tanda tangan yang lewat membuktikan hubungan kriptografi untuk domain d-nya, bukan bahwa setiap alamat di bawah induk memiliki otorisasi bisnis yang sama. Ini adalah perlengkapan desain, bukan hasil penyewa langsung.
Periksa dependensi tersembunyi sebelum perubahan
Telusuri inventaris konfigurasi untuk pekerjaan terjadwal, aplikasi era akuisisi, dan sistem kampanye lama menggunakan subdomain. Tinjau persyaratan penerimaan secara terpisah. Perubahan delegasi DNS dapat memengaruhi lebih dari DKIM , sedangkan penghapusan pemilih dapat memengaruhi pesan tertunda yang sudah ditandatangani dengan pemilih tersebut.
Siapkan tes representatif untuk setiap rute pengiriman yang diketahui. Ambil Dari, d, s, hasil dan penyelarasan penerima tepercaya, bersama dengan jawaban DNS dan stempel waktu. Verifikasi jalur normal serta rute pemulihan. Dasbor yang ditandai terverifikasi adalah bukti konfigurasi yang berguna, namun bukan pengganti sampel pesan yang diterima.
Jadikan offboarding sebagai bagian dari desain awal
Dokumentasikan cara menghentikan penandatanganan baru, mempertahankan verifikasi yang diperlukan selama transisi yang direncanakan, dan menghapus delegasi yang tidak digunakan setelah ketergantungan berakhir. Mengkoordinasikan akses akun dan kredensial API secara terpisah; menghapus satu data DNS tidak menyelesaikan penghentian penyedia. Jika diduga terjadi kompromi kunci, pengendalian keamanan dapat diprioritaskan dibandingkan tumpang tindih biasa.
Register akhir harus menunjukkan tujuan namespace, wewenang yang diberikan, pemilik, pengujian dan kondisi keluar. Catatan tersebut memungkinkan administrator berikutnya membedakan ketergantungan yang diperlukan dari penunjuk yang ditinggalkan tanpa menebak nama penyedia di DNS .
Catat keputusan selanjutnya
Sebelum disetujui, bandingkan nama dan jenis catatan yang diminta dengan otoritas yang dituju. Satu pemilih CNAME tidak boleh diganti secara diam-diam dengan delegasi NS untuk seluruh zona. Jika penyedia memerlukan cakupan yang lebih luas, buat daftar nama dan dependensi yang terpengaruh dan dapatkan keputusan dari pemilik yang bertanggung jawab. Contoh ini tidak memberikan otoritas DNS yang sebenarnya.