Laporan dapat memperlihatkan kebijakan penolakan yang dipublikasikan tanpa melaporkan penolakan. Baca profil pelaporan sebelum menafsirkan disposisi: terkini RFC 9990 mendefinisikan pass untuk pesan yang lewat DMARC berdasarkan kebijakan penegakan hukum, sedangkan laporan lama tidak dapat menggunakan satu pun pesan yang disampaikan. Menafsirkan konteks kebijakan, hasil otentikasi dan keputusan penanganan sebagai bukti yang berbeda. Hubungan keduanya, bukan hanya satu bidang saja, menjelaskan hal-hal yang perlu diselidiki.
Baca konfigurasi yang diamati terlebih dahulu
policy_published mencatat konfigurasi kebijakan yang diamati oleh penerima untuk domain kebijakan laporan. Ini adalah bukti pelaporan historis, bukan pencarian DNS baru. Jika Anda menanyakan DNS hari ini, pisahkan hasil dan stempel waktu tersebut. Suatu kebijakan mungkin telah berubah selama atau setelah interval yang dilaporkan.
RFC 9990 memungkinkan banyak laporan ketika konfigurasi berubah selama suatu periode; jika tidak, reporter harus mencatat konfigurasi akhir yang diamati. Oleh karena itu, satu gambaran kebijakan tidak selalu dapat menjelaskan setiap kondisi waktu pesan. Pertahankan interval dan ubah riwayat sebelum menuduh reporter melakukan inkonsistensi.
Evaluasi domain penulis dan jalur yang selaras
Sebuah rekor's header_from menyediakan domain penulis. Hal ini dapat berbeda dari domain kebijakan ketika subdomain bergantung pada kebijakan domain lain. Tentukan hubungan kebijakan yang berlaku daripada mengasumsikan setiap baris menggunakan nilai p tingkat atas secara terpisah.
Nilai dkim dan spf di bawah policy_evaluated menjelaskan evaluasi pengidentifikasi terkait DMARC. Hasil tersebut berbeda dengan hasil mentah pada auth_results. Jalur yang selaras dapat memenuhi DMARC ; identitas lewat yang tidak terkait tidak bisa. Pesan yang lolos DMARC bukanlah kandidat penolakan kebijakan hanya karena domainnya dipublikasikan p=reject.
Baca disposisi dengan alasan override
Ilustrasi kasus profil saat ini yang pertama: policy_published menunjukkan p=reject, selaras DKIM lulus dan disposisi lulus, sebagaimana dijelaskan dalam RFC 9990 Lampiran A dan diilustrasikan dalam Lampiran B. Kasus kedua: kedua jalur yang selaras gagal, namun disposisi tetap tidak ada dengan alasan kebijakan lokal. Laporan tersebut menjelaskan penggantian penerima, bukan hasil autentikasi yang diperbaiki. Simpan kegagalan dan alasannya secara terpisah.
RFC 9990 memerlukan alasan kapan penyelarasan gagal dan kebijakan yang diterapkan tidak sesuai dengan kebijakan yang dikonfigurasi. Informasi yang hilang atau tidak terduga harus ditandai untuk diselidiki daripada diisi dengan penjelasan yang dibuat-buat. Rangkaian alasannya adalah penjelasan pelapor dan mungkin masih memerlukan pembuktian.
Kasing ini sintetis. Baik disposisi tidak ada maupun hasil autentikasi yang lewat tidak membuktikan penempatan kotak masuk. Keputusan pemfilteran dan pengiriman lainnya mungkin ada di luar penanganan DMARC yang dijelaskan dalam laporan.
Selidiki ketidakcocokan nyata secara metodis
Bandingkan periode laporan, kebijakan yang diamati, domain penulis, mode penyelarasan, dan pengidentifikasi mentah dengan tanggal perubahan DNS Anda dan bukti pesan yang dikontrol. Konfirmasikan bahwa pengirim adalah rute bisnis resmi. Jika laporan tetap tidak konsisten secara internal, pertahankan XML dan catat ketidakpastiannya.
Jangan melemahkan kebijakan domain hanya untuk membuat label dasbor setuju. Memperbaiki cacat pengiriman yang terverifikasi jika ada; secara terpisah mendokumentasikan pengesampingan penerima dan batasan pelaporan. Hasilnya harus berupa narasi yang dapat direproduksi oleh administrator lain dari bidang yang sama.
Bandingkan dua perlengkapan lapangan eksplisit
Kedua peta sintetis parsial menggunakan profil pelaporan dan domain kebijakan RFC 9990 saat ini serta header_from brand.example , p=reject, penyelarasan santai, dan interval waktu 1704067200–1704153600 (1 Januari 2024 00:00 hingga 2 Januari 2024 00:00 UTC). Yang pertama, count=25, mentah SPF tiket untuk vendor.example dan tiket DKIM untuk brand.example /selector billing1. Hasil selaras yang dihitung adalah SPF gagal dan DKIM lulus; DMARC lolos. Disposisi yang diberikan lolos berdasarkan profil pelaporan RFC 9990 saat ini.
Yang kedua, count=4 dan kedua mekanisme mentah lolos vendor.example , dengan pemilih DKIM v1. Tidak ada identitas yang selaras, sehingga hasil DMARC yang dihitung gagal. Disposisi yang diberikan masih belum ada, disertai dengan jenis alasan local_policy dan komentar sintetik yang secara eksplisit “pengecualian penanganan penerusan tepercaya.” Alasan tersebut menjelaskan penanganan fiktif tanpa mengubah penyelarasan yang gagal.
Perbandingan lapangan menjelaskan kedua hasil otentikasi; contoh kedua secara eksplisit memberikan alasan. Peta lapangan parsial ini bukan XML lengkap atau observasi langsung. Keputusan penanganan penerima merupakan masukan, bukan konsekuensi yang disimpulkan dari otentikasi saja.
Pilih tindakan selanjutnya
- Lulus selaras ditambah izin disposisi profil saat ini (atau tidak ada profil lama): tidak ada penolakan DMARC yang diminta untuk pesan yang lewat itu; selidiki pengiriman secara terpisah jika diperlukan.
- Kedua jalur yang disejajarkan gagal ditambah disposisi tidak ada: periksa alasan penggantian dan konfirmasikan pengirimnya, daripada memberi label ulang pada autentikasi sebagai lolos.
- Laporan dan DNS saat ini tidak setuju: bandingkan interval laporan dengan riwayat perubahan kebijakan bertanggal.
- Alasan wajib tidak ada: simpan laporan dan tandai ketidakcocokan yang tidak dapat dijelaskan. Jangan membuat pengecualian kebijakan lokal.
Membedakan disposisi saat ini dan disposisi warisan
RFC 9990 Lampiran A mendefinisikan izin disposisi sebagai tidak ada tindakan untuk meloloskan DMARC dengan kebijakan penegakan hukum. Itu tidak mempertahankan apa pun karena tidak ada tindakan yang diambil. Laporan berformat RFC 7489 yang lebih lama tidak memiliki disposisi pass dan tidak dapat melaporkan apa pun untuk pesan yang lewat. Periksa namespace, profil pelaporan, dan hasil yang selaras: tidak ada yang tidak valid secara universal, namun tidak boleh menggantikan contoh pass profil saat ini. Tidak ada nilai yang membuktikan penempatan kotak masuk.