Periksa rekaman DMARC, atau buat baru
Rekaman DMARC adalah satu baris berisi sampai sebelas pengaturan, dan dua di antaranya menentukan apakah rekaman itu berfungsi sama sekali. Alat ini membacakannya dengan kata-kata sederhana, lalu memeriksa satu hal yang bisa diam-diam menghentikan laporan Anda supaya tidak pernah sampai.
- Berjalan di peramban Anda, bukan di server kami
- Tanpa pendaftaran
- Tanpa watermark
Memuat alat…
Cara kerjanya
- Ketik domain Anda lalu tekan “Check” (periksa).
- Baca pengaturan dan temuannya: p= (kebijakannya) adalah yang ditindaklanjuti penerima, dan pct= membatasi berapa persen email Anda yang terkena kebijakan itu.
- Kalau laporan Anda dikirim ke alamat di perusahaan lain, periksa blok izinnya — tanpa rekaman itu, laporan tidak akan pernah sampai.
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
- Buka alat pengembang peramban Anda (F12) lalu pilih tab “Network” (Jaringan).
- Muat file Anda dan jalankan alatnya.
- 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.
Pertanyaan yang sering diajukan
Saya sudah mengatur DMARC tapi laporannya tidak pernah datang. Kenapa?
Kalau alamat laporannya (rua) berada di domain yang berbeda dari domain Anda — penyedia analitik, agensi Anda, sebuah kotak surat pribadi — domain itu harus mempublikasikan sebuah rekaman yang menyatakan ia menerima laporan untuk Anda: domainanda._report._dmarc.domainmereka dengan nilai v=DMARC1. Penerima memeriksanya sebelum mengirim, dan diam-diam tidak mengirim apa pun kalau rekaman itu tidak ada. Halaman ini memeriksanya untuk Anda. Penyebab umum lainnya sesederhana “mailto:” yang lupa dituliskan di depan alamatnya.
Sebenarnya apa yang diubah oleh adkim dan aspf?
Keduanya menentukan seberapa dekat domain yang lolos SPF atau DKIM harus cocok dengan alamat From yang dilihat orang. Relaxed (bawaan) menerima subdomain apa pun dari organisasi yang sama — mail.example.com dihitung cocok untuk example.com. Strict mensyaratkan kecocokan persis. Relaxed sudah tepat untuk hampir semua orang; strict untuk organisasi yang mengendalikan setiap subdomainnya dan ingin mencegah subdomain yang diretas dipakai orang lain.
Apakah p=none itu percuma?
Itu langkah pertama yang memang perlu, tapi langkah akhir yang buruk. Dengan p=none tidak ada yang berubah pada email Anda, tapi Anda menerima laporannya — persis yang Anda butuhkan selama beberapa minggu yang diperlukan untuk menemukan setiap pengirim yang sah. Kalau dibiarkan di none bertahun-tahun, itu tidak melindungi apa pun: siapa pun masih bisa mengirim atas nama domain Anda, dan sekarang Anda punya rekaman yang menyatakan Anda sudah tahu itu.
Untuk apa sp=?
Kebijakan terpisah untuk subdomain. Tanpa itu, subdomain mewarisi p=. Ini penting karena penyerang memakai subdomain yang memang tidak pernah diatur untuk mengirim email sama sekali — invoice.domainanda.com — sehingga tidak ada risiko apa pun kalau Anda mengatur sp=reject, bahkan selagi domain utamanya masih di none.
Bagaimana dengan pct?
Ini menerapkan kebijakannya hanya pada sebagian persen dari email yang gagal, jadi Anda bisa pindah ke quarantine di angka 10% lalu mengamatinya. Ini jalan menanjak, bukan tujuan akhir: pada pct=50 dengan p=reject, separuh dari pemalsuannya masih lolos.