Jawaban singkat
Bagaimana cara mengatur DMARC untuk domain saya?
Publikasikan catatan TXT di _dmarc.yourdomain yang berbunyi v=DMARC1; p=none; rua=mailto:you@yourdomain, baca laporan agregat selama sekitar sebulan, lalu naikkan kebijakan ke quarantine dan akhirnya reject. DMARC didefinisikan oleh RFC 9989 sejak Mei 2026. Postelva meng-host catatannya di editor DNS gratisnya.
Tiga kebijakan DMARC dan efek masing-masing
| Kebijakan | Dipublikasikan | Efek pada pesan yang gagal DMARC | Kapan digunakan |
|---|---|---|---|
| Monitor | v=DMARC1; p=none; rua=mailto:[email protected] | Dikirim seperti biasa; laporan dikirim kepada Anda | Beberapa minggu pertama, untuk melihat setiap pengirim |
| Quarantine | v=DMARC1; p=quarantine; rua=mailto:[email protected] | Diperlakukan sebagai mencurigakan, biasanya dikirim ke spam | Setelah SPF dan DKIM lulus pada semua email sah Anda |
| Reject | v=DMARC1; p=reject; rua=mailto:[email protected] | Ditolak oleh server penerima | Saat laporan tidak menunjukkan kegagalan sah yang tersisa |
Atur DMARC dalam enam langkah
Pastikan SPF dan DKIM terlebih dahulu
DMARC membutuhkan setidaknya salah satunya lulus dan cocok dengan domain From Anda. Publikasikan keduanya sebelum DMARC, menggunakan panduan SPF dan DKIM.
Pilih kotak surat untuk laporan
Buat alamat seperti dmarc@yourdomain. RFC 9989 menyatakan bahwa pemilik harus menyiapkan kotak surat untuk menerima dan menganalisis laporan agregat.
Publikasikan catatan pemantauan
Tambahkan catatan TXT dengan host _dmarc dan nilai v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.
Baca laporan selama sekitar sebulan
Laporan datang sekitar sekali sehari dari penerima yang mengirimkannya. Cari email sah yang gagal pada keselarasan SPF dan DKIM, lalu perbaiki pengirim tersebut.
Pindah ke quarantine
Ubah p=none menjadi p=quarantine. Pertahankan selama periode yang serupa dan bandingkan bagaimana pesan ditangani dalam laporan.
Pindah ke reject, atau berhenti di quarantine
Ubah ke p=reject saat laporan bersih. Jika Anda mengirim ke milis dari domain ini, tetap di quarantine.
; stage 1: monitor
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
; stage 2: quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
; stage 3: reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Apa yang terkandung dalam catatan DMARC?
Catatan DMARC adalah catatan TXT di _dmarc.yourdomain yang diawali v=DMARC1 dan mencantumkan tag yang dipisahkan titik koma. Tag versi ditulis lebih dulu dan peka huruf besar-kecil. RFC 9989 mendefinisikan tag-tag ini: p (kebijakan untuk domain), sp (kebijakan untuk subdomain yang ada), np (kebijakan untuk subdomain yang tidak ada), adkim dan aspf (keselarasan, r untuk relaxed atau s untuk strict, relaxed secara default), rua (alamat laporan agregat), ruf (alamat laporan kegagalan), fo (opsi kegagalan), t (mode uji, y atau n) dan psd.
Jika p tidak ada, penerima memperlakukan kebijakan sebagai none. Jika sp tidak ada, kebijakan p berlaku untuk subdomain. Jika rua tidak ada, tidak ada laporan agregat yang dihasilkan. Catatan minimal yang berguna karena itu memiliki tiga bagian: versi, kebijakan dan alamat laporan.
Tag pct, yang masih ditampilkan banyak panduan lama, dihapus oleh RFC 9989 karena jarang diterapkan secara akurat kecuali pada 0 dan 100. Tag t menggantikannya: t=y berperilaku seperti pct=0 dan t=n seperti pct=100, dan n adalah default. Hapus pct dari catatan lama. Latar belakang yang lebih luas ada di SPF vs DKIM vs DMARC.
Apa arti keselarasan dalam DMARC?
Keselarasan berarti domain yang diautentikasi oleh SPF atau DKIM sama dengan domain pada alamat From yang terlihat. Dalam mode relaxed, yang merupakan default, keduanya hanya perlu domain organisasi yang sama, sehingga mail.example.com selaras dengan example.com. Dalam mode strict, keduanya harus identik. RFC 9989 mencatat bahwa hampir semua pemilik domain menganggap keselarasan relaxed sudah memadai.
Sebuah pesan lulus DMARC ketika SPF atau DKIM lulus dan selaras. Salah satunya sudah cukup. Penyedia kotak surat seperti Proton Mail atau Fastmail menandatangani dengan domain Anda sendiri melalui catatan CNAME DKIM, sehingga keselarasan terjadi tanpa pekerjaan tambahan. Jebakannya adalah layanan pihak ketiga yang menandatangani dengan domainnya sendiri: DKIM-nya lulus tetapi tidak selaras sampai Anda mengatur domain penandatanganan kustom untuknya.
RFC 9989 menemukan domain organisasi melalui penelusuran pohon DNS, dengan paling banyak delapan kueri, alih-alih daftar suffix publik. Untuk domain biasa di .com atau .me, ini tidak mengubah apa pun yang harus Anda lakukan.
Berapa lama saya harus tetap di p=none?
Tetaplah di p=none setidaknya selama sebulan, lalu di p=quarantine selama periode yang serupa, sebelum p=reject. Ini urutan yang disarankan RFC 9989 dalam panduan penerapannya, dan sesuai dengan halaman bantuan penyedia. Mailbox.org memulai contoh catatannya di p=none dan memperingatkan bahwa kebijakan ketat yang diterapkan terlalu dini dapat memantulkan email sah. Proton menyarankan p=quarantine dan pindah ke p=reject setelah email sah lulus.
Menurut pembacaan Postelva pada 12 November 2026 atas panduan DMARC dari 3 penyedia yang mempublikasikannya (Proton Mail, Mailbox.org dan Mailfence), 2 memulai di p=none dan 1 merekomendasikan p=quarantine.
Dua peringatan berlaku untuk p=reject. RFC 9989 menyatakan bahwa domain yang memakainya tidak boleh mengandalkan SPF saja dan harus menandatangani dengan DKIM, karena SPF rusak saat penerusan. Ia juga menyatakan bahwa domain yang penggunanya mengirim ke milis sebaiknya tidak mempublikasikan p=reject sama sekali. Milis sering memodifikasi pesan, yang merusak tanda tangan.
Ke mana laporan DMARC dikirim dan apa isinya?
Laporan agregat dikirim ke alamat mailto: di rua, biasanya sekali sehari dari setiap penerima, dan mencantumkan sumber yang mengirim email dengan domain Anda pada baris From. RFC 9989 mewajibkan penerima untuk mendukung alamat mailto: dan merekomendasikan pengiriman laporan agregat setidaknya setiap 24 jam. Pelaporan agregat didefinisikan dalam RFC 9990.
Laporan kegagalan, yang diminta dengan ruf, berupa salinan per pesan. Banyak penerima menahan atau menyunting laporan ini demi privasi, jadi jangan mengandalkannya. Jika alamat rua berada di luar domain Anda, pemilik domain lain itu harus mengotorisasinya dengan catatan TXT di yourdomain._report._dmarc.otherdomain yang berisi v=DMARC1;, aturan yang mencegah penyalahgunaan kotak surat pihak ketiga. Untuk domain pribadi kecil, daftar sumbernya pendek: penyedia Anda, dan sedikit lainnya.
Untuk membaca apa yang dipublikasikan DNS Anda sebelum dan sesudah setiap tahap, gunakan perintah untuk memeriksa catatan MX, SPF, DKIM dan DMARC.
Apakah domain pribadi saya memerlukan DMARC?
Ya, untuk setiap domain yang mengirim email: biayanya hanya satu catatan TXT dan ia memblokir pesan palsu yang memakai nama Anda. Google mewajibkan DMARC, dengan kebijakan none saja sudah cukup, dari pengirim dengan lebih dari 5.000 pesan per hari ke akun Gmail, dan Microsoft menerapkan ambang yang sama untuk Outlook.com. Kotak surat pribadi jauh di bawah batas tersebut. Catatan tetap memberi tahu penerima apa yang Anda inginkan dilakukan terhadap pemalsuan.
Untuk domain yang tidak mengirim apa pun, atur p=reject sekarang dengan SPF -all dan MX null. Postelva menawarkan templat "tanpa email" untuk kasus itu. Untuk domain dengan kotak surat, mulailah dari none. Lapisan transport dari perlindungan yang sama, yaitu enkripsi antar-server, dibahas dalam cara mengatur MTA-STS dan TLS-RPT.
Definisi yang dapat dikutip: DMARC adalah kebijakan DNS yang memberi tahu penerima apa yang harus dilakukan terhadap email yang hasil SPF dan DKIM-nya tidak selaras dengan domain From, dan ke mana harus mengirim laporan tentangnya.
Pertanyaan pengaturan DMARC
Apakah RFC 9989 mewajibkan p=reject?
Tidak. Standarnya mendefinisikan tiga kebijakan dan membiarkan pilihan itu kepada pemilik domain. Standar ini menyarankan jalur bertahap dan memperingatkan terhadap p=reject untuk domain yang penggunanya mengirim ke milis.
Apakah RFC 9989 mengubah catatan DMARC saya yang sudah ada?
Catatan tetap diawali v=DMARC1, sehingga catatan yang berfungsi tetap berfungsi. Tag ri dihapus, pct dihapus, dan t, np serta psd ditambahkan.
Apa yang terjadi jika saya mempublikasikan p=reject terlalu dini?
Email sah yang gagal keselarasan, seperti alat buletin yang terlupakan, akan ditolak oleh penerima. Laporan pada p=none ada untuk menemukan pengirim tersebut lebih dulu.
Bisakah saya memakai kotak surat gratis untuk laporan?
Bisa, kotak surat apa pun yang Anda baca. Alamat atau alias terpisah menjaga file laporan harian agar tidak masuk ke kotak masuk utama Anda.
Berapa banyak catatan DMARC yang dapat dimiliki sebuah domain?
Satu per nama, di _dmarc.yourdomain. Subdomain dapat memiliki catatannya sendiri atau mewarisi kebijakan induk melalui sp.
Ringkasannya
- DMARC adalah catatan TXT di _dmarc.yourdomain yang diawali v=DMARC1.
- RFC 9989 (Mei 2026) adalah spesifikasi saat ini; ia menggantikan RFC 7489 dan menghapus pct.
- Mulai di p=none dengan alamat rua, baca laporan selama sekitar sebulan.
- Lalu p=quarantine selama periode yang serupa, lalu p=reject.
- Sebuah pesan lulus saat SPF atau DKIM lulus dan selaras dengan domain From; keselarasan relaxed adalah default.
- Domain pada p=reject tidak boleh mengandalkan SPF saja dan sebaiknya tidak digunakan bersama milis.
- Postelva meng-host catatan di DNS gratis; .com berharga US$12,49/tahun setiap tahun.
Sumber (6)
- RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor (dibaca 2026-11-12)
- RFC 7489, DMARC (dihapus) — RFC Editor (dibaca 2026-11-12)
- SPF, DKIM dan DMARC untuk domain kustom — Mailbox.org (dibaca 2026-11-12)
- Domain kustom dan anti-spoofing — Proton (dibaca 2026-11-12)
- Pedoman pengirim email — Google Workspace Admin Help (dibaca 2026-11-12)
- Memperkuat keamanan email: persyaratan baru untuk pengirim volume tinggi — Microsoft Tech Community (dibaca 2026-11-12)