Cara Membaca Laporan DMARC Aggregate (rua) XML

Q: Apa beda laporan rua dan ruf?

rua adalah laporan agregat berisi statistik, tanpa isi email. ruf adalah laporan forensik/kegagalan per email yang bisa memuat sebagian header atau isi. Banyak penyedia besar tidak mengirim laporan ruf karena alasan privasi, jadi rua adalah sumber utama.

Q: Kenapa saya tidak menerima laporan sama sekali?

Periksa apakah record DMARC valid dan alamat rua memakai format mailto:. Jika alamatnya di domain lain, pastikan record otorisasi pelaporan eksternal ada. Juga pastikan domain memang mengirim email ke penyedia yang mendukung pelaporan, dan tunggu satu sampai dua hari.

Laporan agregat DMARC (rua) adalah file XML yang dikirim penyedia email seperti Google, Microsoft, atau Yahoo ke alamat di tag rua record DMARC Anda, biasanya sekali sehari. Isinya ringkasan: IP mana saja yang mengirim email atas nama domain Anda, berapa banyak, dan apakah SPF, DKIM, serta DMARC lolos. Cara membacanya: fokus pada setiap blok <record>, lihat source_ip, count, hasil policy_evaluated, lalu cocokkan IP tersebut dengan layanan yang memang Anda pakai.

Panduan ini menjelaskan struktur XML laporan agregat bagian per bagian, memberi contoh nyata yang bisa Anda baca baris demi baris, cara membedakan pengirim sah dari pemalsu, dan cara gratis untuk mengolah laporan tanpa harus membaca XML mentah setiap hari.

Dari mana laporan ini datang?

Laporan hanya dikirim jika record DMARC Anda memuat tag rua:

_dmarc.contohdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@contohdomain.com"

Setiap penyedia yang menerima email atas nama domain Anda dan mendukung pelaporan akan mengirim satu email berisi lampiran terkompresi (.zip atau .gz) per periode laporan. Nama file biasanya mengikuti pola penerima!domainanda!waktu-mulai!waktu-selesai.xml.gz. Interval bawaan yang diminta adalah 86400 detik (sehari), dan sebagian besar penerima memang mengirim harian.

Beberapa hal praktis:

Gunakan kotak surat khusus untuk rua. Domain yang mengirim banyak email bisa menerima puluhan laporan per hari.
Jika alamat rua berada di domain lain (misalnya layanan analisis DMARC), domain penerima harus memublikasikan record otorisasi contohdomain.com._report._dmarc.domainpenerima.com berisi v=DMARC1. Layanan pihak ketiga biasanya sudah mengurus ini.
Tidak semua penerima mengirim laporan. Ketiadaan laporan dari penyedia tertentu tidak berarti email Anda tidak sampai ke sana.

Belum punya record DMARC? Susun dengan DMARC Generator lalu cek dengan DMARC Checker.

Struktur XML laporan agregat

Setelah diekstrak, isi file kira-kira seperti contoh berikut (disederhanakan, IP memakai rentang dokumentasi):

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>1234567890123456789</report_id>
    <date_range>
      <begin>1759536000</begin>
      <end>1759622399</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>contohdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.45</source_ip>
      <count>128</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>contohdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>contohdomain.com</domain>
        <selector>default</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>contohdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>198.51.100.23</source_ip>
      <count>37</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>contohdomain.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>mail-asing.example</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

report_metadata

Menjelaskan siapa yang membuat laporan (org_name), alamat kontaknya, ID laporan, dan periode laporan dalam date_range. Nilai begin dan end adalah Unix timestamp dalam detik (UTC). Anda bisa mengubahnya ke tanggal biasa dengan konverter Timestamp atau perintah date -d @1759536000 di Linux.

policy_published

Salinan kebijakan DMARC Anda menurut pandangan penerima saat laporan dibuat: domain, mode alignment DKIM (adkim) dan SPF (aspf) yaitu r (relaxed) atau s (strict), kebijakan p, kebijakan subdomain sp, dan pct. Bagian ini berguna untuk memastikan perubahan record Anda sudah terbaca. Jika Anda baru mengganti ke quarantine tetapi laporan masih menunjukkan none, berarti penerima masih memakai versi lama yang di-cache.

record dan row

Inilah inti laporan. Setiap <record> mewakili satu kombinasi unik dari IP pengirim dan hasil autentikasi. Di dalam <row>:

source_ip: IP server yang menyerahkan email ke penerima.
count: jumlah email dari IP tersebut dengan hasil yang sama dalam periode laporan.
policy_evaluated: hasil akhir menurut DMARC. dkim dan spf di sini berarti lolos dan selaras dengan domain From, bukan sekadar lolos. disposition menunjukkan tindakan yang diterapkan: none, quarantine, atau reject. Kadang ada elemen reason yang menjelaskan pengecualian, misalnya forwarded atau local_policy.

identifiers

header_from adalah domain di header From yang dilihat penerima email. Ini domain yang dinilai DMARC. Beberapa laporan juga memuat envelope_from.

auth_results

Hasil mentah SPF dan DKIM sebelum dicocokkan dengan From. Di sini Anda melihat domain apa yang benar-benar diuji. Perbedaan antara auth_results dan policy_evaluated adalah kunci diagnosis: pada record kedua di contoh, SPF di auth_results bernilai pass untuk domain mail-asing.example, tetapi policy_evaluated menunjukkan spf fail, karena domain tersebut tidak selaras dengan contohdomain.com. Pola ini dibahas detail di DMARC gagal padahal SPF lolos.

Cara membedakan sumber sah dan pemalsu

Langkah yang bisa Anda ikuti untuk setiap source_ip:

Kelompokkan berdasarkan IP dan jumlah. Mulai dari IP dengan count terbesar. Biasanya sumber utama adalah layanan email resmi Anda.
Cari reverse DNS-nya. Jalankan dig -x 198.51.100.23 +short. Hostname seperti mail-*.google.com, *.outbound.protection.outlook.com, atau hostname server hosting Anda memberi petunjuk kuat.
Cocokkan dengan inventaris pengirim. Daftar semua yang mengirim atas nama domain Anda: server hosting, Google Workspace/Microsoft 365, aplikasi web, newsletter, CRM, sistem tiket, payment gateway yang mengirim kuitansi.
Periksa domain di auth_results. Jika DKIM lolos untuk domain milik ESP (misalnya domain bawaan layanan newsletter), itu sumber sah yang belum dikonfigurasi alignment-nya.
Tandai sisanya. IP yang tidak Anda kenal, dari jaringan acak, dengan SPF dan DKIM gagal total, kemungkinan besar pemalsuan atau spam yang memakai domain Anda.

Pola yang sering muncul

Pola di laporan	Kemungkinan arti	Tindakan
dkim pass, spf pass (policy_evaluated)	Sumber sah dan terkonfigurasi benar	Tidak ada
auth_results pass untuk domain ESP, policy_evaluated fail	Layanan sah tanpa alignment	Verifikasi domain di ESP: DKIM kustom dan/atau Return-Path kustom
spf fail, dkim pass, IP milik penyedia email besar	Email diteruskan (forwarding) atau mailing list	Biasanya aman bila DKIM tetap selaras
spf fail, dkim fail, IP tak dikenal	Pemalsuan atau spam	Biarkan, lalu perketat kebijakan DMARC
spf fail, dkim fail, IP server hosting Anda	Aplikasi Anda sendiri yang belum diautentikasi	Tambahkan ke SPF, aktifkan DKIM

Untuk mengecek apakah IP tertentu sudah tercakup SPF, gunakan SPF Checker.

Dapatkan Update Terbaru

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

Satu kebiasaan yang membantu: simpan daftar IP atau hostname yang sudah Anda verifikasi sebagai sumber sah, beserta nama layanannya. Setiap kali membaca laporan baru, Anda cukup memeriksa IP yang belum ada di daftar itu. Dengan begitu, pekerjaan membaca laporan menyusut dari puluhan baris menjadi beberapa baris yang benar-benar perlu diselidiki, dan Anda lebih cepat menyadari jika ada layanan baru yang mulai mengirim atas nama domain Anda.

Cara gratis mengolah laporan

1. Membaca manual untuk domain kecil

Untuk domain dengan volume rendah, membuka file XML di browser atau editor sudah cukup. Ekstrak dulu:

gunzip google.com\!contohdomain.com\!1759536000\!1759622399.xml.gz
# atau untuk .zip
unzip laporan.zip

2. Skrip Python sederhana

Skrip berikut membaca satu file XML dan mencetak ringkasan per IP:

import sys
import xml.etree.ElementTree as ET

root = ET.parse(sys.argv[1]).getroot()
org = root.findtext("report_metadata/org_name")
print(f"Laporan dari: {org}")

for rec in root.findall("record"):
    ip = rec.findtext("row/source_ip") or "-"
    count = rec.findtext("row/count") or "-"
    dkim = rec.findtext("row/policy_evaluated/dkim") or "-"
    spf = rec.findtext("row/policy_evaluated/spf") or "-"
    hfrom = rec.findtext("identifiers/header_from") or "-"
    print(f"{ip:40} {count:>6}  dkim={dkim:5} spf={spf:5} from={hfrom}")

Jalankan dengan python3 ringkas_dmarc.py laporan.xml. Untuk banyak file, bungkus dalam loop dan tulis ke CSV.

3. parsedmarc (open source)

parsedmarc adalah alat open source berbasis Python yang bisa membaca laporan dari file atau langsung dari kotak surat lewat IMAP, lalu mengekspor ke JSON/CSV atau ke Elasticsearch/OpenSearch untuk dibuat dasbor. Cocok jika Anda punya server sendiri dan ingin mengolah laporan secara otomatis.

pip install parsedmarc
parsedmarc -o hasil/ laporan/*.xml.gz

4. Layanan analisis DMARC dengan paket gratis

Beberapa penyedia layanan DMARC menawarkan paket gratis dengan batas volume, yang menerima laporan di alamat rua milik mereka dan menampilkan grafik. Ketentuan dan batasnya berubah dari waktu ke waktu, jadi periksa langsung di situs penyedia sebelum memakai, dan pertimbangkan bahwa laporan berisi metadata pengiriman email domain Anda.

Kesalahan umum saat membaca laporan

Menganggap auth_results pass berarti DMARC lolos. Yang menentukan adalah policy_evaluated.
Panik melihat IP asing. Forwarding dan mailing list wajar menghasilkan SPF gagal. Lihat apakah DKIM tetap lolos dan selaras.
Langsung ke p=reject sebelum semua sumber sah lolos. Email sah ikut ditolak.
Mengabaikan subdomain. Bila subdomain mengirim email, perhatikan header_from dan tag sp.
Hanya melihat satu hari. Sumber yang mengirim mingguan atau bulanan (misalnya invoice) bisa terlewat. Amati minimal beberapa minggu.

Checklist

Record DMARC punya rua ke kotak surat khusus.
Laporan diekstrak dan diringkas per source_ip.
Setiap IP dengan volume signifikan sudah dipetakan ke layanan tertentu.
Sumber sah yang gagal alignment sudah diperbaiki (SPF/DKIM kustom).
Setelah beberapa minggu bersih, kebijakan dinaikkan bertahap.

FAQ

Apa beda laporan rua dan ruf?

rua adalah laporan agregat berisi statistik, tanpa isi email. ruf adalah laporan forensik/kegagalan per email yang bisa memuat sebagian header atau isi. Banyak penyedia besar tidak mengirim laporan ruf karena alasan privasi, jadi rua adalah sumber utama.

Kenapa saya tidak menerima laporan sama sekali?

Periksa apakah record DMARC valid dan alamat rua memakai format mailto:. Jika alamatnya di domain lain, pastikan record otorisasi pelaporan eksternal ada. Juga pastikan domain memang mengirim email ke penyedia yang mendukung pelaporan, dan tunggu satu sampai dua hari.

Apakah IP di source_ip pasti penyerang jika tidak saya kenal?

Tidak selalu. Bisa jadi layanan yang dipakai rekan kerja tanpa sepengetahuan Anda, server forwarding, atau mailing list. Telusuri reverse DNS dan pemilik jaringan (whois) sebelum menyimpulkan.

Seberapa sering saya perlu membaca laporan?

Saat awal memasang DMARC, periksa beberapa kali seminggu. Setelah kebijakan stabil di quarantine atau reject, ringkasan mingguan atau bulanan biasanya cukup, kecuali Anda menambah layanan pengirim baru.