Biasakan Baca Laporan DMARC rua Tiap Minggu agar Pengirim Liar Cepat Ketahuan

Record DMARC sudah dipasang, ada rua=mailto:... di dalamnya, tapi kotak masuk alamat itu tidak pernah dibuka. Isinya tumpukan lampiran .zip dan .gz yang kelihatannya cuma noise. Padahal di situlah layanan pihak ketiga yang belum lolos SPF atau DKIM pertama kali kelihatan, biasanya jauh sebelum ada yang mengeluh email masuk spam. Artikel ini menelusuri masalahnya dari gejala ke akar penyebab. Setelah itu kita jadikan pembacaan laporan sebagai rutinitas mingguan yang ringan.

Gejalanya biasanya datang dari tiket, bukan dari laporan

Pola yang sering muncul di meja support kira-kira begini. Email dari sistem invoice, CRM, atau newsletter mendadak masuk spam di sisi penerima, atau malah ditolak. Pemilik domain merasa tidak mengubah apa-apa. Email dari mailbox biasa juga normal-normal saja. Yang sering terjadi, tim lain menambahkan layanan pengirim baru tanpa mengatur SPF atau DKIM untuk domain kita. Selama policy DMARC masih p=none, email itu tetap terkirim, jadi tidak ada yang sadar. Begitu policy dinaikkan ke quarantine atau reject, atau penerima memperketat filternya sendiri, baru masalahnya terasa. Informasi bahwa ada IP asing yang mengirim atas nama domain kita sebenarnya sudah tercatat. Tempatnya di laporan aggregate DMARC, yaitu ringkasan dalam format XML yang dikirim penyedia email penerima ke alamat rua. Isinya daftar IP yang mengirim email dengan domain kita di header From, beserta hasil SPF dan DKIM-nya.

Pastikan laporan memang sampai ke alamat rua

Sebelum membaca isinya, pastikan laporannya memang datang. Ada beberapa hal yang sering membuat kotak rua kosong. Pertama, cek record-nya. Typo di tag atau di alamat email cukup untuk membuat laporan tidak pernah terkirim.

BASH

# Cek record DMARC domain
dig +short TXT _dmarc.example.com

# Jika alamat rua ada di domain lain, cek record otorisasinya
dig +short TXT example.com._report._dmarc.reportdomain.net

Perintah kedua penting kalau rua mengarah ke domain lain, misalnya rua=mailto:[email protected] untuk domain example.com. Penerima laporan biasanya mengecek dulu apakah domain tujuan mengizinkan menerima laporan untuk domain kita. Caranya lewat record TXT berisi v=DMARC1 di nama tersebut. Kalau record ini tidak ada, laporan bisa tidak dikirim sama sekali. Kalau rua ada di domain yang sama, langkah ini tidak perlu. Kedua, cek mailbox-nya. Kuota yang penuh, filter yang membuang lampiran terkompresi, atau forwarder yang sudah mati juga sering jadi penyebab. Kalau record benar dan mailbox sehat, laporan dari penerima besar biasanya mulai masuk dalam satu atau dua hari.

Membaca satu record di laporan aggregate

Setiap laporan berisi metadata (siapa yang melapor dan periode laporannya), policy yang terbaca dari DNS kita, lalu satu atau lebih elemen record. Satu record mewakili satu kombinasi IP sumber dan hasil autentikasi. Elemen ini menyimpan jumlah pesan, bukan isi pesan. Contoh format output berikut disederhanakan, dengan domain dan IP dokumentasi:

XML

<feedback>
  <report_metadata>
    <org_name>receiver.example</org_name>
    <report_id>contoh-12345</report_id>
    <date_range>
      <begin>1700000000</begin>
      <end>1700086400</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.25</source_ip>
      <count>40</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>vendor-mail.example</domain>
        <selector>s1</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounce.vendor-mail.example</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Cara bacanya: dari IP 198.51.100.25 ada contoh 40 pesan dengan From example.com. disposition adalah tindakan yang diambil penerima. Nilainya none karena policy kita masih p=none. Bagian policy_evaluated adalah hasil DMARC yang sebenarnya, dan di contoh ini keduanya fail.

Jebakan: auth_results pass, tapi DMARC tetap fail

Di sinilah banyak orang salah baca. Bagian auth_results di contoh tadi menunjukkan DKIM pass dan SPF pass. Sekilas terlihat beres. Lalu kenapa policy_evaluated justru fail? Jawabannya ada di alignment. auth_results hanya mencatat bahwa tanda tangan DKIM valid dan SPF lolos, tanpa peduli untuk domain apa. DMARC punya syarat tambahan: domain yang lolos harus sejalan (aligned) dengan domain di header From. Di contoh tadi, DKIM ditandatangani oleh vendor-mail.example, dan SPF dicek terhadap bounce.vendor-mail.example. Keduanya bukan example.com, jadi tidak aligned. Dengan mode relaxed (r), subdomain dari domain organisasi yang sama masih dianggap aligned, misalnya mail.example.com untuk From example.com. Domain milik vendor jelas tidak termasuk. Pola ini khas layanan pihak ketiga yang dipakai dengan pengaturan default. Layanannya sah, email-nya autentik, tapi atas nama domain mereka sendiri. Jangan berhenti di auth_results. Selalu lihat policy_evaluated, lalu bandingkan domain di auth_results dengan header_from. Perbaikannya biasanya ada di sisi pengaturan layanan, bukan di record DMARC kita. Aktifkan DKIM dengan domain sendiri (vendor memberi record CNAME atau TXT untuk dipasang), atau atur return-path/bounce domain ke subdomain milik kita lalu tambahkan include SPF yang sesuai. Fitur ini tersedia atau tidak tergantung layanannya, jadi cek dokumentasi masing-masing.

Memilah sumber kirim: sah, belum aligned, forwarder, atau liar

Setelah bisa membaca satu record, langkah berikutnya memilah semua IP di laporan. Ekstrak dulu lampirannya. Nama file laporan sering mengandung tanda !, jadi bungkus dengan tanda kutip tunggal agar bash tidak salah mengartikannya.

BASH

# Ekstrak laporan (format kompresi tergantung pengirim laporan)
gunzip -c 'receiver.example!example.com!1700000000!1700086400.xml.gz' > laporan.xml
unzip -p 'laporan.zip' > laporan.xml

# Lihat semua source_ip dan jumlah pesannya
grep -E '<source_ip>|<count>' laporan.xml

# Reverse DNS untuk menebak pemilik IP
dig -x 198.51.100.25 +short

# Konversi date_range ke tanggal (sintaks GNU date)
date -u -d @1700000000

Semua perintah di atas read-only dan aman dijalankan. Dari situ, setiap IP biasanya masuk salah satu dari empat kelompok. Kelompok pertama adalah sumber sah yang sudah aligned. Contohnya server mail kita sendiri atau layanan email bisnis yang sudah dikonfigurasi dengan benar. policy_evaluated minimal salah satunya pass. Tidak ada yang perlu dilakukan selain mencatatnya sebagai sumber yang dikenal. Kelompok kedua adalah sumber sah yang belum aligned, seperti contoh vendor tadi. Reverse DNS atau domain di auth_results biasanya langsung menunjukkan layanannya. Kelompok inilah yang paling penting ditemukan lebih awal, karena merekalah yang akan kena saat policy diperketat. Kelompok ketiga adalah forwarder dan mailing list. IP-nya milik penyedia email lain, SPF fail karena pesan diteruskan dari IP mereka, tapi DKIM sering masih pass dan aligned kalau isi pesan tidak diubah. Mailing list yang menambahkan footer atau mengubah subject biasanya merusak DKIM. Kelompok ini umumnya tidak perlu dikejar dengan mengubah SPF. Kelompok keempat adalah pengirim liar. IP-nya tidak dikenal, tidak ada hubungan dengan layanan yang kita pakai, dan SPF serta DKIM sama-sama fail. Ini spoofing. Kita tidak bisa memperbaikinya dari sisi sumber, dan memang itulah gunanya p=quarantine atau p=reject. Satu hal penting: jangan pernah menambahkan IP liar ke SPF supaya laporannya terlihat bersih. Ada satu kasus yang perlu perhatian khusus. Kalau IP yang muncul ternyata IP server hosting kita sendiri, tapi volumenya tidak wajar atau tidak ada aplikasi yang seharusnya mengirim email, curigai skrip yang disusupi. Langkah pelacakannya ada di Hosting Diblokir karena Spam Padahal Tidak Kirim Email? Lacak Skrip PHP-nya.

Jadikan rutinitas mingguan

Laporan biasanya datang harian dari tiap penerima besar. Membacanya setiap hari terasa berlebihan untuk kebanyakan domain, sedangkan sebulan sekali sering sudah terlambat. Seminggu sekali biasanya cukup untuk menangkap sumber baru sebelum ada keluhan. Rutinitasnya bisa sederhana. Simpan daftar sumber kirim yang dikenal di satu file teks: IP atau rentang IP, nama layanannya, dan status alignment-nya. Setiap minggu, ekstrak laporan yang masuk, tarik semua source_ip, lalu bandingkan dengan daftar itu. Yang perlu diperhatikan hanya IP baru dan sumber lama yang tiba-tiba fail. Sisanya bisa dilewati. Kalau volume laporan sudah terlalu besar untuk dibaca lewat grep, pertimbangkan parser atau dashboard DMARC. Pastikan dulu bagaimana layanan itu menyimpan data laporan kita. Kebiasaan ini juga paling berguna sebelum menaikkan policy. Kalau beberapa minggu berturut-turut tidak ada sumber sah yang masih fail, perpindahan dari p=none ke p=quarantine bisa dilakukan dengan lebih tenang. Ada tim yang mulai memakai layanan pengirim baru? Cek laporan minggu berikutnya dan pastikan layanan itu sudah masuk kelompok pertama, bukan kedua. Intinya, alamat rua yang tidak pernah dibaca sama saja dengan tidak memasang rua. Sediakan waktu sebentar tiap minggu, selalu lihat policy_evaluated dan bandingkan dengan header_from, lalu pisahkan vendor yang belum aligned dari spoofing. Dengan begitu, sebagian besar tiket email masuk spam bisa dicegah sebelum sempat dibuka.