Baca laporan DMARC Anda

Kalau domain Anda punya rekaman DMARC, penyedia email besar mengirimkan laporan harian (sebuah file XML terkompresi) yang mendaftar setiap server yang mengirim email atas nama domain Anda. Ini satu-satunya daftar yang akan pernah Anda dapatkan tentang segala sesuatu yang mengirim atas nama Anda — termasuk bagian dari perusahaan Anda sendiri yang sudah Anda lupakan.

Memuat alat…

Cara kerjanya

  1. Simpan lampiran laporannya dari kotak surat yang disebutkan rekaman DMARC Anda (alamat rua=), atau seret langsung keluar dari pesannya.
  2. Lepaskan semuanya sekaligus di sini — .xml, .xml.gz, dan .zip semuanya dikenali.
  3. Lihat dulu sumber-sumber yang gagal: masing-masing adalah entah milik Anda sendiri yang perlu diperbaiki, atau seseorang yang memalsukan domain Anda.

Kenapa tidak ada yang diunggah

Semua yang dikerjakan halaman ini dijalankan oleh kode di dalam tab peramban Anda, memakai mesin yang sama dengan yang menampilkan halaman web. File dibaca dari disk ke memori tab Anda, diolah di sana, lalu ditulis kembali sebagai unduhan. File itu tidak pernah dikirim ke mana pun — tidak ke kami, tidak ke pihak ketiga.

Buktikan sendiri

  1. Buka alat pengembang peramban Anda (F12) lalu pilih tab “Network” (Jaringan).
  2. Muat file Anda dan jalankan alatnya.
  3. Permintaan yang akan Anda lihat hanya mengambil kode alat itu sendiri — dan, pada beberapa alat berat, mesin sumber terbukanya dari CDN publik — ditambah satu ping kunjungan halaman yang kecil ke loreatec.jp (alamat dan judul halaman, tidak lebih). Tidak satu pun membawa file Anda.

Bukti semuanya tetap lokal →

Pertanyaan yang sering diajukan

Kenapa laporan saya datang sebagai .gz dan .zip?

Standarnya membiarkan tiap organisasi pelapor memilih sendiri. Google mengirim .zip, Microsoft dan kebanyakan lainnya mengirim .xml.gz. Alat pembaca ini membuka ketiganya di peramban — gzip lewat fitur dekompresi bawaan peramban, zip lewat sebuah pustaka open-source yang disertakan.

Sebuah sumber menunjukkan SPF lolos tapi DMARC gagal. Bagaimana bisa?

Itulah yang disebut DMARC sebagai “alignment” (keselarasan). SPF lolos berarti ada sebuah domain yang mengizinkan server itu — tetapi domain yang diperiksa adalah alamat pengirim balik yang tersembunyi, bukan baris From yang dilihat penerima Anda. DMARC juga mensyaratkan keduanya harus cocok. Sebuah layanan pengirim email yang mengirim dengan alamat pengirim baliknya sendiri lolos SPF untuk dirinya sendiri, tapi gagal alignment untuk Anda. Perbaikannya adalah mengatur alamat pengirim balik (return-path) khusus bersama layanan itu — atau mengandalkan DKIM yang ditandatangani dengan domain Anda sendiri.

Apa yang sebaiknya saya lakukan sebelum pindah ke p=reject?

Setiap sumber yang gagal di tabel ini harus diidentifikasi lebih dulu. Sebagian akan sah — server lama, sebuah CRM, penyedia pembayaran, sebuah scanner. Masing-masing perlu SPF atau DKIM yang diatur dengan benar. Yang tersisa setelah itu adalah pemalsuan, dan menolaknya itulah seluruh tujuannya. Kalau Anda beralih ke reject sementara masih ada sumber yang belum teridentifikasi di daftarnya, email yang sungguhan akan hilang tanpa peringatan.

Apakah file-file ini keluar dari peramban saya?

Tidak. File-file itu didekompresi dan dibaca strukturnya di sini. Ini lebih penting dari biasanya untuk laporan DMARC: laporan itu berisi alamat IP dari segala sesuatu yang mengirim atas nama Anda, yang pada dasarnya adalah peta infrastruktur Anda.

Bagaimana dengan laporan forensik (ruf)?

Laporan itu bukan ringkasan — masing-masing adalah satu pesan gagal yang utuh, dikirim kepada Anda sebagai email biasa. Buka salah satunya dengan alat pembaca .eml atau penganalisis header. Kebanyakan penerima besar tidak mengirimkannya sama sekali, karena alasan privasi.