Peningkatan tiba-tiba yang dilaporkan DMARC kegagalan adalah alasan untuk menyelidiki, bukan diagnosis. Hal ini dapat mencerminkan pengirim sah yang rusak, upaya peniruan identitas baru, perubahan cakupan penerima, atau penyerapan duplikat. Mulailah dengan melestarikan pengamatan dan mencari tahu penjelasan mana yang didukung oleh bukti.
Alur kerja di bawah ini memisahkan kualitas laporan, otorisasi pengirim, autentikasi, dan dampak bisnis. Ini tidak mengasumsikan akses ke konten pesan atau menjanjikan bahwa setiap kegagalan memiliki penyebab unik yang terlihat dalam data agregat.
Bekukan cuplikan kejadian yang berguna
Referensi: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Simpan interval pelaporan, organisasi penerima, pengidentifikasi laporan, domain kebijakan, dan jumlah catatan yang terpengaruh. Simpan laporan asli dalam kontrol akses dan retensi yang disetujui organisasi. Catat waktu penyerapan secara terpisah dari interval yang dijelaskan dalam laporan, karena kedatangan yang terlambat dapat menyebabkan lonjakan dasbor hari ini untuk lalu lintas yang terlihat sebelumnya.
Konfirmasikan bahwa percobaan ulang atau pemrosesan ulang laporan belum dihitung dua kali. Bandingkan jendela saat ini dan sebelumnya menggunakan cakupan yang setara. Catat apakah peringatan tersebut berarti lebih banyak pesan yang gagal, proporsi yang lebih tinggi, sumber baru, atau perubahan disposisi. Itu adalah pengamatan yang berbeda.
Pisahkan kelompok terkecil yang terkena dampak secara signifikan
Referensi: RFC 9990 §3.1.1.8, RFC 9990 §3.1.1.10, RFC 9990 §3.1.1.11.
Kelompokkan berdasarkan IP sumber yang dilaporkan, domain penulis, dievaluasi SPF Dan DKIM identitas, penerima, dan konfigurasi kebijakan jika tersedia. Pertahankan jumlah agregat pada masing-masing kelompok. Hindari mengubah satu baris laporan menjadi satu pesan atau memperlakukan nama pemilik infrastruktur sebagai bukti otorisasi pelanggan.
Periksa apakah kegagalan memengaruhi semua lalu lintas dari aplikasi yang dikenal atau hanya rute, penerima, atau irisan waktu. Cocokkan hasilnya dengan catatan penyebaran dan perubahan DNS . Stempel waktu yang umum mempersempit penyelidikan tetapi tidak membuktikan hubungan sebab dan akibat.
Pisahkan autentikasi dari penyelarasan
Referensi: RFC 9989 §5.3.5, RFC 6376 §6.1.2.
Periksa hasil SPF dan DKIM serta dampaknya penyelarasan dengan domain penulis. Hasil autentikasi yang lewat pada identitas layanan yang tidak terkait tidak menyediakan jalur yang selaras. Sebaliknya, jalur SPF yang gagal tidak membuat DMARC gagal saat diselaraskan tanda tangan DKIM berlalu.
Contoh kasus: permohonan faktur berubah menjadi tidak terkait jalur kembali sementara itu pemilih DKIM menunjuk ke kunci yang hilang. Asumsikan kebijakan valid yang berlaku, kunci absensi yang ditetapkan dan bukan batas waktu, tidak ada tanda tangan yang selaras, dan pemeriksaan SPF yang telah selesai. Kedua jalur yang selaras tidak tersedia dalam contoh ini, sehingga kegagalan yang diamati masuk akal. Perbaikan yang didukung adalah memulihkan konfigurasi penandatanganan atau amplop yang diinginkan setelah verifikasi, bukan menambahkan IP sembarangan hingga grafik berubah menjadi hijau. Ini adalah skenario diagnostik sintetik, bukan kejadian langsung.
Tetapkan otorisasi dan dampak
Mintalah pemilik aplikasi yang dikenal untuk mengonfirmasi rute dan volume yang diharapkan. Gunakan pesan yang diterima secara terkontrol, log pengiriman, dan bukti dampak pelanggan jika tersedia. Redaksi konten yang tidak perlu sebelum membagikan bukti. Jika tidak ada yang dapat menetapkan otorisasi, pertahankan klasifikasi sumber tidak dikenal daripada melegitimasi sumber melalui perubahan DNS .
Prioritaskan pengaturan ulang kata sandi, faktur, atau pemberitahuan penting yang terganggu menggunakan bukti dampak nyata. Sejumlah besar kegagalan yang tampaknya tidak sah dalam penegakan hukum mungkin memerlukan analisis penyalahgunaan, sementara kegagalan kecil yang sah mungkin memerlukan pemulihan layanan segera. Jaga agar alur kerja tersebut tetap berbeda.
Perbaiki penyebab yang didukung dan verifikasi
Buat perubahan resmi terkecil yang didukung oleh diagnosis. Pengembalian kebijakan di seluruh domain akan melemahkan penerapan email yang tidak terkait dan tidak boleh menjadi respons default terhadap grafik yang tidak dapat dijelaskan. Jika pengecualian sementara dapat dibenarkan, dokumentasikan cakupan, pemberi persetujuan, risiko, pemilik, dan masa berlakunya.
Kirim pesan terkontrol baru melalui rute yang terpengaruh dan periksa hasil autentikasi penerima tepercaya. Kemudian konfirmasikan bahwa laporan berikutnya yang sebanding mendukung pemulihan, sehingga memungkinkan terjadinya penundaan pelaporan. Tutup dengan penyebab, perubahan, bukti dan batas cakupan yang tersisa. Jika penyebabnya masih belum pasti, katakan demikian dan sebutkan pengujian berikutnya daripada mencatat dugaan perbaikan sebagai terbukti.
Mengikat kesimpulan dan tindakan selanjutnya
Untuk regresi faktur fiktif, dapatkan pemilih dan domain penandatanganan yang tepat, bukti pencarian resmi, dan hasil penerimaan tepercaya sebelum memilih perbaikan. Pengamatan tanpa kunci bukanlah bukti bahwa otorisasi IP yang tidak terkait memperbaiki pesan tersebut. Tidak ada pencarian DNS , perbaikan insiden, atau pengujian email yang dijalankan.