[ Laporan & investigasi ]

Mengapa tingkat kelulusan DMARC yang tinggi dapat menyembunyikan layanan sah yang gagal

Temukan kegagalan sah bervolume rendah yang hilang dalam tingkat kelulusan agregat yang tinggi.

Oleh tim peneliti EmailAuth

[Poin-poin penting]

  • Gunakan hasil yang selaras dengan penghitungan dan pembobotan untuk populasi yang diamati.
  • Tinjau layanan penting yang terverifikasi secara terpisah dari volume judul.
  • Kesenjangan pelaporan bukanlah layanan kelulusan otomatis.
Di halaman ini

Secara keseluruhan tinggi DMARC tingkat kelulusan dapat hidup berdampingan dengan layanan penting bisnis yang rusak. Aliran yang lebih besar mendominasi aritmatika, sedangkan aliran yang lebih kecil mungkin membawa pengaturan ulang kata sandi, faktur, atau peringatan penting. Tinjau layanan sah yang diketahui secara terpisah sebelum menggunakan tarif utama untuk menyetujui perubahan.

Tentukan apa yang lolos

Referensi: RFC 9989 §5.3.5, RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.8, RFC 9989 §5.4.

Gunakan hasil selaras yang dievaluasi DMARC, bukan hasil mentah SPF atau DKIM sukses sendirian. Dengan kebijakan valid yang berlaku dan pemeriksaan yang telah selesai, meneruskan satu mekanisme yang selaras sudah cukup untuk lolos DMARC tingkat pesan; membutuhkan keduanya menciptakan metrik yang berbeda. Disposisi terpisah: pesan dapat ditangani di bawah pengecualian penerima tanpa menjadi izin otentikasi.

Beri bobot pada baris berdasarkan jumlah pesannya. Satu baris sehat yang mewakili ribuan observasi dan baris gagal yang mewakili sepuluh bukanlah populasi yang berukuran sama. Beri label tarif yang berlaku untuk observasi yang dikumpulkan, bukan setiap pesan yang dikirim.

Pisahkan inventaris pengiriman yang disetujui

Memetakan identitas yang diamati ke layanan menggunakan konfigurasi penyedia, rute yang diketahui, dan sampel pesan resmi. IP sumber dengan sendirinya dapat dibagikan atau mewakili penerus. Pertahankan lalu lintas yang tidak diklasifikasikan daripada menetapkan kepemilikan hanya dengan menebak-nebak.

Untuk setiap layanan penting, catat volume yang diamati, jumlah kelulusan dan kegagalan yang selaras, cakupan penerima, dan hasil pengujian terbaru. Pisahkan lalu lintas yang tidak diketahui dan dicurigai tidak sah dari kelompok sah yang terverifikasi. Perubahan klasifikasi harus diberi tanggal sehingga peningkatan angka tidak bisa diam-diam dihasilkan dari pengecualian data yang tidak sesuai.

Periksa aliran kecilnya

Contoh kasus: layanan pemasaran memiliki 99.900 pengamatan yang berhasil dan layanan pengaturan ulang kata sandi memiliki 100 pengamatan yang gagal. Tingkat kelulusan gabungan adalah 99,9 persen, sedangkan tingkat kelulusan pengaturan ulang kata sandi yang diamati adalah nol. Tingkat agregat benar secara matematis tetapi secara operasional tidak lengkap.

Hal ini tidak membuktikan bahwa setiap pengaturan ulang kata sandi ditolak atau bahwa semua pesan dari layanan tersebut sampai ke penerima pelaporan. Hal ini membenarkan penyelidikan tingkat rute segera. Periksa pesan mentah saat ini, identitas yang selaras, pengaturan penyedia, dan gateway yang relevan daripada merayakan persentase keseluruhan.

Tetapkan gerbang pengambilan keputusan seputar dampak

Gunakan tarif utama untuk konteksnya, lalu mintalah bukti untuk layanan penting sebelum memperketat kebijakan. Layanan bervolume rendah tanpa observasi memerlukan pengujian atau kesenjangan yang terdokumentasi, bukan asumsi kelulusan. Prioritaskan remediasi berdasarkan dampak bisnis, keyakinan legitimasi, dan bukti kegagalan saat ini.

Tutup masalah layanan dengan pengujian menyeluruh yang baru dan observasi laporan berikutnya jika tersedia. Simpan metrik total dan tampilan layanan dalam laporan pengoperasian. Ringkasan yang berguna membuat pengecualian penting terlihat alih-alih membiarkan volume sehat menyembunyikannya.

Buatlah pengecualian terlihat dalam tinjauan operasi

Cantumkan setiap layanan penting beserta pemiliknya, identitas yang diharapkan, kegagalan yang diamati, dan status penyelidikan saat ini. Tampilkan hitungan meskipun pembulatan akan membuat keseluruhan bagan terlihat sempurna. Sertakan tes terkontrol terbaru yang berhasil dan rute apa pun yang tidak dilakukan. Pemilik harus secara eksplisit menerima kesenjangan yang tersisa daripada membiarkan layanan yang tidak terklasifikasi menghilang dari peninjauan. Periksa setelah pengirim atau templat berubah, karena sampel yang lewat sebelumnya tidak menetapkan bahwa rute yang baru diubah masih rambu dan sejajar dengan benar.

Lanjutkan penyelidikan

Gunakan panduan laporan agregat untuk menafsirkan bidang yang mendasarinya dan panduan diagnosis keselarasan ketika pass otentikasi mentah tidak memenuhi DMARC .

Jaga agar keputusan tetap terbatas

Penghitungan lokal menghasilkan 99.900/100.000 = 99,9% kelulusan keseluruhan dan 0/100 = 0% untuk kelompok hipotetis pengaturan ulang kata sandi. Keputusan yang harus segera diambil adalah menyelidiki jalur kritis tersebut, bukan menyimpulkan penolakan terhadap 100 pesan tersebut. Ini adalah penghitungan pengajaran yang diciptakan, bukan telemetri pelanggan.

[ Membawa pergi ]

Gunakan hasil yang selaras dengan penghitungan dan pembobotan untuk populasi yang diamati. Tinjau layanan penting yang terverifikasi secara terpisah dari volume judul. Kesenjangan pelaporan bukanlah layanan kelulusan otomatis.

[ Berdasarkan peran ]

Apa artinya ini bagi Anda

Pilih peran Anda untuk langkah praktis selanjutnya.

Admin TI / Surat

Hitung tarif hitungan tertimbang yang selaras.

Pertahankan observasi mendasar dan gunakan alur kerja di atas untuk memisahkan tahap kegagalan aktual dari asumsi.

Langkah selanjutnya

  1. Hitung tarif hitungan tertimbang yang selaras.
  2. Verifikasi kepemilikan layanan.
  3. Uji ulang rute spesifik yang gagal.

CISO / Detik

Memerlukan gerbang perubahan tingkat layanan.

Pertahankan cakupan, asal usul, dan ketidakpastian yang tersisa sebelum mengandalkan temuan ini untuk mengambil keputusan keamanan.

Langkah selanjutnya

  1. Memerlukan gerbang perubahan tingkat layanan.
  2. Pisahkan lalu lintas yang tidak diketahui.
  3. Tinjau perubahan klasifikasi dan cakupan.

Pendiri / Non-teknis

Sebutkan layanan penting bervolume rendah.

Hubungkan tugas pelaporan ini dengan keputusan bisnis yang dimiliki dan mintalah bukti yang sebanding dengan dampaknya.

Langkah selanjutnya

  1. Sebutkan layanan penting bervolume rendah.
  2. Tinjau pengecualian di samping tarif judul.
  3. Prioritaskan kegagalan yang berdampak pada pelanggan.

[ FAQ ]

Pertanyaan yang sering diajukan

Apakah kelulusan 99,9 persen masih menyembunyikan masalah serius?

Ya. Aliran kecil yang kritis dapat gagal sementara aliran sehat yang besar mendominasi keseluruhan.

Haruskah SPF dan DKIM lulus untuk DMARC ?

Tidak. Mekanisme SPF atau DKIM yang selaras sudah cukup.

RFC 9989 §5.3.5

Apakah pass DKIM mentah masih bisa gagal diselaraskan?

Ya. Domain penandatanganan harus selaras dengan domain penulis dalam mode yang berlaku.

RFC 9989 §4.4.1

Apakah jumlah kegagalan membuktikan bahwa pesan ditolak?

Tidak. Hasil otentikasi dan penanganan penerima adalah pengamatan yang berbeda.

RFC 9989 §5.4

Haruskah memberi tarif rata-rata pada baris secara merata?

Tidak. Bobot menurut jumlah baris untuk tingkat pengamatan pesan.

RFC 9990 §3.1.1.8

Bisakah IP sumber saja menetapkan pemilik layanan?

Tidak dapat diandalkan. Konfirmasikan dengan konfigurasi dan bukti pesan.

Bagaimana seharusnya layanan penting tanpa data muncul?

Sebagai kesenjangan cakupan yang memerlukan bukti, bukan izin otomatis.

Apa yang membuktikan perbaikan layanan?

Uji rute terkendali saat ini dan pengamatan pendukung selanjutnya, dengan batasan cakupan yang dinyatakan.

[ Sumber ]

Sumber

  1. RFC 9989

    Bagian §4.4.1 · §5.3.5 · §5.4

  2. RFC 9990

    Bagian §3.1.1.8 · §3.1.1.9

[ Glosarium ]

Glosarium

Hitung bobot
Memberi bobot pada setiap baris laporan yang disertakan berdasarkan jumlah pengamatan pesan yang diwakilinya.

RFC 9990 §3.1.1.8

Kelompok layanan kritis
Pengelompokan operasional rute terverifikasi yang dampak bisnisnya perlu ditinjau secara individual, berapa pun volumenya.

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