DMARC Adalah: Cara Kerja, Isi Record & Cara Memasangnya

Dua record DNS biasanya sudah terpasang di domain yang dipakai berkirim email. Pertama SPF (Sender Policy Framework), yang mendaftar server mana saja yang berhak mengirim atas nama domain tersebut. Kedua DKIM (DomainKeys Identified Mail), yang menempelkan tanda tangan digital pada setiap pesan keluar.

Keduanya bekerja, tetapi berhenti pada titik yang sama: hasil pemeriksaannya tidak pernah dihubungkan dengan alamat yang benar-benar terlihat penerima di kotak masuk. Server penerima juga tidak diberi instruksi apa pun saat pemeriksaan itu gagal, dan pemilik domain tidak pernah tahu bahwa kegagalan tersebut terjadi. DMARC adalah kebijakan yang menutup ketiga celah tersebut sekaligus.

Ia tidak menggantikan SPF maupun DKIM, melainkan memakai hasil keduanya. Di atas hasil itu, ia menuntut agar domain yang lolos sama dengan domain di kolom pengirim, lalu memberi tahu penerima apa yang harus dilakukan bila tuntutan tersebut tidak terpenuhi. Sebagai pelengkap, ia meminta penerima mengirimkan laporan berkala ke pemilik domain.

Artikel ini membedah isi record DMARC tag demi tag, menjelaskan cara membaca laporan yang datang, dan menunjukkan perubahan penting yang terjadi pada spesifikasinya sepanjang 2026.

DMARC Adalah Kebijakan, Bukan Pemeriksaan Ketiga

DMARC merupakan singkatan dari Domain-based Message Authentication, Reporting, and Conformance. Nama panjangnya sudah memuat tiga pekerjaannya sekaligus: memastikan pesan benar berasal dari domain yang diklaim (authentication), mengirim laporan balik (reporting), dan menuntut kepatuhan pada aturan pemilik domain (conformance).

Kekeliruan yang paling sering muncul adalah menganggap DMARC sebagai pemeriksaan ketiga setelah SPF dan DKIM. Sebenarnya DMARC tidak memeriksa apa pun sendiri. Ia menumpang hasil dua pemeriksaan yang sudah ada, lalu menambahkan tiga hal yang tidak dimiliki keduanya:

1. Keselarasan domain: SPF dan DKIM boleh saja lolos dengan domain apa pun. DMARC menuntut domain yang lolos itu selaras dengan alamat yang tampil di kotak masuk penerima.
2. Instruksi tindakan: Tanpa DMARC, server penerima menebak sendiri apa yang harus dilakukan pada pesan yang gagal. Dengan DMARC, pemilik domain yang menentukan.
3. Umpan balik: Penerima mengirimkan laporan berisi siapa saja yang berkirim email atas nama domain Anda, termasuk pihak yang tidak berhak.

Ketiganya penting karena protokol pengiriman email sendiri tidak pernah dirancang dengan verifikasi identitas. Kolom pengirim pada SMTP bisa diisi bebas oleh siapa saja, dan itulah yang dimanfaatkan pelaku email spoofing.

Urutan pemeriksaannya di sisi penerima berjalan seperti berikut:

Cara kerja DMARC di server penerima: hasil SPF dan DKIM dikumpulkan, dicocokkan ke header From, lalu p= dijalankan.

Keselarasan Domain: Syarat yang Membedakan DMARC

Keselarasan atau alignment adalah inti yang membuat DMARC berbeda dari sekadar menjalankan SPF dan DKIM berbarengan. Sebuah pesan dinyatakan lolos DMARC bila minimal satu dari dua pemeriksaan berhasil dan domain yang berhasil itu selaras dengan domain pada header From — alamat yang dibaca penerima.

Inilah penyebab paling umum sebuah pesan lolos SPF tetapi tetap dinilai gagal oleh DMARC. Layanan pihak ketiga yang mengirim atas nama Anda, misalnya penyedia newsletter atau notifikasi aplikasi, kerap lolos SPF memakai domainnya sendiri. Pemeriksaannya berhasil, tetapi domain yang lolos bukan domain Anda, sehingga DMARC menyatakan gagal.

Tingkat ketatnya keselarasan diatur dua tag terpisah, adkim untuk DKIM dan aspf untuk SPF. Masing-masing menerima dua nilai:

1. Relaxed (r): Cukup domain organisasinya sama. Pesan dari mail.namadomain.com dinilai selaras dengan From berdomain namadomain.com. Ini nilai bawaan bila tag-nya tidak ditulis.
2. Strict (s): Nama domainnya harus persis sama, sampai ke subdomainnya. mail.namadomain.com tidak lagi dianggap selaras dengan namadomain.com.

Keselarasan DMARC: mode relaxed menerima mail.namadomain.com untuk From namadomain.com, mode strict menolaknya.

Perbedaan keduanya jarang disadari karena mayoritas pemilik domain tidak pernah menuliskan kedua tag ini. Dalam pengukuran yang dijelaskan di bagian berikutnya, 38 dari 59 domain tidak menyebut adkim maupun aspf sama sekali, artinya berjalan dengan mode relaxed tanpa pernah memilihnya secara sadar.

Mode strict terdengar lebih aman, tetapi konsekuensinya nyata. Begitu Anda menetapkan adkim=s, seluruh subdomain yang mengirim email atas nama domain utama harus menandatangani pesannya sendiri. Mulailah dari relaxed, dan naikkan hanya setelah laporan menunjukkan tidak ada pengirim sah yang tertinggal.

Isi Record DMARC: Sebelas Tag yang Sah

Sebuah dmarc record adalah satu baris teks yang dipasang sebagai TXT record di DNS, pada nama host _dmarc di depan nama domain Anda. Garis bawah di awal nama itu bukan salah ketik. Ia menandai record layanan, bentuk penamaan yang sah di DNS meski tidak sah untuk nama mesin biasa seperti yang dibahas pada artikel FQDN.

Contoh record yang lengkap terlihat seperti ini:

v=DMARC1; p=quarantine; sp=reject; rua=mailto:laporan@namadomain.com; adkim=r; aspf=r; fo=1

Dibaca satu per satu, record di atas menyampaikan enam hal. Ini record DMARC versi 1. Pesan yang gagal agar dimasukkan ke folder spam, sedangkan pesan dari subdomain yang gagal agar ditolak sama sekali.

Tiga sisanya mengurus pelaporan dan ketelitian. Laporan agregat dikirim ke alamat yang tertera, keselarasannya memakai mode relaxed untuk DKIM maupun SPF, dan laporan kegagalan dikirim bila salah satu pemeriksaan tidak lolos.

Contoh record DMARC dengan tujuh tag terpakai, disertai arti sebelas tag yang sah menurut RFC 9989.

Seluruh isi dmarc record ditulis dalam bentuk pasangan tag=nilai yang dipisahkan titik koma. Spesifikasi terbaru mengenal sebelas tag, tidak lebih:

Tiga nilai p adalah bagian yang paling menentukan. p=none meminta penerima tidak melakukan apa-apa selain mengirim laporan. p=quarantine meminta pesan yang gagal dibuang ke folder spam. p=reject meminta pesan ditolak sebelum sampai ke penerima.

Dua tag berikutnya sering diabaikan padahal menutup celah yang lebar. Tag sp mengatur subdomain, dan tag np mengatur subdomain yang sebenarnya tidak pernah dibuat. Tanpa np, penyerang bisa mengarang nama subdomain apa saja — misalnya invoice.namadomain.com yang tidak pernah Anda daftarkan — dan memakainya untuk berkirim pesan.

Mei 2026: DMARC Naik Status dan Tag pct Dihapus

Sepanjang sepuluh tahun pertamanya, DMARC berjalan di atas RFC 7489 yang terbit 2015 dengan status Informational. Status itu berarti dokumennya sekadar mencatat praktik yang sudah berjalan, bukan standar yang mengikat.

Pada Mei 2026, IETF menerbitkan tiga dokumen pengganti sekaligus: RFC 9989 untuk mekanisme intinya, RFC 9990 untuk laporan agregat, dan RFC 9991 untuk laporan kegagalan. Ketiganya menggantikan RFC 7489 dan menaikkan DMARC ke jalur standar (Standards Track) untuk pertama kalinya.

Perubahan yang paling berdampak bagi record yang sudah terpasang adalah penghapusan tag pct. Tag itu dulu dipakai untuk menerapkan kebijakan hanya pada sebagian pesan, misalnya pct=25 yang berarti hanya seperempat pesan gagal yang dikenai tindakan. Alasan penghapusannya jujur disebutkan di dokumennya: pengalaman operasional menunjukkan nilai selain 0 dan 100 tidak pernah diterapkan akurat, dan penyimpangannya berbeda-beda antar-implementasi. Fungsi pct=0 yang ternyata berguna dipindahkan ke tag baru t=y.

Dua tag lama lain juga menghilang. Tag ri, yang meminta laporan dikirim pada interval tertentu, dan rf, yang menentukan format laporan kegagalan, tidak muncul lagi di ketiga dokumen tersebut.

Yang membuat penghapusan ini berkonsekuensi nyata adalah satu aturan tegas di dalamnya: tag yang tidak terdaftar wajib diabaikan oleh penerima. Artinya sebuah record yang berbunyi p=reject; pct=10 tidak lagi dibaca sebagai "tolak 10 persen pesan gagal", melainkan sebagai p=reject polos — tolak semuanya. Perilaku record berubah drastis tanpa satu karakter pun disunting.

Perlu ditegaskan bahwa penerapan di sisi penerima berjalan bertahap. Selama masa peralihan ini, satu record yang sama bisa diperlakukan berbeda oleh dua penyedia email yang berbeda, tergantung spesifikasi mana yang sudah mereka ikuti. Ketidakpastian itulah alasan record yang masih menyandarkan perilakunya pada pct sebaiknya segera dirapikan.

Isi Record DMARC 69 Domain Indonesia

Untuk mengukur seberapa besar dampak perubahan di atas, kami memeriksa record DMARC 69 domain Indonesia pada 13 Agustus 2026. Sampelnya menyebar di tujuh sektor: kampus, instansi pemerintah, marketplace, bank, fintech dan travel, media, serta penyedia hosting. Setiap record dikueri lewat DNS, dan record yang dikutip di bawah diverifikasi ulang memakai resolver kedua agar hasilnya konsisten.

Dari 69 domain Indonesia, 59 punya record DMARC, 35 masih memakai tag yang dihapus, dan tidak satu pun memasang np.

Angka yang paling perlu diperhatikan ada di baris tebal. Lebih dari separuh domain yang punya record masih menyimpan pct, ri, atau rf di dalamnya. Sebagian besar memakai pct=100, yang kebetulan sama dengan perilaku bawaan sehingga tidak berubah apa-apa. Tiga domain memakai nilai lain, dan salah satunya berdampak besar.

Domain ugm.ac.id memasang record berikut:

v=DMARC1; p=reject; pct=5; rua=mailto:abuse@ugm.ac.id; ruf=mailto:abuse@ugm.ac.id; fo=1

Di bawah spesifikasi lama, record itu menolak 5 persen pesan yang gagal. Di bawah spesifikasi baru, pct diabaikan dan record yang sama menolak seluruhnya. Perbedaan penegakannya dua puluh kali lipat, ditentukan semata oleh versi spesifikasi yang kebetulan dipakai server penerima.

Temuan kedua menyangkut subdomain. Lima domain memasang sp yang justru lebih longgar daripada p, termasuk tiga yang memakai kombinasi p=reject; sp=none. Domain utamanya terkunci rapat, sementara seluruh subdomainnya dibiarkan tanpa perlindungan sama sekali. Penyerang yang menemui p=reject di domain utama cukup berpindah sasaran ke subdomain mana pun.

Temuan ketiga paling ringkas: tidak satu pun dari 59 domain memasang np. Celah subdomain yang tidak ada masih terbuka lebar di seluruh sampel.

Sampel 69 domain ini bukan potret statistik nasional. Ia dipilih karena mewakili organisasi yang paling sering ditiru dalam penipuan email, sehingga temuannya menggambarkan kondisi kelompok yang justru paling perlu terlindungi.

Laporan yang Datang Setiap Hari ke Alamat rua

Banyak pengelola domain menerima email berisi lampiran aneh dan tidak tahu itu apa. Lampirannya berekstensi ganda seperti .xml.gz, subjeknya menyebut "Report Domain", dan pengirimnya Google atau Yahoo. Itulah laporan agregat DMARC, dikirim karena ada alamat pada tag rua di record Anda.

Bentuknya dokumen XML yang dikompresi gzip, dikirim harian atau lebih sering. Nama berkasnya mengikuti pola tetap: nama penerima, nama domain, waktu mulai, dan waktu selesai, dipisahkan tanda seru.

Laporan DMARC berjalan dari server penerima menjadi berkas XML harian, lalu dikirim ke alamat pada tag rua.

Isinya bukan salinan email, melainkan rekapitulasi. Setiap blok record di dalamnya melaporkan satu alamat IP pengirim beserta jumlah pesan yang dikirimnya dan hasil pemeriksaannya:

<record>
  <row>
    <source_ip>203.0.113.25</source_ip>
    <count>148</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>namadomain.com</header_from>
  </identifiers>
</record>

Blok di atas berbunyi: alamat 203.0.113.25 mengirim 148 pesan atas nama namadomain.com, DKIM-nya lolos, SPF-nya gagal, dan tidak ada tindakan yang diambil karena kebijakannya masih none. Yang Anda cari saat membaca laporan adalah alamat IP yang Anda kenali tetapi hasilnya gagal, karena di situlah pengirim sah yang belum terkonfigurasi benar berada.

Karena isinya XML mentah, membacanya secara manual melelahkan begitu jumlah pengirimnya bertambah. Tersedia layanan yang menerjemahkan laporan ini menjadi tabel dan grafik, sebagian gratis untuk volume kecil. Pilihan lain yang lebih sederhana: arahkan rua ke alamat email khusus, dan buka lampirannya sesekali dengan aplikasi pengolah teks setelah diekstrak.

Satu hal yang perlu Anda pertimbangkan sebelum memasang ruf. Berbeda dari laporan agregat yang hanya berisi angka, laporan kegagalan mengirimkan potongan pesan yang gagal, lengkap dengan header dan kadang isinya. Di sampel kami, 36 dari 59 domain memasangnya. Bila email domain Anda memuat data pribadi pelanggan, memasang ruf berarti mengirimkan cuplikan data itu ke pihak lain.

Cara Membuat Record DMARC di DNS

Cara membuat DMARC record hanya butuh empat langkah, dan tiga di antaranya dikerjakan sekali seumur hidup domain. Yang memakan waktu justru langkah terakhir, karena di situ Anda menunggu data.

Langkah #1: Pastikan SPF dan DKIM sudah aktif

DMARC tidak berguna tanpa keduanya, karena ia hanya membaca hasil pemeriksaan yang mereka lakukan. Google menetapkan syarat waktu yang konkret: SPF dan DKIM harus aktif minimal 48 jam sebelum DMARC dinyalakan. Sebagian besar penyedia layanan email hosting sudah menyediakan kunci DKIM siap salin, sehingga pekerjaan Anda pada langkah ini biasanya sebatas menempelkannya ke DNS.

Langkah #2: Susun record awal dalam mode pemantauan

Record pertama Anda sebaiknya tidak memblokir apa pun. Tujuannya mengumpulkan data, bukan menegakkan aturan:

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

Alamat pada rua boleh alamat mana saja yang Anda baca, termasuk alamat di domain lain. Bila memakai domain lain, pemilik domain tujuan perlu mengizinkannya lewat record tambahan di sisi mereka.

Langkah #3: Tambahkan sebagai TXT record

Di cPanel, menu yang Anda butuhkan bukan Email Deliverability. Menu itu mengurus SPF dan DKIM saja, dan tidak akan membuatkan record DMARC untuk Anda. Yang benar adalah Zone Editor, lalu pilih domainnya, tekan Add Record, dan pilih tipe TXT.

Isi kolom Name dengan _dmarc saja. cPanel menambahkan sendiri nama domainnya begitu kursor berpindah, sehingga hasilnya menjadi _dmarc.namadomain.com. Kolom Record diisi seluruh baris record dari langkah sebelumnya. Bila DNS domain Anda dikelola di tempat lain, misalnya di panel registrar atau penyedia DNS pihak ketiga, langkahnya sama: TXT record dengan nama host _dmarc.

Verifikasi hasilnya dari terminal setelah beberapa menit. Di macOS dan Linux:

dig +short TXT _dmarc.namadomain.com

Perintah dig tidak tersedia secara bawaan di Windows. Padanannya memakai nslookup, yang sudah ada di setiap instalasi Windows:

nslookup -type=TXT _dmarc.namadomain.com

Keluaran yang benar memuat v=DMARC1. Bila kosong, recordnya belum tersebar atau belum tersimpan.

Langkah #4: Baca laporannya, lalu naikkan kebijakannya

Biarkan p=none berjalan sampai laporan agregat menunjukkan seluruh pengirim sah Anda lolos. Setelah itu naikkan ke p=quarantine, dan terakhir ke p=reject. Rentang waktu yang wajar untuk setiap tahap sudah kami bahas terpisah di artikel email spoofing. Sekalian tambahkan sp dan np saat menaikkan kebijakan, karena keduanya tidak ikut naik dengan sendirinya.

Empat Kekeliruan Konfigurasi yang Sering Terjadi

Record yang terlihat ada padahal kosong. Bila _dmarc diarahkan sebagai CNAME ke domain utama, kueri DNS tetap mengembalikan jawaban — tetapi jawabannya adalah record TXT domain utama, berisi SPF dan berbagai kode verifikasi. Tidak ada v=DMARC1 di sana. Kami menemukan satu kasus seperti ini di sampel: dig TXT _dmarc.liputan6.com mengembalikan tiga baris teks, tidak satu pun record DMARC. Yang menentukan bukan ada tidaknya jawaban, melainkan ada tidaknya v=DMARC1 di dalamnya.

Nama host yang tertulis dua kali. Kekeliruan khas panel yang menambahkan nama domain secara otomatis. Anda mengetik _dmarc.namadomain.com di kolom Name, panel menambahkan domainnya lagi, dan recordnya berakhir di _dmarc.namadomain.com.namadomain.com — alamat yang tidak pernah ditanyakan siapa pun. Setelah menyimpan, selalu periksa ulang lewat dig atau nslookup, jangan berhenti di tampilan panel.

Menaikkan p tanpa menaikkan sp. Kombinasi p=reject; sp=none memberi rasa aman yang keliru. Lima domain di sampel kami memakainya, dan tiga di antaranya adalah nama yang dikenal luas.

Menegakkan kebijakan tanpa memasang rua. Salah satu bank di sampel kami menjalankan p=reject; sp=reject tanpa satu pun alamat laporan. Kebijakannya berjalan penuh, tetapi tidak ada informasi yang kembali. Bila suatu saat ada pengirim sah yang tertolak, tidak ada cara mengetahuinya selain menunggu keluhan.

Arti Pesan DMARC yang Sering Membingungkan

Sebagian besar pertanyaan seputar DMARC tidak berawal dari rasa ingin tahu, melainkan dari satu kalimat pendek yang muncul di alat pemindai keamanan atau di email pantulan. Kalimatnya terdengar teknis dan kadang menuduh sesuatu yang sebenarnya tidak salah. Berikut lima yang paling sering ditemui.

"DMARC record published" dan "DMARC quarantine/reject policy not enabled". Keduanya berasal dari alat pemindai kepatuhan, termasuk Secure Score di Microsoft 365, dan sering tertukar karena bunyinya mirip. Sebenarnya keduanya memeriksa hal yang berbeda. Yang pertama sekadar menanyakan apakah domain punya record DMARC. Yang kedua menanyakan apakah recordnya benar-benar menegakkan sesuatu.

Domain dengan p=none akan lolos pemeriksaan pertama dan gagal di pemeriksaan kedua, dan penilaian itu memang tepat. Istilah lain untuk kondisi yang sama adalah "not at enforcement". Perbaikannya bukan menambah record baru, melainkan menaikkan nilai p seperti pada Langkah #4.

dmarc=bestguesspass. Server Microsoft menuliskan nilai ini di header ketika pesan lolos SPF atau DKIM, tetapi domain pengirimnya tidak punya record DMARC sama sekali. Kata "pass" di ujungnya membuat banyak orang mengira konfigurasinya sudah benar. Kenyataannya sebaliknya: nilai itu justru penanda bahwa record DMARC belum ada, dan penerima sedang menebak.

dmarc=temperror dan dmarc=permerror. Keduanya resmi terdaftar di RFC 9989 sebagai hasil pemeriksaan, di samping pass, fail, dan none. Bedanya terletak pada harapan perbaikan. temperror berarti gangguan sementara, umumnya kueri DNS yang gagal atau kehabisan waktu, dan percobaan berikutnya besar kemungkinan berhasil tanpa Anda mengubah apa pun. permerror berarti masalah yang tidak akan sembuh sendiri, biasanya record DMARC yang salah tulis. Melihat temperror sesekali di laporan agregat itu wajar; melihat permerror berarti ada yang harus Anda perbaiki hari itu juga.

"DMARC violation". Istilah ini tidak ada di spesifikasi mana pun. Ia dipakai sebagian gateway email dan produk keamanan sebagai sebutan untuk pesan yang gagal DMARC lalu dikenai kebijakan. Artinya sama dengan dmarc=fail yang berujung pada tindakan, bukan jenis pelanggaran tersendiri.

550 5.7.26 dan 550 5.7.1. Gmail memantulkan pesan dengan bunyi 550 5.7.26 Unauthenticated email from namadomain.com is not accepted due to domain's DMARC policy. Microsoft dan sebagian penyedia lain memakai kode 550 5.7.1 dengan kalimat bernada sama. Ini bukan gangguan di sisi penerima, melainkan kebijakan domain Anda sendiri yang sedang dijalankan. Penyebabnya hampir selalu sama: ada pengirim sah yang belum lolos keselarasan padahal kebijakan sudah dinaikkan. Bacalah alamat IP pengirim di laporan agregat sebelum menurunkan kembali nilai p.

Yang Tidak Bisa Diselesaikan DMARC

Sebelum menganggap urusan ini selesai, ada empat batas yang perlu Anda ketahui.

Hanya pemalsuan domain persis yang tertutup. DMARC bekerja pada domain yang tertulis di header From. Pesan dari namadomaln.com yang ditulis mirip, atau dari alamat asing dengan nama tampilan "Bagian Keuangan", tidak tersentuh sama sekali. Keduanya dikirim dari domain yang memang sah milik pelaku, lengkap dengan SPF dan DKIM yang benar.

Milis dan penerusan otomatis rusak karenanya. Server mailing list mengubah isi pesan saat meneruskannya, dan perubahan sekecil apa pun membatalkan tanda tangan DKIM. Semakin ketat kebijakan Anda, semakin besar kemungkinan pesan Anda tertolak di milis.

Kebijakan yang dinaikkan terburu-buru menjatuhkan email Anda sendiri. Risiko terbesar p=reject bukan berasal dari penyerang, melainkan dari pengirim sah yang belum sempat terdaftar: aplikasi kasir, sistem tiket, notifikasi dari situs web. Semuanya berhenti terkirim tanpa peringatan.

Laporan hanya berguna kalau dibaca. Memasang rua lalu membiarkan laporannya menumpuk di kotak masuk sama saja dengan tidak memasangnya. Kalau tidak ada yang membaca, tetapkan jadwal tetap, misalnya sekali seminggu selama masa pemantauan.

Pertanyaan yang Sering Muncul

Apa bedanya SPF, DKIM, dan DMARC? SPF mendaftar server yang berhak mengirim atas nama domain. DKIM menandatangani isi pesan secara kriptografis. DMARC memakai hasil keduanya, menuntut keselarasan dengan alamat yang dilihat penerima, lalu menentukan tindakan dan meminta laporan. SPF dan DKIM bisa berdiri tanpa DMARC, tetapi DMARC tidak bisa bekerja tanpa keduanya.

Mengapa saya menerima email DMARC? Karena record domain Anda memuat tag rua atau ruf, dan penerima email memenuhi permintaan itu. Lampiran .xml.gz di dalamnya adalah rekapitulasi pengiriman atas nama domain Anda selama satu periode.

Apakah DMARC wajib? Secara teknis tidak, tetapi praktis sudah menjadi syarat. Sejak Februari 2024, Gmail dan Yahoo mewajibkannya bagi pengirim di atas 5.000 pesan per hari, dan Microsoft menyusul untuk Outlook.com pada Mei 2025. Di luar ambang itu pun, domain tanpa DMARC berangkat dengan reputasi minus.

Apakah p=none sudah cukup? Belum, kalau tujuannya melindungi. Kebijakan p=none tidak memblokir satu pesan palsu pun; ia hanya mengumpulkan laporan. Nilainya ada sebagai tahap awal yang wajib dilewati, bukan sebagai tujuan akhir.

Bagaimana kalau domain saya tidak pernah dipakai berkirim email? Justru perlu dilindungi, karena domain tanpa lalu lintas email adalah sasaran empuk. Untuk domain seperti itu, pasang langsung v=DMARC1; p=reject; rua=mailto:... tanpa perlu melalui tahap pemantauan, karena memang tidak ada pengirim sah yang berisiko tertolak.

Kesimpulan

DMARC adalah kebijakan yang menghubungkan hasil pemeriksaan SPF dan DKIM dengan alamat yang benar-benar dibaca penerima, lalu menentukan tindakan saat hubungan itu putus. Isinya sebuah TXT record di _dmarc yang, meski hanya satu baris, menyimpan sebelas tag dengan konsekuensi berbeda-beda.

Kalau Anda mengelola domain yang dipakai berkirim email, satu langkah yang bisa dikerjakan hari ini cukup ringkas: jalankan dig +short TXT _dmarc pada domain Anda, lalu periksa tiga hal. Apakah v=DMARC1 benar-benar ada, apakah masih tercantum pct yang perilakunya kini berubah, dan apakah sp sudah menutup subdomain Anda. Bila ketiganya bersih, sisanya adalah membaca laporan yang datang.

Semoga artikel ini membantu.