Pilih identitas pengirim sebelum mengedit DNS
Quentn menawarkan dua pilihan pengirim yang berbeda: alamat di domain yang dikontrol organisasi, atau alamat menggunakan domain Quentn. Panduan ini mencakup verifikasi domain milik organisasi dan menjelaskan perbedaan rute domain penyedia. Putuskan identitas mana yang terlihat yang harus digunakan kampanye sebelum menulis perubahan DNS . Akses ke kotak surat pribadi di layanan email publik tidak memberikan otoritas atas domain layanan tersebut.
Dalam alur kerja pengirim yang terdokumentasi, buka Email, lalu Pengirim, dan tambahkan email pengirim. Tipe Default ditujukan untuk domain yang dimiliki; menyimpan mengirimkan email konfirmasi alamat. Jenis domain Quentn malah menawarkan alamat domain penyedia dan menanyakan tujuan penerusan, yang harus dikonfirmasi. Ini adalah rute yang berbeda, bukan dua cara untuk menerbitkan catatan untuk penyedia kotak surat publik. Pengaturan pengirim Quentn
Catat alamat yang dipilih, jenis pengirim, pemilik kampanye, dan tujuan balasan. Mengubah default dapat memengaruhi identitas mana yang dipilih seseorang di kampanye mendatang, jadi periksalah kampanye yang sudah disiapkan daripada berasumsi bahwa setiap draf secara otomatis cocok dengan tujuan baru. Pertahankan tes balasan terkontrol dalam rencana penerimaan. Keberhasilan otentikasi tidak berarti bahwa balasan responden sampai ke tim yang mengharapkannya.
Pisahkan konfirmasi alamat dan verifikasi domain
Konfirmasi pengirim menetapkan kendali atas kotak masuk. Verifikasi domain adalah tugas DNS terpisah. Panduan verifikasi Quentn mengarahkan pengguna ke Email, Domain terverifikasi, lalu Buat domain. Setelah membuat domain, buka informasi verifikasinya, publikasikan entri DNS yang ditampilkan di host domain, dan periksa indikasi verifikasi yang dihasilkan. Gunakan catatan yang dikeluarkan rekening saat ini; panduan ini tidak memberikan satu set nilai universal untuk setiap instalasi. Verifikasi domain Quentn
Pemilik DNS harus terlebih dahulu mengonfirmasi yang mana server nama berwibawa. Zona yang terlihat di akun hosting lama mungkin tidak lagi melayani jawaban publik. Untuk setiap instruksi yang dihasilkan, catat jenis rekaman, nama lengkap pemilik, nilai target atau publik, dan nilai yang ada pada pemilik tersebut. Baca konvensi editor DNS untuk nama relatif sehingga tidak menambahkan domain dua kali.
Jangan menyimpulkan a catatan TXT atau pemilih dari nama file tangkapan layar. Jika penyewa mengeluarkan a CNAME, pertahankan targetnya dan periksa apakah tidak ada catatan yang tidak kompatibel yang menempati pemilik yang sama. Jika ia mengeluarkan data TXT , pertahankan nilai publik penuhnya. Tingkatkan tabrakan nama pemilik daripada menghapus catatan layanan yang ada agar verifikasi berhasil. Tiket perubahan harus mengidentifikasi layanan dan pemilik yang terkena dampak sebelum penggantian disetujui.
Panduan Quentn menyebut verifikasi domain opsional. Kata-kata tersebut tidak boleh diterjemahkan menjadi janji bahwa alamat Dari milik organisasi yang belum terverifikasi memenuhi persyaratan autentikasi penerima saat ini. Perlakukan itu sebagai deskripsi alur kerja produk yang terdokumentasi dan tetap memerlukan bukti pesan untuk identitas yang dimaksud. Verifikasi domain Quentn
Bangun SPF dari inventaris pengiriman sebenarnya
Pengenalan autentikasi Quentn memberi tahu pelanggan untuk memperhitungkan sistem lain, termasuk keanggotaan dan email situs web, sebelum mengubah kebijakan domain. Ini juga menunjukkan sebuah SPF contoh dan DMARC contoh. Contoh tersebut bukan pengganti konfigurasi yang dikeluarkan penyewa dan inventaris email organisasi yang sebenarnya. Pengenalan otentikasi Quentn
Cantumkan layanan kotak surat reguler, kampanye Quentn, pengiriman situs web, pengaturan ulang kata sandi, email penagihan, dan penggunaan lain yang diketahui dari domain Dari yang sama. Untuk masing-masingnya, identifikasikan rute SMTP aslinya. Publik sebuah situs web Sebuah rekor tidak membuktikan bahwa website mengirimkan email langsung dari alamat tersebut. Itu mungkin dikirimkan melalui penyedia yang berbeda. Mengotorisasi alamat situs web tanpa memeriksa rute dapat menambah izin yang tidak perlu dan membiarkan jalur email sebenarnya tidak diperbaiki.
SPF milik identitas SMTP yang dievaluasi oleh server penerima. Pertahankan satu kebijakan SPF pada pemilik tertentu, gabungkan hanya otorisasi yang diperlukan, dan evaluasi Batas pencarian DNS setelah perubahan. Jangan membuat rekaman v=spf1 kedua di samping rekaman yang sudah ada. Jangan berasumsi bahwa pass SPF untuk domain envelope yang dikontrol penyedia selaras dengan domain Dari milik organisasi yang terlihat. SPF RFC 7208
Catat apa yang ditambahkan, apa yang dipertahankan, dan alasannya. Jika instruksi SPF yang dikeluarkan penyedia tidak jelas atau berbeda dari contoh umum, dapatkan klarifikasi untuk akun tersebut sebelum dipublikasikan. Draf ini tidak menentukan nama host universal Quentn include.
Verifikasi DKIM dan DMARC pada kampanye sebenarnya
Gunakan pengujian terkontrol kecil yang mewakili rute kampanye produksi. Dari penilaian autentikasi tepercaya penerima, ambil domain Dari, domain amplop, DKIM menandatangani domain, pemilih, dan hasil. Itu tanda tangan DKIMNilai 'sd= dan s= mengidentifikasi pencarian kunci publik; pemindaian DNS umum yang menebak penyeleksi bukanlah bukti yang cukup. DKIM RFC 6376
Untuk DMARC , tentukan mekanisme passing mana yang selaras dengan domain Dari yang terlihat dan yang mana penyelarasan mode berlaku. Hasil SPF yang selaras atau tanda tangan DKIM yang selaras dapat memenuhi DMARC . Keberadaan tiga jenis catatan DNS saja tidak dapat memastikan bahwa pesan tertentu diautentikasi. Penyelarasan yang ketat harus diperiksa menggunakan domain sebenarnya, bukan asumsi bahwa setiap subdomain setara. DMARC RFC 9989
Pertahankan kebijakan DMARC yang ada saat menyelidiki kecuali pemilik domain resmi menyetujui perubahan. Kebijakan pemantauan dan kebijakan penegakan hukum memiliki tujuan yang berbeda. Jangan tempelkan contoh p=reject kebijakan ke dalam domain organisasi bersama sebelum memvalidasi rute yang sah. Tujuan pelaporan juga memerlukan pemilik, kontrol akses, dan peninjauan yang sesuai untuk data yang mungkin mereka terima.
Gunakan proses akses yang disetujui organisasi untuk pekerjaan DNS . Administrator dapat mempublikasikan catatan publik tanpa mengirimkan kata sandi host domain atau token sesi melalui email kepada siapa pun. Jauhkan rahasia dari tiket dukungan, tangkapan layar, dan bukti artikel. Percakapan dukungan penyedia harus dimulai dengan nama catatan aman, nilai publik, stempel waktu yang relevan, dan kesalahan sebenarnya.
Lembar kerja penerimaan Quentn
Berikut ini adalah lembar kerja yang diusulkan, bukan bukti pelanggan yang lengkap. Simpan entri terpisah untuk pengiriman domain milik dan domain Quentn.
- Pilihan identitas: jenis pengirim, alamat yang terlihat, kampanye, pemilik bisnis, tujuan balasan, dan apakah pilihan default berubah.
- Kontrol alamat: penerima konfirmasi, status penyelesaian, dan hasil tes balasan, tanpa menyimpan tautan konfirmasi.
- Kontrol domain: domain yang dimasukkan, pemilik DNS otoritatif, instruksi penyewa saat ini, dan status verifikasi.
- DNS Publik : setiap pemilik yang dihasilkan, jenis, nilai atau target, status sebelumnya, TTL, waktu kueri, dan jawaban yang diamati.
- Pengirim lainnya: kotak surat, situs web, keanggotaan, transaksional, dan rute lainnya yang menggunakan domain.
- Kampanye yang diterima: pengidentifikasi pengujian aman, penerima, stempel waktu, Dari, domain amplop, DKIM d= dan s=, dan hasil autentikasi tepercaya.
- Penerimaan: mekanisme yang selaras, rute yang belum teruji, pertanyaan dukungan, pemilik rollback, dan status persetujuan manusia.
Diagnosis fiktif dari surat yang dikonfirmasi tetapi tidak diautentikasi
Contoh ini fiktif. Pemilik kampanye mengonfirmasi kotak masuk pengirim baru dan melihat alamat yang tersedia di Quentn. Tes mencapai penerima dengan hasil DMARC yang gagal. Tim awalnya menganggap email konfirmasi telah menyelesaikan otentikasi.
Investigasi memisahkan konfirmasi alamat dari verifikasi domain. Administrator DNS menemukan bahwa catatan ditambahkan ke zona hosting yang tidak aktif, sementara zona otoritatif masih kekurangan konfigurasi publik yang diperlukan. Perbaikan yang diusulkan adalah mempublikasikan nilai yang dikeluarkan akun saat ini di host aktif, memeriksa status verifikasi Quentn, dan mengulangi tes kampanye yang sama. Tes balasan juga diulangi karena identitas pengirim yang benar tidak memvalidasi perutean balasan. Skenario ini mencatat metode diagnostik, bukan kejadian yang diamati.
Ruang lingkup memegang dan meninjau gerbang
Tidak ada akun Quentn aktif, set DNS yang dikeluarkan, zona pelanggan, atau kampanye yang diterima yang diperiksa. Jenis catatan yang tepat, target, nilai pemilih, dan perilaku penandatanganan tetap menjadi persyaratan bukti khusus akun. Kandidat dengan sengaja menghindari penyertaan SPF universal dan tidak menerapkan instruksi pembagian kredensial yang tidak aman dari sumbernya. Tinjauan UKM manusia, tinjauan pembaca visual, tes otentikasi langsung, dan persetujuan publikasi masih menunggu keputusan.
Tandai hal-hal yang tidak diketahui dalam kasus fiksi
Dalam kasus zona tidak aktif fiktif, kegagalan DMARC kampanye merupakan masukan yang diasumsikan. Hasil pasti SPF dan DKIM , penyeleksi penandatanganan, dan catatan yang dikeluarkan penyewa sengaja tidak ditentukan. Jangan jadikan skenario itu menjadi klaim bahwa pemilih Quentn tertentu gagal. Bukti berikutnya adalah kumpulan catatan yang dikeluarkan saat ini, tanggapan resmi, dan hasil penerima baru, yang dikumpulkan oleh pemilik resmi.
Pisahkan penerimaan pesan dari peluncuran kebijakan
Hasil SPF yang selaras dapat memenuhi evaluasi pesan, namun tidak hanya membenarkan pemindahan seluruh domain untuk ditolak. RFC 9989 Bagian 7.4 memerlukan DKIM yang valid untuk penerbitan domain p=reject dan memperingatkan tentang interoperabilitas email tidak langsung. Inventarisasi semua pengirim yang sah dan rute tidak langsung sebelum pemilik kebijakan menyetujui penerapannya. Tidak ada perubahan DNS , operasi penyewa, atau pengujian pesan yang diterima yang dijalankan untuk artikel ini.