Pisahkan kepemilikan domain Clever Elements dari autentikasi
Clever Elements menerbitkan instruksi terpisah untuk membuktikan kontrol domain dan mengonfigurasi otentikasi email. Panduan ini mencakup alur kerja akun Clever Elements yang terdokumentasi, bukan CleverReach atau platform pemasaran lain yang memiliki nama serupa. Artikel autentikasi tertanggal 19 April 2024, dan artikel kepemilikan tertanggal 19 Maret 2024. Langkah-langkah produknya memberikan bukti penyiapan yang berguna, namun usianya memerlukan tinjauan penerapan akun saat ini, terutama jika lebih tua DMARC saran berbeda dari standar saat ini.
Itu panduan kepemilikan domain mengarahkan pengguna untuk mempublikasikan a catatan TXT berisi kode konfirmasi dari akun tersebut. Gunakan kode yang dikeluarkan tersebut daripada kode ilustrasi yang dicetak dalam artikel. Pemeriksaan tersebut menunjukkan kendali atas konfigurasi DNS yang relevan; itu bukan sebuah DKIM kunci publik, sebuah SPF kebijakan atau bukti bahwa surat tertentu diautentikasi. Jaga agar tujuan setiap catatan tetap eksplisit dalam permintaan perubahan.
Identifikasi domain pengirim dan dependensi yang ada
Sebelum menambahkan catatan, identifikasi domain pengirim sebenarnya yang digunakan oleh surat yang dituju dan siapa yang mengelola DNS otoritatifnya. Domain yang digunakan untuk tautan web mungkin berbeda dengan domain di alamat penulis email yang terlihat. Clever Elements merekomendasikan domain hyperlink bermerek terpisah bersama autentikasi, namun rekomendasi tersebut tidak boleh dianggap sebagai bukti bahwa pencitraan merek tautan mengautentikasi pengirim. Tinjau setiap fungsi dengan ketentuannya masing-masing.
Inventarisasi kebijakan SPF yang ada, aktif pemilih DKIM pemilik dan kebijakan DMARC saat ini sebelum mengubah apa pun. Catat layanan lain yang mengirimkan dengan identitas organisasi yang sama sehingga otorisasinya tidak terhapus secara tidak sengaja. Jika domain yang dipilih adalah subdomain, tinjau kebijakan dan delegasi sebenarnya daripada berasumsi bahwa setiap pengaturan diwarisi dari induknya. Tidak ada domain pelanggan, milis, atau data DNS yang diperiksa untuk naskah ini.
Publikasikan alias DKIM yang terdokumentasi dan aktifkan penandatanganan secara terpisah
Pejabat itu panduan pengaturan otentikasi menentukan a CNAME dengan awalan cemsc. _domainkey menunjuk ke dkim.cemsc.net untuk domain pengirim. Konfirmasikan bahwa nilai yang terdokumentasi ini tetap berlaku untuk rekening giro sebelum dipublikasikan. Bandingkan pemilik akhir yang sepenuhnya memenuhi syarat dengan perilaku akhiran editor DNS , dan periksa apakah catatan yang ada pada nama tersebut masih diperlukan. Jangan menimpa pemilik yang ditempati tanpa memahami ketergantungannya.
Panduan ini secara eksplisit mengharuskan pengaktifan pengiriman DKIM untuk akun setelah menambahkan catatan. Ini menjelaskan jendela opsi pengoptimalan dan kontrol alternatif di akun pengguna di kanan atas. Publikasi DNS dan pengaturan akun tersebut merupakan langkah yang berbeda. Alias yang benar tidak dapat membuat penanda tangan yang tidak aktif menghasilkan tanda tangan, dan kontrol yang diaktifkan tidak dapat memvalidasi alias yang salah. Catatlah bukti catatan publik dan status rekening sebenarnya ketika operator yang berwenang melakukan pekerjaan tersebut.
CNAME mendelegasikan pencarian kunci publik ke target penyedia yang disebutkan. Itu tidak menerbitkan kunci pribadi, dan tidak ada materi pribadi yang termasuk dalam lembar kerja penerimaan. RFC 6376 , bagian 3.5 dan 3.6.2.2 tentukan bidang tanda tangan dan penyimpanan kunci TXT . Verifikasi tingkat pesan selanjutnya harus menggunakan domain tanda tangan dan pemilih yang sebenarnya daripada mengasumsikan keberadaan awalan DNS yang sudah dikenal membuktikan kunci mana yang menandatangani pesan.
Gabungkan otorisasi SPF daripada menyalin keseluruhan contoh
Panduan Clever Elements mencetak kebijakan yang berisi mx, include:cemsc.net dan softfail sepanjang jangka waktu. Itu adalah contoh penyedia, bukan inventaris lengkap dari setiap pengirim yang sah untuk organisasi nyata. Tinjau apakah mekanismenya sesuai dengan infrastruktur resmi yang sebenarnya. Jangan membuat yang kedua mandiri Catatan SPF atau menghapus kotak surat dan layanan transaksional yang ada hanya untuk mereproduksi sampel artikel.
RFC 7208 , bagian 2.4, 3.2 dan 4.6.4 mengenali KIRIM DARI, jelaskan perilaku beberapa rekaman dan tetapkan batasan pada istilah yang bergantung pada DNS yang dievaluasi. Nilai identitas amplop yang digunakan oleh rute pengiriman sebenarnya dan kebijakan lengkapnya. Hitung ketergantungan yang bertumpuk di sepanjang jalur evaluasi daripada memperlakukan setiap penyertaan yang terlihat sebagai keseluruhan biaya pencarian. Menerbitkan penyertaan SPF tidak dengan sendirinya mengonfigurasi aplikasi untuk menggunakan identitas atau jaminan amplop tertentu penyelarasan dengan domain pengirim yang terlihat.
Rekonsiliasi resep DMARC lama dengan persyaratan saat ini
Artikel penyedia tahun 2024 menyertakan instruksi peluncuran berbasis persentase dan tag persen dalam sampelnya catatan DMARC. RFC 9989 , Lampiran A.6 menghapus dokumen persen dari spesifikasi DMARC saat ini. Jangan menampilkan resep lama tersebut sebagai generator standar saat ini atau berasumsi bahwa persentasenya akan memberikan kontrol peluncuran yang diharapkan di seluruh penerima. Tinjau cakupan pengirim yang ada dan pilih rencana transisi berdasarkan perilaku dan bukti saat ini.
Penyedia juga menggambarkan alamat pelaporan dan pilihan kebijakan yang lebih kuat. Itu adalah keputusan pemilik domain, bukan default yang tidak berbahaya untuk disalin dari halaman penyiapan. Pertahankan kebijakan yang ada hingga cakupannya, pengirim yang sah, dan perubahan yang dimaksudkan telah ditinjau. Memilih tujuan laporan memerlukan pembagian data dan tanggung jawab operasional; naskah ini tidak membuat catatan pelaporan atau mengizinkan pengiriman laporan ke penerima baru. String versi tetap v=DMARC1 di bawah standar saat ini, bukan versi kedua yang diciptakan.
RFC 9989 , bagian 4.4 menjelaskan keselarasan. Hasil SPF yang selaras atau hasil DKIM yang selaras dapat memenuhi kondisi autentikasi; standar ini tidak secara universal mengharuskan keduanya untuk lulus. Dua hasil kelulusan untuk domain yang tidak terkait tidak setara dengan penyelarasan. Jaga agar rekomendasi penyedia untuk mengkonfigurasi beberapa mekanisme terpisah dari aturan evaluasi normatif.
Tafsirkan cek produk secara sempit
Clever Elements mengatakan sistemnya mendeteksi apakah catatan telah diatur dengan benar dan menghapus pemberitahuan pengoptimalan dalam tampilan detail surat yang belum terkirim ketika pemeriksaan dipenuhi. Ini juga menjelaskan pemeriksaan domain pengirim yang digunakan di akun pengguna. Itu adalah pengamatan akun yang berguna, namun tidak menggantikan bukti penerima yang tepercaya untuk rute pengiriman surat yang sebenarnya. Pemberitahuan yang hilang bukan merupakan bukti penempatan kotak masuk atau keterlibatan penerima.
Artikel kepemilikan memberikan perkiraan pengakuan biasa dalam hitungan menit dan kemungkinan penundaan hingga 48 jam. Perlakukan hal tersebut sebagai panduan penyedia, bukan bukti bahwa nama atau nilai yang salah pada akhirnya akan berhasil. Latihan penerimaan yang diusulkan harus mempertahankan waktu observasi aktual dan status konfigurasi, kemudian menggunakan pesan tidak berbahaya yang diotorisasi secara terpisah untuk memeriksa hasil tanda tangan dan penyelarasan. Tidak ada pengiriman surat, peralihan akun, kueri DNS , atau unggahan diagnostik yang dilakukan di sini.
Diagnosis fiktif: DNS sudah siap tetapi penandatanganan tidak diaktifkan
Penerbit fiksi, Lantern Field Notes, menambahkan alias DKIM yang terdokumentasi dan kode TXT kepemilikan yang dikeluarkan akunnya. Editornya menandai otentikasi selesai karena kedua catatan terlihat di panel DNS . Peninjauan menemukan bahwa kontrol pengiriman DKIM belum diaktifkan dan tidak ada bukti penerima untuk domain pengirim yang dituju.
Koreksi yang diusulkan adalah memisahkan verifikasi kepemilikan, pencarian kunci, aktivasi penandatanganan, dan penerimaan pesan ke dalam item daftar periksa yang berbeda. Hal ini tidak berarti mengganti kunci publik atau memperketat DMARC dengan segera. Contoh ini fiktif dan tidak berisi informasi pelanggan nyata, hasil penyedia, atau pengujian yang dijalankan. Hal ini menggambarkan mengapa persiapan DNS saja tidak dapat membuat konfigurasi penandatanganan aktif.
Lembar kerja penerimaan kosong dan batas pelepasan
- Produk, penerapan akun saat ini, dan domain pengirim: ______
- Referensi kode TXT kepemilikan yang diterbitkan dan hasil verifikasi publik: ______
- Pemilik/target alias DKIM dan tinjauan ketergantungan data yang ada: ______
- Aktivasi pengiriman DKIM yang sah dan status akun yang diamati: ______
- Melengkapi kebijakan SPF dan mengevaluasi bukti ketergantungan: ______
- Keputusan DMARC saat ini, peninjauan persen lama dan persetujuan pelaporan: ______
- Hasil pemeriksaan akun dan bukti penyelarasan pesan yang diterima secara terpercaya: ______
- Pengecualian yang tersisa, pemilik rollback dan keputusan rilis: ______
Bukti implementasi asli, tinjauan materi pelajaran oleh manusia, penerapan sumber terkini, pengujian jalur produksi, aksesibilitas visual, dan pelepasan pemilik tetap terbuka. Persyaratan katalog yang lebih luas masih memerlukan bukti operasional resmi. Panduan ini tidak mengklaim bahwa akun live telah dikonfigurasi, bahwa contoh DMARC lama tetap terkini, atau bahwa email yang diautentikasi dijamin masuk ke kotak masuk.