DMARC p=none ke p=reject Tanpa Kehilangan Email Sah: Peluncuran Bertahap (2026)

Diterbitkan 2026-07-08

Angka per 2026-06-29 · metodologi v7. Data sensus agregat dari 261 juta domain yang dinilai. Lihat cara kami menilai.

Pindahkan DMARC dari p=none ke p=reject dalam empat tahap: pantau laporan rua selama 2–4 minggu, perbaiki setiap pengirim yang sah, tingkatkan p=quarantine dengan pct, kemudian tolak — jangan pernah langsung lompat ke reject. 70,368,600 dari 261,086,232 domain yang dinilai terhenti di SPF soft tanpa penegakan DMARC, menurut sensus Defaults.Exposed.

Ini adalah runbook operasional: tabel tahap dengan kriteria keluar, record untuk setiap tahap, kehalusan RFC 7489 pct yang mengubah arti “50%” pada reject, dan tag sp= untuk subdomain. Jika Anda memutuskan apakah akan menegakkan, baca 6 tahap kematangan DMARC terlebih dahulu — itulah kerangka kerjanya; dan jika level kebijakan sendiri masih baru bagi Anda, apa arti p=none, p=quarantine dan p=reject adalah primernya. Halaman ini adalah pelaksanaannya.

Mengapa Anda tidak bisa langsung lompat ke p=reject?

Karena p=reject memberi tahu setiap penerima yang mematuhi untuk memantul email yang gagal DMARC — dan sampai Anda menonton laporan Anda, Anda tidak tahu apa yang gagal. Hampir setiap domain yang mengaktifkan pemantauan menemukan pengirim yang sah yang dilupakan: CRM, alat faktur, formulir kontak. Lompat ke reject pada hari pertama dan email itu tidak masuk spam; ia menghilang pada waktu SMTP. Kehilangan rangkaian faktur mengajarkan organisasi untuk takut pada DMARC, dan record diputar kembali ke p=none secara permanen — dari 261,086,232 domain yang dinilai, 37,312,637 diparkir tepat di sana, dan hanya 10.59% (27,640,987) yang pernah mencapai kebijakan yang ditegakkan.

Alasan lainnya adalah keselarasan. DMARC lulus hanya ketika SPF atau DKIM lulus dan selaras dengan domain From yang terlihat — SPF terhadap domain Return-Path (RFC5321.MailFrom), DKIM terhadap d= tanda tangan. Pengirim pihak ketiga biasanya lulus SPF pada domain mereka, bukan domain Anda, itulah mengapa tahap perbaiki-setiap-sumber sebagian besar adalah tentang mengaktifkan DKIM domain kustom setiap vendor — diuraikan dalam DMARC gagal tapi SPF dan DKIM lulus.

Apa empat tahap peluncuran?

Tahap	Record kebijakan	pct	Yang terjadi pada email yang gagal	Kriteria keluar
1. Pantau	`p=none; rua=mailto:…`	—	Dikirimkan normal; Anda menerima laporan agregat	2–4 minggu laporan; setiap pengirim di dalamnya diidentifikasi sebagai sah atau tidak
2. Perbaiki sumber	`p=none` (tidak berubah)	—	Masih dikirimkan normal	Setiap sumber yang sah lulus DMARC selaras (DKIM domain kustom per pengirim); kegagalan yang tersisa hanya lalu lintas yang tidak dikenal/palsu
3. Ramp karantina	`p=quarantine`	10 → 25 → 50 → 100	Bagian yang disampel masuk ke folder spam; bagian yang tidak disampel diperlakukan sebagai p=none (dikirimkan)	1–2 minggu di pct=100 tanpa email yang sah dikarantina
4. Tolak	`p=reject`	100	Dipantulkan pada waktu SMTP; pengirim mendapat bounce, penerima tidak melihat apapun	Berkelanjutan — pertahankan `rua` selamanya untuk menangkap pengirim baru

Data per 2026-06-29; perilaku kebijakan per RFC 7489.

Tahap 3 adalah tempat domain terhenti atau panik. Masuk ke folder spam bisa dipulihkan — pengguna menemukan email, Anda melonggarkan pct, Anda memperbaiki sumber. Penolakan tidak bisa dipulihkan, itulah mengapa karantina pada pct=100 yang berjalan bersih adalah tiket masuk ke tahap 4.

Bagaimana cara menjalankan peluncuran, langkah demi langkah?

Jalankan pemindaian gratis di defaults.exposed sebelum menyentuh DNS. Ini mengkonfirmasi kebijakan Anda saat ini dan apakah SPF dan DKIM sudah ada di bawahnya — dua leg yang ditegakkan berdiri padanya.
Aktifkan pemantauan jika belum. Menerbitkan p=none dengan rua= adalah langkah lima menit dalam “DMARC policy not enabled”. Kumpulkan 2–4 minggu laporan — cukup untuk menangkap pengirim bulanan seperti rangkaian faktur.
Inventarisasi setiap sumber dalam laporan. Urutkan pengirim menjadi milik Anda, vendor Anda, dan tidak dikenal. Laporan mentah datang sebagai XML — alat pemrosesan laporan (atau dashboard provider Anda) mengubahnya menjadi inventaris pengirim yang dapat dibaca.
Buat setiap sumber yang sah lulus selaras. Aktifkan DKIM domain kustom setiap vendor (biasanya dua record CNAME di dashboard mereka) agar tanda tangan membawa domain Anda, bukan domain mereka. Lebih memilih DKIM untuk keselarasan: ia bertahan saat penerusan, SPF tidak.
Tunggu dua minggu yang bersih. Keluar dari tahap 2 hanya ketika kegagalan yang dilaporkan secara eksklusif adalah lalu lintas yang tidak Anda kenal — pemalsuan yang ingin Anda blokir.
Pindah ke p=quarantine; pct=10 — edit record TXT _dmarc yang ada (contoh yang dikerjakan: setup DMARC IONOS), dan perhatikan sintaks: typo dalam tag kebijakan dapat membatalkan record sepenuhnya. Tingkatkan pct ke 25, 50, 100 selama 2–4 minggu, pantau laporan dan tiket helpdesk. Apapun yang sah di spam: turunkan pct kembali, perbaiki sumber, lanjutkan.
Pindah ke p=reject setelah 1–2 minggu bersih di pct=100. Pertahankan rua= selamanya — setiap alat baru yang diadopsi perusahaan Anda adalah pengirim yang gagal di masa depan.

Apa yang sebenarnya dilakukan pct? Kehalusan RFC 7489

pct meminta penerima untuk menerapkan kebijakan Anda pada persentase email yang gagal tersebut. Kehalusannya, dari RFC 7489 §6.6.4: email yang tidak disampel tidak jatuh kembali ke “dikirimkan normal” — ia mendapatkan kebijakan berikutnya yang kurang ketat. Di bawah p=quarantine; pct=25, 75% lainnya diperlakukan sebagai p=none dan dikirimkan. Tetapi di bawah p=reject; pct=50, 50% lainnya dikarantina, tidak dikirimkan. Tidak ada penolakan yang lembut: begitu record Anda mengatakan reject, setiap pesan yang gagal setidaknya masuk ke folder spam di penerima yang mematuhi.

Digunakan dengan sengaja, itu adalah fitur — p=reject; pct=1 berperilaku sebagai “karantina hampir semua, tolak sedikit”, jalur masuk terakhir yang sah. Dua peringatan: penerima tidak semua mengimplementasikan sampling secara identik, jadi perlakukan pct sebagai dial kasar; dan hapus tag (atau atur pct=100) setelah tahap 4 stabil, sehingga record Anda mengatakan apa yang Anda maksud.

Bagaimana dengan subdomain — tag sp=?

Secara default, subdomain mewarisi kebijakan domain organisasi: p=reject di yourdomain.com juga mencakup mail.yourdomain.com. Tag sp= membiarkan mereka menyimpang, dalam arah yang berguna dan berbahaya. Berguna: p=quarantine; sp=reject mengunci subdomain yang tidak pernah Anda kirim email saat apex masih di tengah-ramp — spoofer dengan sengaja menarget subdomain dari domain yang dipantau. Berbahaya: sp=none yang terlupakan secara diam-diam membebaskan setiap subdomain dari kebijakan reject yang Anda habiskan enam minggu mendapatkannya. Periksa di tahap 4; jika satu subdomain benar-benar membutuhkan kebijakan yang lebih longgar, terbitkan record _dmarc pada subdomain tersebut alih-alih melonggarkan semuanya.

Apakah NIS2 berarti bisnis EU harus melakukan ini?

DMARC bekerja identik di mana pun — tidak ada yang berubah dalam runbook ini di perbatasan EU. Yang berubah adalah tarikan kepatuhan. NIS2 Pasal 21(2)(j) mensyaratkan entitas dalam lingkup untuk mengamankan komunikasi mereka, dan Commission Implementing Regulation (EU) 2024/2690 mengeja persyaratan teknis untuk entitas infrastruktur digital yang dicakupnya — Annex-nya (poin 6.7.2(k)) mensyaratkan rencana implementasi untuk menerapkan standar keamanan email modern yang disepakati secara internasional, dan poin 6.7.2(l) mensyaratkan praktik terbaik keamanan DNS. Kebijakan DMARC yang ditegakkan, dengan SPF dan DKIM di bawahnya, adalah kontrol yang dapat diaudit yang diakui untuk pemalsuan; p=none adalah pemantauan yang nyata-nyata, bukan mengamankan. Jika pelanggan Anda dalam lingkup, kuesioner pemasok mereka semakin banyak menanyakan persis ini.

Pertanyaan yang Sering Diajukan

Berapa lama seluruh peluncuran membutuhkan waktu? Enam hingga sepuluh minggu adalah tipikal: 2–4 minggu pemantauan, 1–3 minggu memperbaiki sumber, 2–4 minggu meningkatkan karantina, kemudian tolak. Ini adalah waktu kalender, bukan upaya — sebagian besar menunggu laporan mengkonfirmasi setiap perubahan. 89.41% dari 261,086,232 domain yang dinilai tanpa kebijakan yang ditegakkan (data per 2026-06-29) sebagian besar tidak sedang di tengah peluncuran; mereka tidak pernah memulai jam.

Bisakah saya melewati karantina dan menggunakan p=reject dengan pct rendah? Anda bisa — per RFC 7489 §6.6.4, p=reject; pct=10 berarti 10% ditolak dan 90% dikarantina, kira-kira akhir tahap 3. Tetapi p=quarantine terlebih dahulu lebih mudah dipahami, dan penerima bervariasi dalam seberapa setia mereka melakukan sampling. Bagaimanapun, tahap 1–2 tidak bisa dinegosiasikan: tidak ada rasa penegakan yang aman sementara pengirim yang sah masih gagal.

Bagaimana dengan email yang tidak bisa saya perbaiki — forwarder dan mailing list? Penerusan memutus SPF secara desain, dan beberapa mailing list menulis ulang konten, juga memutus DKIM. DKIM yang selaras bertahan dalam penerusan biasa, yang menangani sebagian besar; residu kecil adalah alasan tahap karantina ada — email yang masuk ke folder spam bisa dipulihkan saat Anda menilai. Detail di email yang diteruskan gagal SPF.

Apakah berhenti di p=quarantine sudah cukup baik? Ini sebagian besar nilainya, dan jauh lebih baik dari 37,312,637 domain yang diparkir di p=none (dari 261,086,232 yang dinilai, data per 2026-06-29) — tetapi email palsu masih mencapai folder spam, di mana orang menemukannya. Reject adalah titik akhir: hanya 10.59% dari domain yang dinilai yang menegakkan sama sekali, dan menyelesaikannya adalah yang diakui pemeriksa, asuransi, dan kuesioner.

Kirimkan laporan kepada pemilik

Jika Anda menjalankan peluncuran ini untuk klien atau perusahaan, garis finish dapat diperlihatkan. Jalankan ulang pemindaian gratis setelah p=reject ter-resolve dan teruskan laporan yang dinilai: domain berpindah ke kebijakan yang ditegakkan, dengan timestamp dan dalam bahasa yang mudah dipahami. Satu halaman itu menjawab baris keamanan email pada perpanjangan asuransi siber dan kuesioner pemasok yang didorong NIS2 lebih baik dari screenshot panel DNS — dan membuat enam minggu pekerjaan yang hati-hati dan tidak terlihat menjadi terlihat oleh orang yang membayarnya.

Periksa kebijakan DMARC Anda gratis

Lihat apa kebijakan Anda saat ini — dan apakah SPF dan DKIM dapat menopang penegakan — secara privat dan hanya untuk pemilik.

Periksa domain Anda → · Perbaiki DMARC → · “DMARC policy not enabled” — langkah pertama yang jujur → · Hanya data agregat. Data disimpan dan diproses di EU.