# Apa Itu DMARC? Alignment, Kebijakan, dan Perubahan RFC 2026 URL: https://notificationharbor.com/id/journal/apa-itu-dmarc Type: blog Locale: id Published: 2026-09-29 Updated: 2026-09-29 --- > DMARC memberitahu penerima apa yang harus dilakukan ketika email gagal alignment. Inilah cara record, kebijakan, dan laporan bekerja, serta apa yang berubah pada 2026. Apa itu DMARC? Ini adalah TXT record DNS yang memberitahu mail server penerima apa yang harus dilakukan ketika suatu pesan mengklaim domain Anda di header From namun gagal autentikasi, dan kemana mengirim laporan tentang hal itu. DMARC sendiri tidak melakukan autentikasi apa pun. DMARC mengecek apakah SPF atau DKIM telah lolos dan apakah domain yang mereka validasi sesuai dengan domain yang pembaca lihat. Kesesuaian itu disebut alignment, dan ini adalah bagian yang paling sering keliru oleh tim. Sebuah pesan bisa lolos SPF, lolos DKIM, dan tetap gagal DMARC. ## DMARC adalah lapisan kebijakan di atas SPF dan DKIM SPF mencantumkan IP mana yang boleh mengirim untuk suatu domain. DKIM menandatangani pesan sehingga penerima dapat memverifikasi bahwa itu tidak diubah dan domain penandatangan menyetujuinya. Tidak satupun dari keduanya melihat alamat From yang dibaca manusia. DMARC menutup celah itu. Ia mengajukan satu pertanyaan: apakah domain di header From yang terlihat selaras dengan domain yang lolos SPF atau DKIM? Jika ya, pesan lolos. Jika tidak, penerima menerapkan kebijakan Anda. ![Engineer reviewing DNS records in a terminal on a laptop at a desk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f76a50-inline1.webp) Record berada di `_dmarc.domain-anda.com` sebagai TXT record. Satu yang minimal dan valid terlihat seperti ini: `_dmarc.contoh.com. IN TXT "v=DMARC1; p=none; rua=mailto:laporan-dmarc@contoh.com"`Tiga tag melakukan pekerjaan sesungguhnya. `p` adalah kebijakan, `rua` adalah tempat laporan agregat dikirim, dan `adkim` / `aspf` mengatur seberapa ketat alignment-nya. Segalanya yang lain bersifat opsional. ## Alignment adalah tempat setup yang bagus gagal SPF mengautentikasi envelope sender, domain Return-Path. DKIM mengautentikasi domain di tag `d=` dari tanda tangan. DMARC membutuhkan setidaknya salah satu untuk cocok dengan domain From, baik secara tepat (strict) atau di tingkat domain organisasi (relaxed, default). Ini adalah kegagalan yang paling sering kami lihat dalam traces. Sebuah tim mengirim melalui penyedia pihak ketiga, penyedia menandatangani dengan domain-nya sendiri (`d=penyedia-mail.net`) dan menggunakan domain bounce-nya sendiri. SPF lolos, DKIM lolos, dan DMARC gagal karena tidak ada domain yang cocok dengan `contoh.com`. Perbaikannya adalah custom sending domain: key DKIM yang diterbitkan di bawah domain Anda, dan idealnya custom return-path di subdomain. Setiap penyedia serius mendukungnya. Beberapa mengaktifkannya secara default. ## Tiga kebijakan: none, quarantine, reject Tag `p` memiliki tiga nilai, dan ini bukan tangga yang Anda naiki sesuai jadwal. - **`p=none`**: penerima mengirimkan secara normal dan mengirimkan Anda laporan. Gunakan ini selama 2 hingga 4 minggu pertama, saat Anda membuat inventaris pengirim. - **`p=quarantine`**: penerima mengarahkan kegagalan ke spam atau junk. Gunakan ini setelah laporan menunjukkan semua sumber yang sah selaras. - **`p=reject`**: penerima menolak kegagalan pada tahap SMTP. Gunakan ini setelah quarantine berjalan bersih selama satu siklus pengiriman penuh. `p=none` adalah pemantauan, bukan perlindungan. Domain yang berada di `none` selama dua tahun memiliki kotak centang compliance dan tidak ada pertahanan terhadap spoofing. Lewati godaan untuk membiarkannya di sana karena "tidak ada yang rusak". `p=reject` adalah tujuan untuk domain apa pun yang hanya mengirim email yang Anda kontrol. Domain dengan traffic mailing-list berat atau forwarder legacy memerlukan lebih banyak perhatian, karena forwarding sering kali merusak SPF dan dapat merusak DKIM jika intermediary mengedit body. ## Mengapa aturan Gmail dan Yahoo membuat ini mendesak Sejak Februari 2024, [panduan pengirim Google](https://support.google.com/mail/answer/81126?hl=en) mengharuskan siapa pun yang mengirim lebih dari 5.000 pesan per hari ke akun Gmail untuk menerbitkan DMARC record, dengan SPF dan DKIM di tempat. Kebijakannya bisa `none`. Google juga meminta bulk sender untuk menjaga user-reported spam rate di Postmaster Tools di bawah 0,30%, dan merekomendasikan tetap di bawah 0,10%. [Yahoo Sender Hub](https://senders.yahooinc.com/best-practices/) menyatakan persyaratan core yang sama: DMARC policy yang valid minimal `p=none`, dengan domain From selaras dengan domain SPF atau DKIM. Relaxed alignment dapat diterima. Perhatikan apa dan apa yang bukan dalam aturan itu. Persyaratan adalah record yang diterbitkan dan alignment yang lolos, bukan penegakan. Itu adalah dasar. Ini bukan garis finish. ![Lowered customs barrier at a harbor container yard at dusk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/4a2947-inline3.webp) ## Laporan agregat adalah produk, kebijakan adalah switch Alamat `rua` menerima laporan XML harian dari setiap penerima yang menghormati DMARC. Setiap laporan mencantumkan source IP, jumlah pesan, hasil SPF dan DKIM, dan apakah alignment berlaku. Ini adalah cara Anda menemukan pengirim yang terlupakan: export CRM lama, tool billing yang kontraktor sambungkan pada 2022, form marketing di subdomain yang tidak ada yang miliki. XML mentah tidak dapat dibaca dalam volume. Arahkan `rua` ke mailbox yang parser dapat terima, atau ke layanan pelaporan DMARC yang dihosting, dan lihat data yang dikelompokkan oleh sumber. Apa yang ingin Anda lihat adalah setiap sumber yang sah menunjukkan 100% selaras, dan segalanya yang lain jelas tidak dikenal. Rollout praktis berjalan dalam urutan ini: - Terbitkan `p=none` dengan alamat `rua`. - Kumpulkan laporan dua hingga empat minggu. Bangun inventaris pengirim. - Perbaiki setiap sumber yang sah yang tidak selaras dengan DKIM domain khusus atau return-path. - Pindah ke `p=quarantine`. Pantau untuk tiket dukungan tentang email yang hilang. - Pindah ke `p=reject` ketika quarantine menunjukkan tidak ada kegagalan yang sah. Kirimkan setiap langkah secara terpisah. Mengubah kebijakan dan menambahkan penyedia pengiriman baru dalam minggu yang sama membuat regresi apa pun tidak mungkin untuk diattribusikan. ## DMARCbis mengubah tag, bukan record Anda Pada 2026 IETF menerbitkan RFC 9989, RFC 9990, dan RFC 9991, yang menggantikan RFC 7489. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) adalah spec DMARC core. Pelaporan agregat dan pelaporan kegagalan pindah ke dokumen mereka sendiri. Perubahan praktis untuk pemilik record sangat kecil: - `pct`, `rf`, dan `ri` dihapus. - `t` (testing mode) menggantikan `pct` sebagai switch all-or-nothing: `t=y` melaporkan tanpa penegakan. - `np` mengatur kebijakan untuk subdomain yang tidak ada, yang memblokir spoofing alamat seperti `abc123.contoh.com`. - `psd` menandai domain suffix publik, dan tree walk DNS menggantikan pencarian Public Suffix List lama. Record `v=DMARC1` yang ada tetap valid. Tidak ada yang rusak jika Anda tidak mengubah apa pun hari ini. Dukungan penyedia untuk tag baru akan diluncurkan tidak merata, jadi tag baru yang tampak tidak melakukan apa pun biasanya berarti penerima belum mengimplementasikannya. Tag `np` adalah yang layak diadopsi lebih awal. Menyetel `np=reject` saat `p` masih `none` menutup jalur abuse fake-subdomain tanpa berkomitmen pada sisa email Anda untuk penegakan. ## Subdomain, dan mengapa default mewarisi DMARC record pada domain organisasi berlaku untuk subdomain juga, kecuali Anda menggantinya dengan `sp`. Warisan itu berguna dan juga jebakan. Jika marketing mengirim dari `news.contoh.com` melalui penyedia terpisah, itu mewarisi kebijakan induk. Pindahkan induk ke `p=reject` sebelum penyedia itu telah menyelaraskan DKIM dan newsletter turun ke lantai. Terbitkan record `_dmarc.news.contoh.com` terpisah ketika subdomain memiliki armada pengirim sendiri dan tempo rollout sendiri. Arsitektur yang lebih bersih memisahkan stream berdasarkan subdomain sejak awal. Email transaksional pada satu, lifecycle pada yang lain, email manusia pada akar. Masing-masing mendapat key DKIM sendiri, reputasinya sendiri, dan record DMARC sendiri. ## Baca header Authentication-Results sebelum Anda menebak Ketika pesan gagal, server penerima mencatat alasannya. Di Gmail, "Show original" menampilkan header `Authentication-Results`, dan itu memberitahu Anda lebih banyak dari dashboard apa pun. `Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounce.penyedia-mail.net; dkim=pass header.d=penyedia-mail.net; dmarc=fail (p=NONE) header.from=contoh.com`Bacanya dari kiri ke kanan. SPF lolos untuk `bounce.penyedia-mail.net`. DKIM lolos untuk `penyedia-mail.net`. DMARC gagal karena header From mengatakan `contoh.com` dan tidak ada domain yang lolos yang cocok. Catatan `(p=NONE)` menunjukkan kebijakan yang dilihat penerima. Pada `none` pesan ini dikirimkan anyway. Pada `reject` itu akan bounce dengan error 5.7.x, dan pengirim akan mengetahuinya dari pelanggan. Dua check menangkap sebagian besar kasus ini. Konfirmkan nilai `header.d` dalam hasil DKIM adalah domain Anda. Kemudian konfirmkan domain `smtp.mailfrom` adalah domain Anda atau subdomain-nya. ## SPF memiliki batas lookup yang DMARC ekspos SPF memungkinkan sepuluh lookup DNS per evaluasi. Setiap `include:` untuk penyedia menghabiskan beberapa di antaranya, dan nested include menghabiskan lebih banyak. Lewati sepuluh dan SPF mengembalikan error permanen, yang dihitung sebagai gagal. Tim dengan lima atau enam tools pengiriman memukul ini tanpa menyadarinya, karena kegagalan SPF tidak terlihat sebelum pelaporan DMARC. Begitu laporan `rua` tiba, polanya jelas: satu sumber tiba-tiba gagal SPF di semua penerima pada hari seseorang menambahkan `include:` lain. Ini adalah satu alasan lagi untuk mengandalkan alignment DKIM sebagai jalur utama. DKIM bertahan dari sebagian besar forwarding, tidak memiliki anggaran lookup, dan terikat pada pesan daripada connecting IP. Simpan SPF valid, tetapi jangan bangun pass DMARC Anda hanya di atasnya. ## Apa yang tidak akan dilakukan DMARC DMARC mencegah spoofing domain yang tepat. Tidak menghentikan domain yang terlihat mirip (`contoh1.com`), tidak menilai konten, dan tidak memperbaiki reputasi pengirim yang buruk. Domain yang sempurna selaras yang mengirim ke daftar yang dibeli tetap mendarat di spam. Ini juga tidak menggantikan pemantauan. Alignment dapat rusak dalam diam: perubahan DNS menghapus selector DKIM, penyedia merotasi key, tool baru mulai mengirim tanpa pengetahuan Anda. Laporan adalah cara Anda mengetahuinya sebelum pengguna Anda melakukannya. Perlakukan record DMARC seperti potongan config produksi lainnya. Itu milik version control, perubahan melalui review, dan mailbox `rua` membutuhkan pemilik. ![Cream envelope being sealed with a red wax stamp](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f3aca9-inline2.webp) ## Sebelum Anda menerbitkan record Lalui ini sekali. Butuh waktu kurang dari satu jam untuk domain tunggal. - Cantumkan setiap sistem yang mengirim email sebagai domain Anda: produk, penagihan, help desk, CRM, marketing, calendar invite. - Konfirmkan masing-masing menandatangani DKIM dengan domain Anda, bukan domain vendor. - Tetapkan custom return-path di mana penyedia memungkinkannya. - Pilih tujuan `rua` yang akan dibaca seseorang. - Mulai dengan `p=none`, dan letakkan tanggal Anda berencana meninjau di kalender. - Periksa spam rate di Google Postmaster Tools mingguan selama rollout. ## Kemana harus pergi dari sini Jika Anda tidak pernah melihat laporan Anda, terbitkan `p=none` dengan alamat `rua` hari ini dan baca apa yang tiba dalam dua minggu. Laporan pertama hampir selalu menamai setidaknya satu pengirim yang tidak ada yang ingat. Langkah konkret berikutnya adalah memutuskan mana dari itu yang Anda simpan. ## FAQ ### Apakah DMARC wajib? Untuk bulk sender, secara efektif ya. Google mengharuskan DMARC record untuk pengirim lebih dari 5.000 pesan per hari ke Gmail, dan Yahoo mengharuskan kebijakan yang valid minimal p=none. Penegakan tidak diwajibkan, tetapi record dan alignment-nya adalah. ### Apa arti p=none dalam DMARC? Ini berarti monitor saja. Penerima mengirimkan email yang gagal secara normal dan mengirimkan Anda laporan. Ini memenuhi minimum Gmail dan Yahoo tetapi tidak memberikan perlindungan terhadap spoofing. ### Bisakah email lolos SPF dan DKIM namun tetap gagal DMARC? Ya. DMARC mengharuskan domain yang divalidasi oleh SPF atau DKIM untuk selaras dengan domain header From. Email yang dikirim melalui penyedia yang menandatangani dengan domainnya sendiri lolos kedua check dan masih gagal alignment. ### Berapa lama saya harus tetap di p=none? Biasanya dua hingga empat minggu laporan agregat, cukup lama untuk melihat setiap pengirim yang sah termasuk yang volume rendah. Lanjutkan begitu setiap sumber yang sah menunjukkan sebagai selaras. ### Apakah DMARC mempengaruhi deliverability? Secara tidak langsung. Record yang diterbitkan dan selaras adalah persyaratan baseline di Gmail dan Yahoo, dan kegagalan alignment dapat mendorong email ke spam atau memicu penolakan di bawah kebijakan yang penegakan. Tidak memperbaiki reputasi pengirim yang buruk atau tingkat complaint tinggi. ### Apa yang berubah dengan DMARCbis dan RFC 9989? RFC 9989 menggantikan RFC 7489. Ini menghapus pct, rf dan ri, menambahkan t, np dan psd, dan menggantikan pencarian Public Suffix List dengan tree walk DNS. Record v=DMARC1 yang ada tetap valid.