Alat Validasi Catatan DMARC Terbaik

DMARC adalah singkatan dari Domain-based Message Authentication, Reporting, and Conformance. Ini adalah catatan TXT DNS yang diterbitkan di `_dmarc.yourdomain.com` yang memberi tahu server email penerima apa yang harus dilakukan ketika email yang mengaku dari domain Anda gagal dalam pemeriksaan autentikasi. Tanpa DMARC, siapa pun dapat mengirim email yang tampak berasal dari domain Anda - teknik yang disebut spoofing domain yang digunakan dalam serangan phishing dan Business Email Compromise.

Catatan DMARC melakukan dua hal: menetapkan kebijakan (tindakan apa yang diambil terhadap pesan yang gagal) dan mengonfigurasi pelaporan (ke mana ringkasan hasil autentikasi dikirim). Kebijakan bisa `none` (pantau tanpa tindakan), `quarantine` (kirim ke spam), atau `reject` (blokir pesan sepenuhnya). Tag pelaporan menentukan alamat email yang menerima laporan agregat XML harian dari penyedia email utama.

Struktur catatan DMARC

# Catatan hanya pemantauan (titik awal yang aman)
v=DMARC1; p=none; rua=mailto:[email protected]

# Karantina dengan penegakan parsial dan laporan forensik
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r

# Penolakan penuh - gunakan hanya setelah memastikan semua pengirim lolos
v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s

• v=DMARC1: Tag versi - wajib, harus di awal, persis seperti yang tertulis.
• p=: Kebijakan yang diterapkan pada domain - `none`, `quarantine`, atau `reject`.
• sp=: Kebijakan subdomain - mengganti p= untuk subdomain jika diatur.
• rua=: Tujuan laporan agregat - URI mailto: (atau URI layanan pelaporan).
• ruf=: Tujuan laporan forensik - laporan kegagalan individual (lebih jarang, ada implikasi privasi).
• pct=: Persentase pesan yang dikenai kebijakan - berguna untuk peluncuran bertahap (1-100).
• adkim=: Mode penyelarasan DKIM - `r` (relaxed) atau `s` (strict).
• aspf=: Mode penyelarasan SPF - `r` (relaxed) atau `s` (strict).

DMARC tidak mengautentikasi email dengan sendirinya - ini adalah lapisan orkestrasi di atas SPF dan DKIM. Ketika server email penerima menerima email yang mengaku dari domain Anda, ia memeriksa dua hal: apakah pesan lolos SPF atau DKIM, dan apakah domain yang terautentikasi selaras dengan domain di header From? Jika setidaknya salah satunya lolos dan selaras, DMARC lolos. Jika tidak ada yang lolos dengan penyelarasan, server penerima menerapkan kebijakan dalam catatan DMARC Anda.

Autentikasi dan penyelarasan SPF

SPF (Sender Policy Framework) mengatur server email mana yang diizinkan mengirim email atas nama domain Anda. Pemeriksaan dilakukan terhadap pengirim amplop SMTP (alamat `MAIL FROM`), bukan header From yang terlihat. Untuk penyelarasan DMARC, domain di `MAIL FROM` harus cocok (atau menjadi subdomain, dalam mode relaxed) dengan domain header From. Saat mengirim melalui layanan pihak ketiga seperti Mailchimp atau SendGrid, domain return-path mereka sering kali `mailchimp.com` - ini merusak penyelarasan SPF kecuali Anda mengonfigurasi subdomain return-path khusus. Gunakan SPF Record Validator untuk memeriksa catatan SPF Anda dari kesalahan sintaks dan pelanggaran batas lookup sebelum mengandalkannya untuk penyelarasan DMARC.

Autentikasi dan penyelarasan DKIM

DKIM (DomainKeys Identified Mail) menambahkan tanda tangan kriptografis pada email keluar. Tanda tangan menyertakan tag `d=` yang menentukan domain penandatangan. Untuk penyelarasan DMARC, domain `d=` harus cocok (atau menjadi subdomain, dalam mode relaxed) dengan domain header From. Penyelarasan DKIM lebih tangguh untuk pengirim pihak ketiga karena Anda dapat mengonfigurasi mereka untuk menandatangani dengan domain Anda sendiri, bukan milik mereka. DKIM Record Validator memeriksa apakah catatan DNS kunci publik untuk selektor tertentu terformat dengan benar dan dapat diakses.

Untuk lolos autentikasi DMARC, pesan harus diautentikasi oleh SPF atau DKIM, dan domain yang mengautentikasi harus selaras dengan domain di header From.

Memvalidasi catatan DMARC memerlukan pemeriksaan tiga hal: bahwa catatan DNS ada dan dapat diakses, bahwa sintaksnya benar, dan bahwa SPF dan DKIM dikonfigurasi untuk mendukung penyelarasan yang dibutuhkan DMARC. Setiap langkah dapat dilakukan dengan cepat menggunakan alat yang tepat.

Sebagian besar masalah validasi DMARC termasuk dalam kategori yang dapat diprediksi. Banyak yang merupakan kesalahan sintaks sederhana yang langsung ditemukan validator; lainnya adalah masalah konfigurasi yang lebih halus yang memerlukan pemahaman penyelarasan untuk diagnosis yang tepat.

Kesalahan sintaks dan tag

• v=DMARC1 tidak ada sebagai tag pertama: Tag versi harus menjadi field pertama. Jika tag lain mendahuluinya, catatan tidak valid.
• Tag p= hilang: Tag kebijakan wajib ada. Catatan tanpa p= rusak dan diabaikan oleh sebagian besar server email.
• Nilai p= tidak valid: Hanya `none`, `quarantine`, dan `reject` yang valid. Nilai lain (mis. `monitor`) membuat catatan ditolak.
• Titik koma hilang antar tag: Tag harus dipisahkan titik koma. Pemisah yang hilang membuat parser menggabungkan dua tag menjadi satu tag tidak valid.
• Spasi di sekitar tanda =: `p = none` (dengan spasi) tidak valid di beberapa parser. Gunakan `p=none` tanpa spasi.
• Format URI rua= tidak valid: Nilai rua= harus berupa URI `mailto:` yang valid. Alamat email biasa tanpa `mailto:` adalah kesalahan sintaks.

Kesalahan penyelarasan dan autentikasi

Kesalahan penyelarasan lebih sulit didiagnosis daripada kesalahan sintaks karena memerlukan pemahaman header email. Skenario paling umum: Anda mengonfigurasi SPF dengan benar untuk pengiriman langsung dari server email sendiri, tetapi ketika email dikirim melalui platform pemasaran pihak ketiga, `MAIL FROM` menggunakan domain platform tersebut - merusak penyelarasan SPF. Solusinya adalah mengonfigurasi penandatanganan DKIM dengan domain Anda sendiri di platform pihak ketiga, atau menyiapkan subdomain return-path khusus yang dipetakan ke domain Anda.

Kesalahan paling umum dalam penerapan DMARC adalah menetapkan `p=reject` sebelum memastikan semua aliran email sah terautentikasi dengan benar. Email dari layanan pengiriman yang terlupakan - platform email transaksional, CRM, sistem tiket, integrasi mitra - akan diblokir secara diam-diam, dan pengirim mungkin tidak menyadarinya sampai menerima laporan keluhan atau pengguna melaporkan email yang hilang.

Peluncuran tiga fase

Peluncuran DMARC yang aman mengikuti tiga fase. Dalam Fase 1 (minggu 1-4), terbitkan `p=none` dengan alamat pelaporan `rua=` dan tinjau laporan agregat untuk mengidentifikasi semua sumber pengiriman beserta tingkat keberhasilannya. Dalam Fase 2 (minggu 5-10), pindah ke `p=quarantine; pct=10` dan tingkatkan `pct=` secara bertahap saat laporan mengonfirmasi perbaikan tingkat keberhasilan - mulai dari 10% berarti hanya 10% pesan yang gagal dikarantina, membatasi radius dampak. Dalam Fase 3 (mulai minggu ke-11), pindah ke `p=reject` setelah semua pengirim sah secara konsisten lolos dan laporan agregat Anda menunjukkan kegagalan autentikasi minimal atau tidak ada dari sumber sah.

Yang perlu dicari dalam laporan agregat

Laporan agregat menunjukkan setiap sumber yang mengirim email mengaku dari domain Anda. Cari server email Anda sendiri, penyedia layanan email Anda, dan semua pengirim pihak ketiga yang berwenang - semuanya harus menunjukkan tingkat keberhasilan tinggi untuk SPF dan DKIM. Sumber apa pun dengan volume signifikan dan tingkat keberhasilan rendah perlu diselidiki: baik itu pengirim sah yang perlu memperbaiki autentikasinya, atau pengirim tidak berwenang yang harus diblokir penegakan. DMARC Policy Rollout Planner memandu Anda menafsirkan sinyal-sinyal ini dan memilih waktu yang tepat untuk setiap transisi fase.

Pelaporan DMARC adalah umpan balik yang membuat penegakan aman. Tanpa laporan agregat, Anda terbang buta - Anda tidak bisa tahu sumber mana yang lolos atau gagal autentikasi, atau apakah perubahan infrastruktur pengiriman baru-baru ini merusak sesuatu. Menyiapkan pelaporan dengan benar sama pentingnya dengan menyiapkan kebijakannya sendiri.

Laporan agregat (rua=)

Tag `rua=` menentukan URI `mailto:` yang menerima laporan agregat XML harian dari setiap penyedia email utama (Google, Microsoft, Yahoo, dll.) yang menangani email dari domain Anda. Setiap laporan adalah file XML terkompresi yang menampilkan jumlah pesan, IP sumber, hasil SPF/DKIM/DMARC, dan disposisi kebijakan. Alamat penerima harus berada di domain yang sama dengan catatan DMARC, atau berupa URI lintas domain dengan catatan izin yang diterbitkan di domain pihak ketiga. Sebagian besar organisasi menggunakan layanan pelaporan DMARC khusus alih-alih kotak masuk langsung, karena laporan XML mentah membutuhkan alat penguraian agar berguna.

Laporan forensik (ruf=)

Tag `ruf=` mengonfigurasi laporan forensik (kegagalan) - salinan individual pesan yang gagal DMARC. Ini berisi lebih banyak detail daripada laporan agregat tetapi memiliki implikasi privasi: bisa menyertakan header email, dan beberapa penyedia berhenti mengirimkannya karena pertimbangan GDPR. Sebagian besar praktisi DMARC hanya menggunakan `rua=` untuk data agregat dan menghilangkan `ruf=` kecuali analisis forensik atas kasus kegagalan tertentu diperlukan.

Layanan pelaporan DMARC pihak ketiga

• Google Postmaster Tools: Dasbor gratis yang menampilkan reputasi domain Anda dan tingkat keberhasilan autentikasi email dari sudut pandang Gmail.
• Postmark DMARC: Pengurai laporan agregat gratis dengan dasbor visual - bagus untuk memulai tanpa layanan berbayar.
• Dmarcian: Platform berbayar komprehensif dengan analisis per sumber, peringatan masalah autentikasi, dan panduan peluncuran.
• Valimail: Platform DMARC kelas perusahaan dengan rekomendasi penegakan otomatis berdasarkan analisis laporan.
• EasyDMARC: Platform pemantauan dan pengelolaan DMARC kelas menengah dengan wawasan yang dapat ditindaklanjuti per sumber pengiriman.

Mengikuti praktik-praktik ini memastikan penerapan DMARC Anda memberikan perlindungan nyata tanpa mengganggu email sah, dan konfigurasi Anda tetap benar seiring berkembangnya infrastruktur pengiriman Anda.

Selalu validasi seluruh tumpukan autentikasi email

Catatan DMARC hanya seefektif catatan SPF dan DKIM yang mendukungnya. Validasi ketiganya bersama-sama: gunakan DMARC Record Validator untuk catatan kebijakan, SPF Record Validator untuk memeriksa sintaks mekanisme dan batas 10 lookup, dan DKIM Record Validator untuk memastikan kunci publik Anda diterbitkan dengan benar untuk setiap selektor yang digunakan. Validasi ulang ketiganya setelah setiap perubahan infrastruktur email - layanan pengiriman baru, migrasi domain, atau perpanjangan sertifikat SSL semuanya dapat memengaruhi penerbitan kunci DKIM.

Gunakan penyelarasan relaxed selama transisi

Mode penyelarasan default untuk SPF dan DKIM adalah relaxed (`adkim=r; aspf=r`), yang memungkinkan subdomain memenuhi penyelarasan untuk domain induk. Ini adalah pengaturan yang tepat selama peluncuran karena banyak pengirim sah menggunakan subdomain domain Anda untuk autentikasi. Beralihlah ke penyelarasan strict (`adkim=s; aspf=s`) hanya jika Anda memiliki persyaratan keamanan khusus dan telah memastikan semua pengirim menggunakan pencocokan domain yang tepat - penyelarasan strict dengan satu pengirim salah konfigurasi merusak DMARC untuk setiap pesan yang dikirim pengirim tersebut.

• Mulai dengan p=none, jangan pernah p=reject: Bangun kepercayaan pada tingkat keberhasilan autentikasi Anda sebelum menerapkan penegakan.
• Siapkan rua= sebelum hal lain: Anda tidak bisa mengambil keputusan kebijakan yang tepat tanpa data laporan agregat.
• Periksa alat bantu perencanaan selektor DKIM: Gunakan DKIM Selector Planning Helper saat merotasi kunci DKIM untuk menghindari kesalahan tumpang tindih.
• Gunakan pct= untuk penegakan bertahap: Mulai dari pct=10 saat beralih ke quarantine atau reject - ini membatasi dampak jika ada yang salah konfigurasi.
• Validasi ulang setelah setiap perubahan platform email: Menambahkan alat pemasaran, CRM, atau sistem tiket baru biasanya memerlukan pembaruan SPF dan konfigurasi DKIM.
• Pantau propagasi DNS: Setelah menerbitkan atau mengubah catatan DMARC, gunakan DNS Propagation ETA Estimator untuk mengetahui kapan perubahan terlihat secara global.