Cara Membaca Kebijakan DMARC Perusahaan dalam Sepuluh Detik (dan Apa yang Tidak Diungkapkannya)

Satu pencarian DNS memberitahu Anda apa yang telah diminta perusahaan kepada server surat dunia untuk dilakukan dengan surat palsu yang dikirim atas namanya. Catatan tersebut bersifat publik, dan perintahnya adalah satu baris: dig +short TXT _dmarc.example.com. Yang dikembalikan adalah rangkaian pengaturan pendek, dan di dalamnya ada satu instruksi — p=none, p=quarantine atau p=reject — yang menyatakan preferensi pemilik domain ketika pesan menggunakan domain tersebut gagal autentikasi.

Spesifikasi saat ini, RFC 9989, dipublikasikan pada Mei 2026 sebagai dokumen IETF Standards Track, menggantikan RFC 7489 yang lebih lama. Ini mendefinisikan ketiga nilai hampir secara ringkas:

• p=none — "Pemilik Domain tidak mengungkapkan preferensi apa pun."
• p=quarantine — "Pemilik Domain menganggap surat tersebut mencurigakan. Adalah mungkin surat tersebut valid, meskipun kegagalan menciptakan kekhawatiran yang signifikan."
• p=reject — "Pemilik Domain menganggap semua kegagalan tersebut sebagai indikasi yang jelas bahwa penggunaan nama domain tidak valid."

Baca kembali kata-kata tersebut, karena kata-kata itu lebih lemah daripada yang diakui sebagian besar penjelasan tentang DMARC. Kebijakan adalah preferensi, dipublikasikan oleh pengirim agar penerima mempertimbangkannya. Bukan instruksi yang harus dilaksanakan penerima. RFC 9989 mengatakan demikian dalam satu kalimat: "Penanganan akhir pesan apa pun selalu merupakan masalah kebijakan lokal dan diserahkan kepada kebijaksanaan Mail Receiver." Bagian yang sama menambahkan kedua sisi konsekuensinya — penerima "DAPAT memilih untuk menolak atau mengisolasi pesan bahkan jika lolos pemeriksaan validasi DMARC," dan mereka "TIDAK BOLEH menolak pesan semata-mata karena kebijakan terbit 'reject'," tepatnya agar surat sah yang dikirim dengan cara yang tidak dapat dijelaskan DMARC, dan mailing list, tidak hancur dalam prosesnya.

Jadi apa yang benar-benar diakui p=none? Lebih sedikit daripada yang biasanya dituduhkan. Dalam istilah spek sendiri itu adalah Monitoring Mode: pemilik domain mengumpulkan laporan agregat dan "tidak mengungkapkan preferensi penanganan untuk pesan yang gagal validasi DMARC," sementara penerima yang menerapkan DMARC "masih dapat" memvalidasi penggunaan domain. Apa yang tidak dilakukannya adalah mengubah apa pun di ujung penerima. Filter spam, penilaian reputasi, pemeriksaan URL, dan analisis lampiran penyedia Anda adalah mesin terpisah yang berjalan terlepas dari apa yang dipublikasikan pengirim. Pesan palsu yang tiba di domain p=none tidak dipromosikan ke inbox Anda oleh catatan; catatan hanya diserahkan kepada penerima tanpa preferensi yang dinyatakan, dan penerima memutuskan.

Setengah lainnya dari kesalahpahaman berjalan ke arah yang berlawanan. DMARC tidak membaca bagian berbahaya dari email phishing. Spesifikasi umumnya mencantumkan apa yang sengaja diluar cakupan, dan "analisis konten" ada di daftar itu, dalam kata-kata tersebut. Ini juga menyatakan bahwa DMARC "tidak mengatasi penggunaan nama domain yang terlihat mirip atau penyalahgunaan nama tampilan yang dapat dibaca manusia RFC5322.From" — dua trik yang membawa sebagian besar surat impersonasi merek. Dan tentang nilai kelulusan: "kelulusan DMARC sendiri tidak menjamin bahwa pengiriman ke inbox penerima akan aman atau diinginkan." Pesan yang diautentikasi dengan benar dari domain sekali pakai lulus DMARC dengan bersih. DMARC menjawab siapa yang berwenang menggunakan domain di header From:. Tidak lebih.

Di sinilah aturan pengirim massal 2024 secara rutin salah dilaporkan, termasuk dalam versi pertama artikel ini. Pedoman pengirim Google memerlukan pengirim 5.000 atau lebih pesan per hari ke akun Gmail untuk "Siapkan autentikasi email DMARC untuk domain pengiriman Anda," dan kemudian katakan, dalam napas yang sama: "Kebijakan penegakan DMARC Anda dapat diatur ke none." Sender Hub milik Yahoo sendiri, yang harus dibaca secara terpisah daripada diasumsikan menyalin Google, menyatakan persyaratan sebagai "Terbitkan kebijakan DMARC yang valid dengan setidaknya p=none - DMARC harus lulus," dan tidak mempublikasikan ambang batas volume numerik sama sekali. Kedua set persyaratan berlaku efektif dari Februari 2024. Tidak satupun memaksa siapa pun keluar dari p=none. Apa yang sebenarnya dipaksa keduanya adalah autentikasi yang selaras: Google memerlukan bahwa "domain di header From: pengirim harus selaras dengan domain SPF atau domain DKIM," dan Yahoo mengatakan penjajaran santai dapat diterima. Penjajaran, bukan tingkat keparahan, adalah gatenya.

Yang meninggalkan alasan sebenarnya mengapa domain duduk dalam pemantauan, dan itu bersifat operasional daripada pengecut. Berpindah ke quarantine atau reject berarti terlebih dahulu menemukan setiap layanan yang mengirim surat atas nama Anda — penggajian, ticketing, pemasaran, meja support yang tidak terdokumentasi — dan mengautentikasi masing-masing agar selaras. Standar itu sendiri mengakui bahaya yang membuat ini lambat: pengirim pihak ketiga tidak diperkenalkan atau dikecualikan oleh DMARC, penerusan dan mailing list dapat memecah penjajaran tanpa kesalahan pengirim, dan spek menunjukkan penerima pada RFC 7960 untuk mode kegagalan yang tepat. Organisasi yang mempublikasikan p=none dan membaca laporannya melakukan pekerjaan dalam urutan yang dijelaskan spek. Satu yang mempublikasikan p=none dan mengabaikan laporan tidak. Dari luar, catatan saja tidak dapat memberitahu Anda mana dari keduanya yang Anda lihat.

Anda tidak memerlukan terminal untuk mencari. Alat pencarian gratis — domain checker dmarcian, pemeriksaan DMARC MXToolbox — mengambil catatan dan mencetak kebijakan untuk Anda. Lakukan untuk bank Anda, penyedia penggajian, maskapai yang Anda terbang. Baca jawabannya untuk apa adanya: pernyataan niat oleh pemilik domain, satu masukan di antara banyak ke keputusan yang dibuat penyedia surat Anda sendiri, tentang satu jenis pemalsuan tertentu. Itu adalah hal yang benar-benar berguna untuk dapat dibaca dalam sepuluh detik. Bukan keputusan tentang apakah pesan berikutnya yang mengklaim berasal dari merek itu aman.

Koreksi, 20 Oktober 2026. Versi sebelumnya dari artikel ini menggambarkan p=none sebagai pengiriman pemalsuan ke inbox dan p=reject sebagai satu-satunya pengaturan yang memblokir pesan yang dipalsukan, mengatakan bahwa aturan pengirim massal 2024 Google dan Yahoo memaksa pengirim keluar dari p=none, dan mengutip angka kira-kira satu dari tiga domain saat penegakan. Deskripsi kebijakan telah dikoreksi terhadap RFC 9989; Google dan Yahoo sebenarnya menerima p=none, dikutip di atas dari dokumentasi mereka sendiri; dan angka penegakan telah dihapus karena laporan yang mendasar tidak mempublikasikan sampel atau penyebutnya. Artikel sekarang juga menyatakan apa yang tidak diperiksa DMARC.

@@END@@