Apa Itu DMARC? Beda p=none, Quarantine & Reject

Q: Kenapa saya tidak menerima laporan rua?

Periksa sintaks mailto:, pastikan kotak surat benar-benar bisa menerima email, dan bila alamatnya di domain lain, pastikan record otorisasi _report._dmarc sudah ada. Laporan juga baru datang setelah ada email yang dikirim ke penyedia yang mendukung pelaporan.

DMARC (Domain-based Message Authentication, Reporting and Conformance) adalah record TXT di _dmarc.domainanda.com yang memberi tahu server penerima apa yang harus dilakukan pada email yang mengaku dari domain Anda tetapi gagal autentikasi. Ada tiga kebijakan: p=none (hanya pantau), p=quarantine (masukkan ke spam/karantina), dan p=reject (tolak). Selain kebijakan, DMARC juga mengirimkan laporan rutin sehingga Anda tahu siapa saja yang mengirim email atas nama domain Anda.

DMARC dibangun di atas dua mekanisme lain: SPF dan DKIM. Artikel ini fokus pada DMARC itu sendiri: bedanya ketiga kebijakan, arti setiap tag, dasar alignment, cara membaca laporan rua, dan urutan rollout yang aman agar email sah tidak ikut terblokir.

Masalah yang diselesaikan DMARC

SPF dan DKIM masing-masing hanya membuktikan sesuatu tentang sebuah domain, belum tentu domain yang dilihat penerima di kolom From:. Penipu bisa mengirim email dengan From: billing@bankanda.com dari server miliknya sendiri yang SPF-nya lolos untuk domain lain. DMARC menutup celah ini dengan dua hal:

Alignment: SPF atau DKIM yang lolos harus untuk domain yang sama (atau sekeluarga) dengan domain di header From:.
Kebijakan + laporan: pemilik domain menyatakan tindakan untuk email yang gagal, dan penerima mengirim statistik kembali.

Sebuah email lolos DMARC bila minimal satu dari ini benar: SPF pass dan aligned, atau DKIM pass dan aligned. Email gagal DMARC hanya bila keduanya gagal.

Dasar alignment

Alignment membandingkan domain di From: dengan:

domain envelope (MAIL FROM/Return-Path) untuk SPF, dan
domain d= di tanda tangan DKIM.

Ada dua mode. Mode relaxed (default) cukup bila domain organisasinya sama, jadi bounce.contoh.com selaras dengan contoh.com. Mode strict mengharuskan nama domain persis sama. Untuk sebagian besar situs, relaxed sudah tepat.

Skenario paling umum DMARC gagal adalah layanan pihak ketiga (newsletter, CRM) yang memakai domain mereka sendiri di Return-Path dan di d=. SPF dan DKIM-nya pass, tetapi tidak selaras dengan domain Anda. Diagnosis lengkap dan cara memperbaikinya ada di artikel DMARC gagal padahal SPF lolos, jadi di sini cukup dasar konsepnya.

p=none vs quarantine vs reject

Kebijakan	Yang diminta ke penerima	Kapan dipakai
`p=none`	Tidak ada tindakan khusus; tetap kirim laporan	Tahap awal untuk memetakan semua pengirim
`p=quarantine`	Perlakukan sebagai mencurigakan, biasanya masuk folder spam/junk	Setelah semua pengirim sah sudah lolos
`p=reject`	Tolak saat transaksi SMTP	Tujuan akhir untuk perlindungan penuh

Penting dipahami: kebijakan ini adalah permintaan, bukan perintah. Penerima tetap punya kebijakan sendiri. Misalnya Microsoft 365 punya pengaturan "Honor DMARC record policy" di kebijakan anti-phishing yang menentukan apakah p=reject benar-benar ditolak atau dialihkan ke karantina.

Juga, p=none tidak melindungi domain Anda dari spoofing. Ia hanya membuka "lampu pemantau". Banyak domain berhenti di p=none bertahun-tahun karena takut; padahal manfaat sebenarnya baru terasa di quarantine atau reject.

Tag-tag DMARC

Contoh record lengkap:

_dmarc.contoh.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@contoh.com; adkim=r; aspf=r; pct=100; fo=1"

Tag	Wajib?	Fungsi
`v=DMARC1`	Ya, harus pertama	Penanda versi
`p=`	Ya	Kebijakan untuk domain: `none`, `quarantine`, `reject`
`sp=`	Tidak	Kebijakan khusus subdomain; bila tidak ada, subdomain ikut `p=`
`rua=`	Tidak, tapi sangat disarankan	Alamat penerima laporan agregat, format `mailto:`, boleh lebih dari satu dipisah koma
`ruf=`	Tidak	Alamat laporan kegagalan per pesan; banyak penerima tidak mengirimkannya
`pct=`	Tidak	Persentase email gagal yang dikenai kebijakan (default 100)
`adkim=`	Tidak	Mode alignment DKIM: `r` (default) atau `s`
`aspf=`	Tidak	Mode alignment SPF: `r` (default) atau `s`
`fo=`	Tidak	Kapan laporan kegagalan dibuat: `0` (default, bila semua gagal), `1` (bila salah satu gagal), `d`, `s`
`ri=`	Tidak	Interval laporan yang diminta dalam detik, default 86400 (sehari)

Beberapa catatan praktis:

Record ditaruh di host _dmarc, bukan di @. Hanya boleh ada satu record DMARC per nama.
Berbeda dengan SPF, DMARC diwariskan ke subdomain yang tidak punya record _dmarc sendiri, termasuk subdomain yang tidak ada. Itu sebabnya sp= berguna.
Revisi standar DMARC yang sedang berjalan di IETF (dikenal sebagai DMARCbis) mengganti pct dengan mekanisme yang lebih sederhana. Saat ini pct masih dikenali penerima besar seperti Google dan Microsoft, jadi aman dipakai, tetapi jangan mengandalkannya sebagai satu-satunya strategi rollout.

Contoh pemakaian sp= untuk subdomain

Misalkan domain utama Anda masih di tahap pemantauan, tetapi Anda tahu tidak ada subdomain yang sah mengirim email. Anda bisa langsung melindungi semua subdomain sambil tetap memantau domain utama:

v=DMARC1; p=none; sp=reject; rua=mailto:dmarc@contoh.com

Penyerang sering memakai subdomain acak seperti billing.contoh.com karena mengira subdomain tidak dijaga. Dengan sp=reject, email palsu dari subdomain itu ditolak walaupun domain utama belum ditegakkan. Bila nanti ada subdomain yang memang perlu mengirim email, buat record _dmarc khusus untuk subdomain tersebut dengan kebijakannya sendiri.

Anda bisa menyusun record tanpa salah ketik dengan DMARC Generator.

Memahami laporan rua

Setelah record dengan rua= terpasang, penyedia email besar mulai mengirim laporan agregat, biasanya sekali sehari, berupa file XML (sering dikompres zip atau gzip) sebagai lampiran email. Isinya bukan isi pesan, melainkan statistik per IP pengirim:

<record>
  <row>
    <source_ip>198.51.100.25</source_ip>
    <count>340</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>contoh.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>contoh.com</domain><result>pass</result></dkim>
    <spf><domain>bounce.layanan.net</domain><result>pass</result></spf>
  </auth_results>
</record>

Cara membacanya:

source_ip dan count: dari IP mana dan berapa banyak email.
policy_evaluated: hasil setelah alignment. Di contoh, SPF dianggap fail karena domain SPF-nya bounce.layanan.net, tidak selaras dengan contoh.com.
auth_results: hasil mentah SPF/DKIM sebelum alignment. SPF sebenarnya pass, hanya untuk domain lain.
Karena DKIM pass dan aligned, email ini tetap lolos DMARC.

Membaca XML mentah setiap hari cepat melelahkan. Untuk domain kecil, mengekstrak file lalu membukanya di editor teks atau browser masih bisa dilakukan. Untuk volume besar, gunakan layanan analisis laporan DMARC yang mengubah XML menjadi dashboard. Sediakan kotak surat khusus (misalnya dmarc@) agar laporan tidak membanjiri inbox pribadi.

Bila alamat rua berada di domain lain (misalnya layanan analisis pihak ketiga), domain tujuan harus memasang record otorisasi berbentuk contoh.com._report._dmarc.domain-tujuan.com berisi v=DMARC1. Layanan analisis biasanya sudah mengurus ini.

Dapatkan Update Terbaru

Berlangganan gratis. Artikel & tutorial coding terbaru langsung ke email kamu. Tanpa spam.

Rollout DMARC yang aman

Tujuannya mencapai p=reject tanpa memblokir email sah. Urutan yang direkomendasikan Google dan Microsoft pada dasarnya sama:

Tahap 0: Siapkan SPF dan DKIM

Pastikan semua layanan pengirim sudah lolos SPF dan, idealnya, menandatangani DKIM dengan domain Anda. Google menyarankan menunggu 48 jam setelah SPF/DKIM aktif sebelum memasang DMARC.

Tahap 1: Pantau dengan p=none

v=DMARC1; p=none; rua=mailto:dmarc@contoh.com

Kumpulkan laporan beberapa minggu. Buat daftar setiap IP/layanan yang muncul, tandai mana yang sah, lalu perbaiki alignment-nya satu per satu.

Tahap 2: Quarantine bertahap

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@contoh.com

Naikkan pct secara bertahap (misalnya 25, 50, 100) sambil memantau laporan dan keluhan pengguna.

Tahap 3: Reject

v=DMARC1; p=reject; rua=mailto:dmarc@contoh.com

Pertahankan rua agar Anda tetap tahu bila ada layanan baru yang belum dikonfigurasi.

Microsoft juga menyarankan memulai dari subdomain bervolume rendah dan menyisakan domain induk untuk terakhir. Untuk domain yang tidak pernah mengirim email, langsung pasang v=DMARC1; p=reject; bersama v=spf1 -all.

Cara mengecek DMARC

dig +short TXT _dmarc.contoh.com

Pastikan hanya satu record, diawali v=DMARC1, dan tag p= ada. DMARC Checker memeriksa sintaks dan menjelaskan arti setiap tag. Untuk email sungguhan, buka header di Gmail dan cari dmarc=pass di baris Authentication-Results.

Kesalahan umum

Langsung p=reject tanpa fase pemantauan, sehingga invoice atau email reset password ikut ditolak.
Record di host yang salah (@ bukan _dmarc).
Dua record DMARC di nama yang sama.
Tidak memasang rua, sehingga terbang buta.
Menetap di p=none selamanya dan mengira domain sudah terlindungi.
Strict alignment tanpa alasan, yang membuat subdomain sah gagal.

Checklist DMARC

SPF dan DKIM aktif dan selaras untuk semua pengirim sah.
Record di _dmarc, diawali v=DMARC1, hanya satu.
rua mengarah ke kotak surat khusus atau layanan analisis.
Rollout: none → quarantine (pct bertahap) → reject.
Domain parkir: p=reject.
Laporan ditinjau rutin, termasuk setelah mencapai reject.

FAQ

Apakah p=none sudah memenuhi syarat Gmail?

Untuk pengirim massal, Google mensyaratkan adanya record DMARC dan kebijakan p=none sudah memenuhi syarat minimum itu. Namun perlindungan dari spoofing baru didapat di quarantine atau reject.

Apakah DMARC butuh SPF dan DKIM sekaligus?

Secara teknis cukup salah satu yang lolos dan selaras. Namun sangat disarankan keduanya, karena SPF sering rusak saat forwarding, sedangkan DKIM biasanya bertahan.

Berapa lama sebaiknya di p=none?

Tidak ada angka baku. Patokannya data: lanjutkan setelah laporan beberapa minggu menunjukkan semua sumber sah sudah lolos dan selaras.

Apakah laporan DMARC berisi isi email?

Laporan agregat tidak. Isinya hanya IP, jumlah, dan hasil autentikasi. Laporan kegagalan (ruf) bisa memuat sebagian header, dan banyak penyedia memilih tidak mengirimnya.

Kenapa saya tidak menerima laporan rua?

Periksa sintaks mailto:, pastikan kotak surat benar-benar bisa menerima email, dan bila alamatnya di domain lain, pastikan record otorisasi _report._dmarc sudah ada. Laporan juga baru datang setelah ada email yang dikirim ke penyedia yang mendukung pelaporan.