Mulailah dengan domain yang dapat Anda otorisasi
Pengaturan CleverReach DKIM panduan menjelaskan alur kerja domain khusus di pengaturan akun. Ini adalah titik awal yang berguna untuk konfigurasi autentikasi, namun domain pengirim harus merupakan domain yang dapat dikelola secara sah oleh organisasi. Akses operator pemasaran ke antarmuka kampanye tidak secara otomatis memberikan kendali atas zona DNS atau persetujuan untuk mengubah seluruh organisasi DMARC kebijakan.
Identifikasi akun yang dituju Dari domain, kategori kampanye, dan pemilik DNS . Jika tim menggunakan alamat freemail publik, jangan mencoba mempublikasikan catatan untuk domain penyedia tersebut. Panduan ini membahas penanganan alamat pengirim freemail, namun hal tersebut bukan merupakan pengganti domain pengirim yang dikontrol sendiri oleh organisasi. Rencanakan perubahan alamat pengirim apa pun yang terlihat dengan pemilik komunikasi sehingga penerima tidak terkejut.
Naskah ini mencakup dokumentasi penyiapan DKIM . Ia tidak menciptakan sebuah SPF sertakan nilai, tegaskan bahwa setiap akun CleverReach memiliki pengaturan yang sama, atau klaim penyewa yang diterapkan telah diperiksa. CleverReach Menyiapkan DKIM
Hasilkan konfigurasi domain dan pemilih
Navigasi yang terdokumentasi dimulai dari ikon profil, lalu Akun Saya, Pengaturan, dan DKIM . Tambahkan domain yang dituju melalui Tambahkan domain. Panduan ini juga menyediakan a pemilih pilihan. Perlakukan domain dan pemilih bersama-sama sebagai konfigurasi tertentu: pemilih yang berbeda mengarahkan pemverifikasi ke lokasi kunci DNS yang berbeda, meskipun alamat pembuatnya tetap tidak berubah.
Setelah menambahkan domain, gunakan menu tindakan untuk Menampilkan pengaturan DNS . Salin yang dihasilkan catatan TXT dari pengaturan domain tersebut daripada meminjam contoh dari akun lain atau menggunakan nama pemilih konvensional. Pertahankan nama pemilik yang ditampilkan, jenis dan nilai lengkap dalam permintaan perubahan. Catat siapa yang membuat permintaan dan akun miliknya, tanpa menyertakan kredensial login.
Selector membantu membedakan kunci DKIM ; hal ini bukan merupakan janji bahwa kunci yang sama dapat digunakan kembali di seluruh vendor atau akun independen. Sebelum mengganti nama pemilik yang ada, tentukan apakah konfigurasi aktif lainnya bergantung padanya. Tabrakan memerlukan resolusi yang ditinjau ulang, bukan penimpaan yang tidak teruji. Pengaturan domain dan pengaturan DNS; RFC 6376 , bagian 3.5
Publikasikan nilai TXT di zona yang benar
Administrator DNS harus memetakan nama pemilik yang dihasilkan ke zona otoritatif dan konvensi editor. Beberapa antarmuka menambahkan nama zona secara otomatis; yang lain menerima nama lengkap. Konfirmasikan nama terbitan yang dihasilkan daripada menganggap nilai bidang visual sebagai sesuatu yang pasti. Tipe data dalam alur kerja CleverReach ini adalah TXT ; jangan diubah menjadi a CNAME hanya karena layanan lain menggunakan alias.
Pertahankan nilai kunci lengkap dan periksa representasi DNS akhir. Data TXT dapat berisi beberapa string karakter yang digabungkan oleh aplikasi; string tersebut tidak sama dengan beberapa catatan independen atas nama pemilik. Menyalin teks presentasi yang dikutip ke dalam bidang yang menyediakan kutipannya sendiri juga memerlukan penanganan khusus penyedia. Jangan menebak perilaku editor dari contoh umum. RFC 1035 , bagian 3.3.14; RFC 6376 , bagian 3.6.2.2.
Dokumentasi mencakup contoh untuk penyedia DNS , namun target penerimaan tetap berupa nama dan nilai yang diinginkan. Singkatan root seperti @ tidak boleh dideskripsikan sebagai wildcard universal untuk setiap subdomain. Dalam sintaks file master RFC 1035 , @ yang berdiri sendiri menunjukkan asal saat ini, tidak setiap subdomain; editor DNS tertentu mungkin memerlukan masukan yang berbeda. RFC 1035 , bagian 5.1; Instruksi TXT yang dihasilkan
Jalankan verifikasi dan tafsirkan status secara sempit
Setelah menerbitkan rekaman, kembali ke menu tindakan domain dan pilih Verifikasi. Panduan ini menjelaskan status aktif setelah verifikasi berhasil. Jaga agar pemeriksaan penyedia ini berbeda dari publikasi DNS itu sendiri. Perubahan DNS yang disimpan tidak membuktikan bahwa layanan telah memeriksanya, dan pemeriksaan yang gagal tidak langsung membenarkan penggantian kunci atau membuat entri domain lain.
Jika pemeriksaan tidak berhasil, bandingkan nama pemilik yang dituju, zona otoritatif, nilai TXT lengkap, dan pilihan domain terlebih dahulu. Kemudian pertimbangkan waktu publikasi dan data cache. Penyedia membahas penundaan propagasi, namun interval tunggu yang dinyatakan tidak boleh menjadi jaminan bahwa catatan yang salah pada akhirnya akan diperbaiki dengan sendirinya. Simpan stempel waktu dan status persisnya sehingga pemeriksaan selanjutnya dapat dibandingkan secara bermakna.
Status tersebut berkaitan dengan konfigurasi yang diperiksa oleh CleverReach. Ini bukan laporan pesan tersampaikan dan tidak membuktikan secara independen di domain mana kampanye tertentu ditandatangani. Perbedaan ini sangat penting ketika sebuah organisasi memiliki beberapa domain pengirim atau kampanye terjadwal yang lebih lama. Verifikasi dan panduan status
Periksa keselarasan pada rute kampanye yang dipilih
Pemeriksaan akhir yang diusulkan adalah pesan kampanye perwakilan resmi yang diperiksa pada sistem penerima. Catat domain Dari yang terlihat, domain DKIM d=, pemilih, dan hasil validasi tepercaya. Bandingkan identitas penandatanganan yang lewat dengan domain penulis menggunakan DMARC yang berlaku penyelarasan mode. Jangan menyimpulkan keselarasan hanya karena kedua domain tersebut mengandung nama merek organisasi.
SPF dan DKIM adalah mekanisme otentikasi terpisah. DMARC dapat menggunakan identitas yang selaras, namun artikel penyiapan DKIM tidak menetapkan konfigurasi SPF lengkap untuk setiap rute produk. Jika SPF perlu ditinjau, dapatkan identitas amplop sebenarnya dan instruksi penyedia saat ini daripada menambahkan dugaan penyertaan di domain akar.
Pesan yang selaras memberikan bukti untuk sampel dan rute tersebut. Itu tidak menjanjikan penempatan kotak masuk, keterlibatan, kualitas persetujuan, atau keamanan permintaan bisnis pesan. Pertahankan pengamatan pengiriman dan keputusan risiko konten dalam alur kerja mereka sendiri. RFC 9989 , bagian 4.4; RFC 7208 , bagian 2.4
Lembar kerja penerimaan untuk administrator kampanye
Gunakan lembar kerja yang diusulkan ini untuk menghubungkan permintaan konfigurasi ke bukti akhir. Selesaikan secara terpisah untuk setiap domain atau rute yang berbeda secara material.
- Kepemilikan domain: beri nama akun, domain pengirim yang dituju, pemilik komunikasi, dan administrator DNS .
- Konfigurasi yang dihasilkan: pertahankan domain yang dipilih, pemilih, dan pemilik/nilai TXT yang dikeluarkan dari Tampilkan pengaturan DNS .
- Tinjauan tabrakan: identifikasi kunci apa pun yang ada dengan nama yang sama dan dependensi aktifnya sebelum mengubahnya.
- Publikasi DNS : catat perubahan yang disetujui, nama pemilik yang memenuhi syarat dan bukti verifikasi yang diharapkan.
- Verifikasi penyedia: catat waktu Verifikasi diminta dan status pengembalian sebenarnya.
- Contoh kampanye: catat kelas pemberitahuan atau kampanye yang dipilih dan identitas penulis/penandatangan yang diamati.
- Keputusan rilis: sebutkan nama pengulas, kesenjangan yang tersisa, dan pemilik pengembalian, bukannya menandai semua kampanye siap dari satu layar.
Tidak ada login akun, publikasi DNS , atau transmisi kampanye yang dilakukan di sini. Lembar kerja tersebut merupakan desain penerimaan asli, bukan catatan implementasi yang telah selesai.
Diagnosis fiktif: domain aktif, pengirim tidak terduga
Organisasi keanggotaan fiktif mengonfigurasi DKIM untuk news.example dan memperoleh status aktif. Kampanye berikutnya masih dijadwalkan dengan alamat Dari yang lama di events.example . Peninjau melihat domain aktif di pengaturan dan awalnya berasumsi bahwa kampanye harus selaras. Kedua observasi tersebut menyangkut identitas yang berbeda, sehingga kesimpulannya tidak didukung.
Investigasi yang diusulkan dimulai dengan pengirim kampanye yang dikonfigurasi dan domain penandatanganan pesan yang diterima. Tim memeriksa apakah domain yang dituju telah dipilih untuk rute tersebut, lalu meninjau hubungan penyelarasan yang relevan. Itu tidak menghapus kunci news.example yang berfungsi untuk memperbaiki kampanye yang tidak terkait. Serah terima akhir membedakan konfigurasi terverifikasi dengan kampanye yang masih memerlukan bukti. Skenario ini fiktif dan tidak berisi pencarian DNS atau pengiriman tes yang dijalankan.