Apa Itu DMARC? Alignment, Kebijakan, dan Perubahan RFC 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.

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 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 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.

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:

1. Terbitkan p=none dengan alamat rua.

2. Kumpulkan laporan dua hingga empat minggu. Bangun inventaris pengirim.

3. Perbaiki setiap sumber yang sah yang tidak selaras dengan DKIM domain khusus atau return-path.

4. Pindah ke p=quarantine. Pantau untuk tiket dukungan tentang email yang hilang.

5. 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 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.

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.