Sebuah domain tidak boleh memiliki kotak surat karyawan dan tetap mengirimkan faktur, pemberitahuan situs web, atau pesan pemasok. Tetapkan penggunaan sebenarnya sebelum mendeklarasikannya a domain tidak mengirim.
Setelah bukti tersebut tersedia, konfigurasikan kontrol untuk tujuan masing-masing. SPF menjelaskan pengiriman amplop resmi, DMARC alamat selaras dengan penggunaan domain Dari yang terlihat, dan MX nol menyatakan bahwa domain tersebut tidak menerima email. Itu adalah keputusan yang berkaitan, bukan catatan yang dapat dipertukarkan.
Periksa penggunaan yang sah dan tidak aktif
Tinjau aplikasi bisnis, formulir web, sistem yang diperoleh, kampanye yang dialihdayakan, dan pemberitahuan berkala. Tanyakan apakah domain muncul di alamat Dari, alamat pengirim amplop, penanganan balasan, atau tujuan pelaporan yang terlihat.
Periksa subdomain secara terpisah. Domain induk yang tidak mengirimkan tidak menetapkan bahwa setiap anak memiliki tujuan yang sama, dan layanan pengirim anak dapat memiliki konfigurasinya sendiri.
Gabungkan data yang diamati dengan konfirmasi pemilik dan bukti konfigurasi. Jendela pelaporan yang tenang merupakan konteks yang berguna namun tidak dapat membuktikan bahwa alur kerja tahunan atau tidak aktif tidak ada.
Jadikan deklarasi pengiriman eksplisit
Untuk domain yang benar-benar diotorisasi untuk tidak mengirim email, ilustrasi kebijakan SPF di domain tersebut adalah:
v=spf1 -all
Di bawah RFC 7208 §4.6.2 Dan RFC 7208 §5.1, ini tidak memberikan izin pengiriman untuk identitas SPF yang dievaluasi. Ini bukan merupakan instruksi untuk menambahkan kebijakan SPF kedua selain yang sudah ada. Selidiki dan ganti izin usang melalui perubahan yang disetujui.
Pemeriksaan SPF HELO Dan KIRIM DARI identitas sebagaimana ditentukan dalam RFC 7208 §2.3 Dan RFC 7208 §2.4. Dengan sendirinya, hal ini tidak mencegah layanan yang tidak terkait menempatkan domain di alamat Dari yang terlihat. Pertimbangkan kebijakan DMARC yang berlaku sebagai bagian terpisah dari rencana tersebut.
Menilai kebijakan DMARC untuk domain tersebut
Setelah mengonfirmasi bahwa tidak ada aliran Dari-domain sah yang akan terganggu oleh perubahan tersebut, contoh domain non-pengiriman tercakup di _dmarc.example.com adalah:
v=DMARC1; p=reject
Ini adalah kebijakan ilustratif untuk tujuan yang disebutkan, bukan templat untuk domain korespondensi staf. Konfirmasikan penemuan yang berlaku dan perilaku subdomain di bawah RFC 9989 §4.10.1 Dan RFC 9989 §4.7, dan mempertahankan perbedaan interoperabilitas tujuan umum.
Jika laporan diminta, gunakan alamat pengumpulan yang benar-benar menerima surat. Domain yang dikonfigurasi untuk tidak menerima email juga tidak dapat diasumsikan menerima kotak pesan pelaporannya sendiri. Di bawah RFC 9990 §4, tujuan eksternal memerlukan izin pelaporan dan pemeriksaan pengumpulan yang relevan.
Putuskan apakah domain juga tidak menerima email
Domain yang tidak terkirim masih dapat menerima email. Jangan menghapus rute penerimaan yang sah hanya karena tidak ditemukan penggunaan keluar.
Jika keputusan terpisahnya adalah domain tidak menerima email, RFC 7505 §3 mendefinisikan MX nol. Dalam notasi file master DNS , data pertukarannya adalah:
0 .
Itu harus menjadi satu-satunya catatan MX untuk domain itu. Titik terakhir mewakili pertukaran nol, bukan nama host server yang akan dibuat. Ikuti model masukan editor DNS dan verifikasi jawaban yang dipublikasikan.
Di bawah RFC 7505 §4.2, domain TIDAK BOLEH mempublikasikan null MX ketika digunakan dalam SMTP MAIL FROM atau alamat Dari yang terlihat karena penerima dapat menolak email mereka. Periksa kegunaannya sebelum dipublikasikan.
Kerjakan contoh layanan tersembunyi
Dalam contoh sintetis ini, domain merek terparkir tidak memiliki kotak surat, namun aplikasi pembaruan yang dialihdayakan masih menggunakannya di Dari dan mengharapkan balasan di domain tersebut.
Menerbitkan kontrol yang tidak dikirim dengan segera dapat mengganggu alur kerja tersebut. Tim pertama-tama mengidentifikasi pemilik layanan dan memutuskan apakah akan memigrasikan identitas, mempertahankan fungsi email yang sah, atau menghentikan aplikasi.
Hanya dengan demikian, domain tersebut dapat mendokumentasikan bahwa domain lama tidak memiliki sisa pengiriman resmi dan, jika berlaku, tidak ada persyaratan penerimaan. Bukti mengubah klasifikasi; tidak adanya kotak surat pada awalnya tidak menyelesaikannya.
Verifikasi keadaan akhir dan pertahankan pemiliknya
Simpan catatan sebelumnya dan keputusan tujuan domain yang disetujui. Verifikasi SPF resmi, DMARC yang berlaku, dan konfigurasi penerimaan secara independen. Catat cakupan subdomain yang ditinjau dan pengecualiannya.
Lanjutkan memeriksa penggunaan yang tidak terduga, perubahan kepemilikan, dan layanan yang baru diperkenalkan. Konfigurasi untuk domain yang tidak digunakan memerlukan seseorang yang bertanggung jawab untuk memperhatikan kapan domain tersebut digunakan.
Menggunakan inventaris pengirim untuk membangun ketergantungan dan pemilihan kebijakan untuk domain dengan email sah yang aktif.
Catat keputusan dan batasannya
Dalam skenario perpanjangan tersembunyi, tahan klasifikasi tidak mengirim dan keputusan tidak menerima hingga pemilik menyelesaikan identitas Dari yang aktif dan balasan yang diharapkan. Setelah migrasi, verifikasi rute pengganti sebelum menghentikan rute lama. MX null tidak mempublikasikan kebijakan SPF atau DMARC ; kebijakan penolakan tidak menjamin bahwa setiap penerima menolak. Contoh-contoh ini tidak mengizinkan perubahan dan mengklaim tidak ada kueri yang dieksekusi.