Permintaan rua yang diterbitkan tidak menghasilkan sensus lengkap untuk setiap tujuan. Penerima mungkin tidak berpartisipasi dalam pelaporan, mungkin tidak memiliki observasi yang relevan, atau mungkin menghadapi masalah pembangkitan atau penyampaian. Perlakukan reporter yang tidak hadir sebagai pertanyaan investigasi, bukan bukti tidak adanya surat atau penyalahgunaan.
Tentukan populasi penerima yang diharapkan
Mulailah dengan mengirimkan log dan tujuan terverifikasi untuk interval yang ditinjau. Kelompokkan berdasarkan infrastruktur penerima aktual yang diketahui; domain penerima dan identitas pembuat laporan tidak perlu memiliki hubungan satu-ke-satu. Hosting email dan gateway yang dialihdayakan dapat membuat daftar reporter berbasis merek menyesatkan.
Catat hal-hal yang mendukung setiap ekspektasi: laporan sebelumnya, dokumentasi pihak pertama saat ini, pengiriman terkendali, atau log pengirim. Pisahkan asumsi. Jangan menciptakan jadwal atau kemampuan pelaporan penyedia dari perilaku penyedia lain.
Singkirkan cacat permintaan dan pengumpulan
Referensi: RFC 9990 §4, RFC 9990 §3.5.
Verifikasi kebijakan yang berlaku dan rua tujuan, maka diperlukan otorisasi eksternal. Periksa log kotak surat penerimaan, karantina, dan kegagalan parser. Jika laporan sampai ke pengumpul tetapi tidak ditampilkan, penerima akan melaporkan; kesenjangannya adalah pada proses pengumpulan.
Pesan baru yang dikontrol ke kotak surat percobaan yang menyetujui dapat menetapkan bahwa jalur tertentu menerima surat. Hasil autentikasi tepercayanya membantu mendiagnosis pesan tersebut, namun tidak membuktikan bahwa laporan agregat akan dihasilkan atau tiba pada waktu yang terjamin.
Klasifikasikan ketidakpastian dengan jujur
Referensi: RFC 9990 §3.1, RFC 9989 §5.3.8.
Gunakan status berbeda seperti pelaporan sebelumnya tetapi terlambat, permintaan tidak valid, pengiriman ditolak, penguraian gagal, dan partisipasi belum dikonfirmasi. Hal ini mencegah tim yang berbeda memperlakukan setiap entri yang hilang sebagai pemadaman yang sama. RFC 9990 menggambarkan umpan balik harian atau lebih sering, namun cakupan praktisnya masih bergantung pada sistem partisipasi aktual dan pengumpulan yang berhasil.
Contoh kasus: laporan datang dari penerima A dan B, sedangkan log pengirim juga menunjukkan surat yang diterima di C. Tidak ada laporan dari C. Tanpa bukti lebih lanjut, klasifikasikan C sebagai tidak teramati dalam pelaporan agregat. Jangan menetapkan tingkat kegagalan nol pada C atau menyimpulkan implementasi kebijakannya dari laporan A.
Buat keputusan dengan bukti yang ada
Prioritaskan cakupan yang hilang untuk arus kritis, perubahan infrastruktur terkini, dan penerima yang sebelumnya memberikan kontribusi yang andal. Gunakan log pengirim, sampel pesan resmi, dan diagnostik pengiriman untuk melengkapi laporan. Jangan berulang kali mengubah catatan yang valid hanya untuk memunculkan pelapor yang belum dikonfirmasi.
Publikasikan temuan yang diamati dan batasan cakupannya. Jika ketidakhadiran penerima berdampak signifikan terhadap keputusan penegakan hukum, dapatkan bukti yang lebih baik mengenai jalur tersebut atau dokumentasikan ketidakpastian yang tersisa dan pemilik keputusan. Hasilnya harus berupa peta bukti yang dapat dipertahankan dan bukan janji bahwa setiap penyedia kotak surat terwakili.
Pertahankan daftar reporter yang diharapkan
Untuk setiap penerima yang penting, catat mengapa partisipasi diharapkan, interval terakhir yang diamati, riwayat perilaku kedatangan dan kualitas bukti saat ini. Pisahkan perubahan penyedia terverifikasi dari tebakan lokal berdasarkan file yang hilang. Tinjau register setelah migrasi pengirim atau perubahan hosting penerima, karena infrastruktur pelaporan yang relevan dapat berubah tanpa perubahan pada alamat email pelanggan. Harapan yang tidak dapat dibuktikan harus diberi label belum dikonfirmasi. Hal ini memberikan analis berikutnya titik awal yang konkrit dan bukan peringatan berulang yang tidak dapat dijelaskan.
Lanjutkan penyelidikan
Gunakan panduan laporan agregat untuk menafsirkan bidang yang mendasarinya dan panduan diagnosis keselarasan ketika pass otentikasi mentah tidak memuaskan DMARC.
Bukti sintetik yang dieksekusi
Berikut ini adalah perlengkapan sintetik offline yang dijalankan ulang secara lokal, bukan DNS langsung, SMTP , atau observasi pelanggan. Input XML-nya diurai dengan pustaka standar Python, dan pernyataan memeriksa bidang dan penghitungan yang dihasilkan. Tahapan DNS dan email yang disimulasikan diberikan masukan pengujian, bukan bukti bahwa penerima sebenarnya melakukan operasi tersebut. Validasi skema penuh dan otentikasi sumber produksi berada di luar perlengkapan kecil ini; bukti hidup masih menunggu keputusan.
Permintaan yang diberikan adalah _dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:aggregate@collector.example,mailto:archive@archive.example". Domain contoh yang dicadangkan ini diasumsikan sebagai domain organisasi terpisah dalam perlengkapan. Dua jawaban otorisasi sintetis adalah brand.example._report._dmarc.collector.example TXT "v=DMARC1" Dan brand.example._report._dmarc.archive.example TXT "v=DMARC1". Model lokal cocok dengan nama pemilik otorisasi yang diberikan dan nilai versinya di bawah RFC 9990 §4. Itu tidak menjalankan permintaan DNS atau algoritma otorisasi lengkap. Implementasi produksi harus melakukan prosedur penemuan dan otorisasi secara lengkap daripada mengasumsikan batas-batas domain ini.
Laporan yang disimpan memiliki ID R1, domain kebijakan brand.example , rentang_tanggal mulai 1772409600 dan berakhir 1772496000, IP sumber 192.0.2.10 dan hitungan 100. Evaluasinya selaras DKIM hasilnya lolos dan selaras SPF gagal. Hasil SPF mentah lolos ke vendor.example , yang menggambarkan mengapa kesuksesan mentah tidak selaras dengan kesuksesan. Bidang ini diurai dari XML, bukan disimpulkan dari dasbor.
receiver.example kontrol positif memiliki tanda terima yang disimulasikan dan jumlah yang diurai sebanyak 100. Penerima sintetis kedua, unobserved.example , memiliki 20 kiriman pengirim yang disediakan tetapi tidak ada tanda terima dan tidak ada jumlah yang diurai. Penegasan tersebut mempertahankan bahwa hitungan tersebut adalah nol, bukan nol. Kontrol positif permintaan-ke-parser yang telah selesai menunjukkan bahwa kolektor model dapat memproses satu laporan; hal ini tidak menetapkan bahwa penerima yang hilang berpartisipasi atau mencoba melakukan pengiriman. Investigasi langsung harus mendapatkan bukti kotak surat dan penyedianya sendiri sebelum mengubah klasifikasi tersebut.
Pertahankan hasilnya dalam lingkup pengujian
Demonstrasi lokal yang disediakan hanya memverifikasi parser sintetik kecilnya, masukan tahapan dan penghitungan yang disediakan. Tidak ada otorisasi DNS nyata, pengiriman SMTP , migrasi kolektor, partisipasi penyedia, atau perilaku basis data produksi yang diuji. Masukan asli tetap diarsipkan, dan setiap perbandingan langsung memerlukan bukti yang dilindungi dan persetujuan yang dapat dipertanggungjawabkan.