Sebuah domain bisa menjadi domain baru bagi organisasi Anda tanpa harus bebas dari ketergantungan email. Pendaftaran baru dapat digunakan oleh situs web baru, sedangkan nama yang diperoleh atau didaftarkan ulang mungkin memiliki aplikasi warisan, aturan penerusan, atau harapan yang belum ditemukan oleh pemilik baru.
Yang pertama bermanfaat DMARC oleh karena itu keputusan adalah keputusan yang bertujuan. Tetapkan siapa yang mengontrol domain, apa yang akan dikirim, apa yang akan diterima, dan siapa yang dapat menyetujui perubahan. Kemudian konfigurasikan dan verifikasi catatan yang relevan untuk cakupan tersebut.
Buat daftar tujuan kecil
Perlakukan domain sebagai aset dengan pemilik yang bertanggung jawab. Catat akun registrar, penyedia DNS resmi, kontak perpanjangan, pemberi persetujuan perubahan, dan tujuan penggunaan. Akses administratif harus tetap bertahan setelah kepergian staf.
Tetap mengirim dan menerima sebagai dua bidang terpisah:
- Tujuan penggunaan: Hanya situs web; Mengirim pertanyaan: Bisakah formulir, alat pendukung, atau aplikasi apa pun dikirim menggunakan domain ini?; Menerima pertanyaan: Apakah pelanggan atau layanan memerlukan alamat di sini?
- Tujuan penggunaan: Surat produk transaksional; Mengirim pertanyaan: Akun aplikasi dan rute pemulihan mana yang dikirim?; Menerima pertanyaan: Kemana perginya balasan, kegagalan pengiriman, dan permintaan dukungan?
- Tujuan penggunaan: Surat karyawan; Mengirim pertanyaan: Pengguna, delegasi, dan alat terhubung mana yang mengirim?; Menerima pertanyaan: Kotak surat, alias, dan jalur penerusan manakah yang ada?
- Tujuan penggunaan: Registrasi defensif; Pertanyaan pengiriman: Apakah organisasi menyetujui pengiriman apa pun?; Menerima pertanyaan: Apakah ada layanan masuk yang diperlukan?
Register yang disarankan ini membuat asumsi tersembunyi terlihat. “Tidak ada kotak surat karyawan” tidak berarti bahwa suatu domain tidak mengirimkan apa pun.
Periksa ketergantungan email yang kurang jelas
Sebelum mendeklarasikan domain tidak terkirim, periksa formulir situs web, alat pemantauan, pengaturan e-niaga, sistem faktur, penyedia identitas, dan platform dukungan. Tanyakan apakah mereka menggunakan domain sebagai Dari yang terlihat, alamat pengirim amplop atau a DKIM penandatanganan domain.
Untuk domain yang diakuisisi, sertakan pemilik kontrak dan aplikasi dari serah terima akuisisi. Snapshot DNS mencatat apa yang dipublikasikan sekarang; itu tidak membuktikan tidak adanya aplikasi yang tidak aktif atau pesan yang dijadwalkan untuk bulan depan.
Menggunakan inventaris pengirim untuk melampirkan setiap penggunaan yang ditemukan ke akun dan pemilik yang disebutkan. Pertahankan pemeriksaan yang belum terjawab sebagai temuan terbuka daripada mengubah keheningan menjadi persetujuan.
Verifikasi di mana sebenarnya perubahan DNS berada
Konfirmasikan server resmi dan nama pemilik yang sepenuhnya memenuhi syarat sebelum dipublikasikan. Akun registrar dan akun hosting DNS bisa berbeda sistem. Delegasi subdomain dapat memindahkan bagian tertentu dari pohon nama ke otoritas lain.
Untuk domain pengirim baru, ikuti konfigurasi yang dihasilkan platform untuk akun sebenarnya. Menerbitkan kunci DKIM atau catatan delegasi bukan merupakan bukti bahwa layanan telah mulai ditandatangani; RFC 6376 §3.6.2.1 Dan RFC 6376 §5 pengambilan kunci dan penandatanganan secara terpisah. Kirim pesan terkontrol melalui rute yang dituju dan periksa verifikasi tepercaya yang diterima dan penyelarasan.
Di bawah RFC 9989 §4.5, kebijakan DMARC dipublikasikan dengan nama _dmarc yang berlaku. Nilai yang ditempatkan pada akar domain tidak menggantikan nama pemilik tersebut. Alur kerja publikasi menghubungkan verifikasi DNS dengan bukti pesan dan pelaporan.
Pilih cabang yang benar untuk domain non-pengiriman
Sungguh domain tidak mengirim dapat menerbitkan kebijakan yang menyatakan preferensi penanganan pemilik terhadap penggunaan domain Dari tanpa izin. Kebijakan DMARC yang bersifat restriktif adalah keputusan cakupan yang masih bergantung pada implementasi dan analisis penerima.
SPF dan layanan masuk memerlukan keputusan terpisah. Di bawah RFC 7208 §5.1 Dan RFC 7208 §4.6.2, sebuah ilustrasi v=spf1 -all kebijakan menyatakan bahwa tidak ada sumber yang diberi wewenang oleh kebijakan SPF tersebut untuk domain yang dievaluasi. Itu tidak dengan sendirinya menjelaskan setiap kemungkinan subdomain atau memblokir email masuk.
Deklarasi null MX berkaitan dengan penerimaan. RFC 7505 §3 mendefinisikannya sebagai satu-satunya catatan MX, dengan preferensi nol dan menargetkan satu titik, untuk domain yang tidak menerima email. Panduan di RFC 7505 §4.2 mengatakan domain yang digunakan di KIRIM DARI atau alamat Dari yang terlihat tidak boleh dipublikasikan null MX . Jangan menerapkannya hanya karena domain tersebut tidak memiliki inbox biasa.
Menggunakan panduan domain non-pengiriman sebelum menggabungkan kontrol ini. Mereka mengungkapkan niat yang berbeda dan harus setuju dengan penggunaan sebenarnya.
Bekerja melalui domain produk baru fiktif
Misalkan sebuah perusahaan mendaftarkan domain produk. Daftar periksa peluncurannya memberi label nama “hanya situs web”, tetapi tiga pemeriksaan mengungkapkan kegunaan lain:
- Penemuan: Layanan pengaturan ulang kata sandi akan menggunakan domain produk di Dari; Konsekuensi: Nama tersebut adalah domain pengirim
- Penemuan: Balasan harus sampai ke alamat dukungan; Konsekuensi: Diperlukan rute masuk
- Penemuan: Wilayah aplikasi pencadangan menggunakan akun penyedia terpisah; Konsekuensi: Akun tersebut memerlukan konfigurasi dan bukti pesannya sendiri
Langkah selanjutnya yang benar adalah merevisi register tujuan, mengkonfigurasi rute yang disetujui dan memverifikasinya. Menerapkan kumpulan rekaman non-pengiriman akan bertentangan dengan layanan yang direncanakan.
Nama pertahanan terpisah mungkin sebenarnya tidak disetujui untuk digunakan dalam pengiriman atau penerimaan. Pemiliknya dapat memilih kontrol untuk tujuan berbeda tersebut dan mendokumentasikan pemeriksaan yang mendukung klasifikasi tersebut.
Jadikan pelaporan sebagai jalur operasional yang berfungsi
Jika pelaporan gabungan diminta, verifikasi tujuan dan otorisasi tujuan eksternal yang diperlukan berdasarkan RFC 9990 §4. Putuskan siapa yang akan meninjau laporan dan bagaimana lalu lintas tak terduga akan diselidiki. Alamat pelaporan tidak berguna hanya karena muncul dalam nilai TXT .
Domain baru mungkin menghasilkan sedikit lalu lintas yang sah. Di bawah RFC 9990 §3.1 Dan RFC 9989 §5.3.8, koleksi yang kosong mungkin tidak mencerminkan surat yang diamati, partisipasi penerima, atau masalah pengumpulan. Gunakan tes terkontrol dan pemeriksaan koleksi untuk membedakan kemungkinan-kemungkinan tersebut.
Jaga privasi dan akses pelaporan tetap proporsional dengan tujuannya. Panduan privasi pelaporan menjelaskan bagaimana menilai data yang dikumpulkan.
Tinjau perubahan tujuan sebelum mengaktifkan layanan baru
Konfigurasi awal tidak boleh menjadi kendala yang bisa dilewati oleh tim. Ketika sebuah domain memperoleh email karyawan, penggunaan transaksional, atau subdomain baru, memerlukan pembaruan tujuan dan otentikasi serta tinjauan penerimaan yang sesuai.
Partisipasi penuh DMARC saat ini memerlukan lebih dari satu pesan yang disampaikan: Persyaratan dalam RFC 9989 §8 mencakup penyelarasan SPF dan DKIM , pelaporan dan publikasi kebijakan. Domain karyawan tujuan umum juga memerlukan penilaian interoperabilitas RFC 9989 §7.4 sebelum memilih menolak.
Hasil yang tahan lama adalah domain yang pemilik, tujuan, dan catatannya selaras. Tinjau perjanjian tersebut ketika peran bisnis domain berubah, daripada berasumsi bahwa label hari pertama tetap akurat selamanya.
Jaga agar tindakan selanjutnya tetap spesifik
Perlengkapan domain produk memerlukan rute pengiriman dan jalur balasan yang disetujui, sehingga label khusus situs webnya harus diubah sebelum memilih kontrol non-pengiriman. Akun cadangan tetap menjadi tugas verifikasi tersendiri. Preferensi penanganan Null MX , SPF -all dan DMARC bukanlah saklar yang dapat dipertukarkan. Ini adalah konsekuensi perencanaan, bukan catatan yang diimplementasikan atau penilaian akuisisi yang sebenarnya.