[ DMARC & kebijakan ]

Lindungi domain yang tidak terkirim tanpa menonaktifkan layanan email tersembunyi

Verifikasi bahwa domain benar-benar tidak mengirimkan email resmi, lalu menilai kebijakan autentikasi keluar dan konfigurasi penerimaan sebagai keputusan terpisah.

Oleh tim peneliti EmailAuth · 5 menit membaca

[Poin-poin penting]

  • Tidak ada kotak surat karyawan tidak membuktikan tidak ada pengiriman.
  • SPF , DMARC dan null MX memecahkan masalah yang berbeda.
  • Tinjau penerimaan dependensi secara terpisah dan pertahankan pemilik domain.
Di halaman ini

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.

[ Membawa pergi ]

Tidak ada kotak surat karyawan tidak membuktikan tidak ada pengiriman. SPF , DMARC dan null MX memecahkan masalah yang berbeda. Tinjau penerimaan dependensi secara terpisah dan pertahankan pemilik domain.

[ Berdasarkan peran ]

Apa artinya ini bagi Anda

Pilih peran Anda untuk langkah praktis selanjutnya.

Admin TI / Surat

Pisahkan ketiga keputusan DNS .

Verifikasi tidak ada pengiriman amplop resmi, nilai kebijakan Dari domain, dan putuskan secara independen apakah penerimaan harus dihentikan.

Langkah selanjutnya

  1. Tinjau kumpulan catatan yang ada.
  2. Verifikasi penemuan dan pengecualian subdomain.
  3. Gunakan tujuan laporan kerja di luar domain non-penerima.

CISO / Detik

Memerlukan bukti untuk klasifikasi tidak terkirim.

Pengendalian hanya akan sekuat inventaris dan kepemilikan yang berkelanjutan. Catat apa yang dinilai dan bagaimana penggunaan selanjutnya akan terdeteksi.

Langkah selanjutnya

  1. Menyetujui ruang lingkup dan perlakuan layanan yang sah.
  2. Melestarikan bukti perubahan dan pemulihan.
  3. Menilai kembali setelah akuisisi atau perubahan kepemilikan domain.

Pendiri / Non-teknis

Periksa ketergantungan bisnis sebelum menghentikan email.

Domain terparkir atau defensif masih dapat mendukung layanan outsourcing. Memerlukan konfirmasi dari pemilik aplikasi sebelum mengubah perannya.

Langkah selanjutnya

  1. Sertakan pembaruan dan pemberitahuan yang jarang terjadi.
  2. Periksa ketergantungan balasan dan alamat pemulihan.
  3. Pertahankan pemilik yang disebutkan namanya setelah pensiun.

[ FAQ ]

Pertanyaan yang sering diajukan

Apakah tidak adanya kotak surat membuktikan bahwa domain tidak mengirimkan surat?

Tidak. Aplikasi dan pemasok dapat menggunakan identitasnya tanpa kotak surat karyawan. Periksa konfigurasi aktual, alur kerja berkala, dan pemilik yang bertanggung jawab.

Apa yang dinyatakan oleh v=spf1 -all ?

Itu tidak memberikan izin pengiriman untuk identitas SPF yang dievaluasi. Konfirmasikan bahwa domain benar-benar tidak memiliki penggunaan resmi sebelum mengganti kebijakan valid yang ada.

RFC 7208 §5.1

Apakah SPF -all untuk melindungi domain Dari yang terlihat?

Tidak. SPF memeriksa identitas HELO dan MAIL FROM, bukan bidang Dari yang terlihat. Nilai penggunaan Dari-domain yang selaras dan kebijakan DMARC yang berlaku secara terpisah.

RFC 7208 §2.3 RFC 7208 §2.4 RFC 9989 §4.4.2

Apakah domain yang tidak mengirim masih dapat menerima email?

Ya. Mengirim dan menerima adalah fungsi yang terpisah. Pertahankan ketergantungan penerimaan, balasan, dan operasional kotak surat yang sah.

Apa yang dimaksud dengan MX nol?

Ini menyatakan bahwa domain tidak menerima email. RFC 7505 menetapkan satu MX dengan preferensi nol dan satu titik sebagai pertukaran, tanpa data MX lainnya.

RFC 7505 §3

Bisakah saya menggunakan null MX pada domain yang masih muncul di Dari?

RFC 7505 menyarankan agar pengaturan tersebut tidak dilakukan karena penerima dapat menolak email yang menggunakan domain tersebut. Tinjau dan migrasikan penggunaan identitas yang sah sebelum menerapkannya.

RFC 7505 §4.2

Ke mana laporan harus dikirim jika domain tidak menerima email?

Gunakan tujuan pengumpulan kerja yang disetujui di tempat lain, dengan izin eksternal dan pemeriksaan penyerapan yang diperlukan. Jangan berasumsi kotak surat lokal akan menerimanya.

RFC 9990 §4

Bukti apa yang mendukung penghentian penggunaan email domain?

Pertahankan tinjauan layanan dan pemilik, penanganan aliran dan subdomain yang tidak aktif, perubahan konfigurasi yang disetujui, jawaban yang dipublikasikan, dan proses untuk mendeteksi penggunaan baru.

[ Sumber ]

Sumber

  1. RFC 9989

    Bagian §4.10.1 · §4.4.2 · §4.7

  2. RFC 9990

    Bagian §4

  3. RFC 7208

    Bagian §2.3 · §2.4 · §4.6.2 · §5.1

  4. RFC 7505

    Bagian §3 · §4.2

[ Glosarium ]

Glosarium

Nol MX
Satu-satunya data MX dengan preferensi nol dan titik pertukaran, menyatakan bahwa domain tidak menerima email.

RFC 7505 §3

SPF -all
Semua mekanisme selalu cocok; pengembalian kualifikasi minus gagal saat dievaluasi.

RFC 7208 §4.6.2 RFC 7208 §5.1

Asal perusahaan

Mengapa lembaga keuangan dan pemerintah terkemuka menghentikan dasbor keamanan email mereka.

Platform autentikasi email tradisional menjual dasbor kepada Anda dan meminta teknisi Anda melakukan pekerjaannya. Di lingkungan berisiko tinggi, pengawasan manual berarti penegakan yang tertunda, penyimpangan konfigurasi, dan domain bayangan yang tidak dipantau.

EmailAuth adalah platform asal email agen. Agen kami menegakkan p=reject, jaga agar pengirim pihak ketiga tetap selaras dan pindahkan domain Anda ke kapasitas penuh RFC 9989 kepatuhan, standar DMARC baru, dengan kemampuan audit yang dapat dilakukan secara langsung oleh manusia.

Pemerintah Perusahaan besar Lembaga keuangan tingkat 1

SaaS · Penyewaan khusus · On-prem dengan celah udara · Enkripsi BYOK

Basis Pengetahuan