Sebuah pesan bisa disampaikan DMARC dan masih gagal memenuhi persyaratan pengirim penyedia kotak surat. Hal ini belum tentu merupakan suatu kontradiksi. DMARC menjawab pertanyaan identitas tertentu; penerima mungkin juga memerlukan mekanisme yang berfungsi, transportasi yang aman, konstruksi pesan yang sesuai, dan perilaku pengiriman yang bertanggung jawab.
Mulailah dengan keputusan protokol
Referensi: RFC 9989 §4.1, RFC 9989 §4.4, RFC 9989 §4.10, RFC 9989 §5.3.5.
RFC 9989, yang diterbitkan pada bulan Mei 2026, menggantikan RFC 7489 dan 9091 yang lama. Berdasarkan bagian 4.1, DMARC lolos ketika data kebijakan ada untuk Domain Penulis dan domain tersebut selaras dengan pengidentifikasi yang diautentikasi dari pesan. Prinsip aligned-pass tetap ada: setidaknya satu mekanisme otentikasi yang didukung harus lolos penyelarasan ke domain Dari yang terlihat. Untuk SPF dalam DMARC , identitas yang relevan adalah SMTP KIRIM DARI domain berdasarkan RFC 9989 §4.4.2; hasil SPF berbasis HELO yang berdiri sendiri bukanlah pengganti identitas DMARC tersebut. Untuk DKIM, ini adalah domain d= dari tanda tangan yang valid. Mekanisme yang sukses tanpa penyelarasan yang diperlukan tidak akan memberikan kontribusi lolosnya DMARC . RFC 9989 bagian 3.2.10 dan 4.1–4.3.
Penyelarasan memiliki mode ketat dan santai. Ketat membandingkan domain yang berlaku dengan tepat; santai menggunakan hubungan organisasi-domainnya. RFC 9989 bagian 4.10 mendefinisikan Jalan Pohon DNS penemuan daripada pendekatan daftar sufiks publik yang lama. Verifikasi versi yang diterapkan oleh penerima atau evaluator sebelum mengasumsikan perilaku penemuannya. Jangan terapkan penyelarasan santai dengan memeriksa apakah satu string domain diakhiri dengan string domain lainnya. Akhiran yang menipu atau penghitungan domain organisasi yang salah dapat memberikan hasil yang salah.
Tambahkan persyaratan penyedia sebagai lapisan terpisah
Panduan dukungan konsumen dalam jumlah besar dari Microsoft mengharuskan SPF dan DKIM untuk lulus, ditambah DMARC . Persyaratan massal Yahoo memerlukan mekanisme dan melewati DMARC . Ini adalah gerbang operasional selain logika mekanisme protokol yang selaras. Tinjau sumber tujuan saat ini daripada menyimpulkan aturan universal dari satu penyedia. dukungan Microsoft Dan Persyaratan Yahoo.
Buat satu kolom untuk hasil DMARC dan kolom terpisah untuk kontrol autentikasi, DNS , transportasi, pemformatan, dan berhenti berlangganan yang diperlukan. Indikator hijau keseluruhan tanpa kolom tersebut menyulitkan untuk mengetahui apakah perangkat lunak sedang mengevaluasi protokol, daftar periksa penyedia, atau hanya sintaks DNS yang dipublikasikan.
Gunakan tabel kebenaran untuk mengungkap perbedaannya
Referensi: RFC 9989 §5.3.5.
Paket ulasan pribadi mencakup perlengkapan sintetis dua kotak. Pertama, SPF dan DKIM sama-sama lulus namun tidak ada yang sejajar: DMARC gagal. Kedua, SPF gagal saat DKIM lolos dan menyelaraskan: DMARC lolos. Kasus kedua masih bisa menggagalkan gerbang penyedia yang secara mandiri memerlukan keberhasilan SPF .
Masukan ini sengaja berupa boolean sederhana, bukan implementasi penemuan DNS Tree Walk, penemuan berbasis sufiks publik lama, evaluasi SPF , atau kriptografi DKIM . Kedua kasus tersebut mengasumsikan adanya catatan kebijakan DMARC yang berlaku. Mereka membuat perbedaan logis dapat direproduksi tanpa berpura-pura menguji penyedia. Dalam penyelidikan nyata, ganti setiap boolean dengan hasil observasi tepercaya dan identitas evaluasinya.
Jangan bingung antara publikasi dengan evaluasi
Referensi: RFC 9989 §5.4.
Penerbitan p=none menetapkan kebijakan pemantauan yang diminta, bukan hasil otentikasi pesan yang berhasil. Menerbitkan kunci publik DKIM tidak menandatangani surat keluar. Menambahkan sebuah Catatan SPF tidak membuktikan koneksi sebenarnya menggunakan alamat resmi. Setiap artefak konfigurasi memerlukan pengamatan yang sesuai dari rute pengiriman yang dituju.
Demikian pula, berpindah dari p=none ke p=reject tidak memperbaiki keselarasan. Ini mengubah penanganan kegagalan yang diminta pemilik domain. Inventarisasi rute yang sah sebelum mengubah penegakan hukum, pertahankan rencana rollback dan evaluasi dampaknya terhadap aliran tidak langsung. Penerima masih menerapkan kebijakan disposisi lokalnya sendiri; tindakan DMARC yang diminta bukan merupakan jaminan pengiriman.
Buat catatan penutupan yang berguna
Referensi: RFC 8601 §5.
Untuk setiap sampel yang diselidiki, simpan Dari, pengirim amplop, IP penghubung, penandatangan DKIM dan pemilih, hasil mekanisme, mode penyelarasan, dan respons penerimaan akhir. Identifikasi sumber tepercaya dari hasil tersebut. Jangan menerima salinan header secara sewenang-wenang sebagai sesuatu yang otoritatif hanya karena mengandung kata “lulus”.
Tutup temuan protokol dan temuan kepatuhan penyedia secara terpisah. Hal ini memungkinkan untuk mengatakan secara akurat bahwa DMARC lolos sementara persyaratan lain masih belum terselesaikan, dan untuk menetapkan koreksi kepada pemilik hak tanpa melemahkan kontrol yang tidak terkait.