# DMARC dari p=none ke p=reject dalam 30 hari URL kanonis: https://brew.new/id/blog/dmarc-p-none-to-reject-in-30-days Penulis: Thomas Park Dipublikasikan: 2026-10-04 Diperbarui: 2026-10-04 DMARC adalah record TXT di `_dmarc.` yang memberi tahu server penerima apa yang harus dilakukan terhadap email yang memakai domain Anda di header From tetapi gagal lolos SPF dan DKIM yang selaras (aligned), serta ke mana laporan harus dikirim. `p=none` hanya meminta laporan, `p=quarantine` meminta server penerima memperlakukan email yang gagal sebagai mencurigakan, dan `p=reject` meminta mereka menolaknya. Gmail, Yahoo, dan Microsoft menerima `p=none` dari pengirim massal, sehingga banyak domain memublikasikannya lalu berhenti di situ: pelaku spoofing dilaporkan, tetapi tidak diblokir. Analisis Red Sift atas 73,3 juta domain, yang dikutip pada [April 2026](https://redsift.com/blog/email-authentication-bespinlabs-redsift), menemukan bahwa 14,9% domain memiliki kebijakan DMARC apa pun dan 2,5% menegakkan `p=reject`. EasyDMARC, vendor DMARC lainnya, [melaporkan pada 2025](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) bahwa 62,7% perusahaan Fortune 500 yang memakai DMARC menggunakan `p=reject`, dibandingkan 15,2% perusahaan Inc. 5000. Berikut rencana 30 hari menuju `p=reject`, record demi record, untuk domain yang mengirim email dari layanan email kantor, satu atau dua ESP, help desk, dan alat penagihan. Tiga puluh hari cocok untuk subdomain pengirim. Domain yang dipakai staf Anda untuk email sehari-hari butuh waktu lebih lama. ## Poin penting - Publikasikan `v=DMARC1; p=none; rua=mailto:...` pada hari ke-1. Tanpa `rua`, server penerima tidak boleh mengirim laporan agregat. - Setiap pengirim yang sah harus lolos SPF atau DKIM yang selaras dengan domain From Anda. Untuk sebagian besar alat, artinya alat tersebut harus menandatangani DKIM dengan domain Anda. - Jaga SPF agar memakai paling banyak 10 term yang memicu kueri DNS, termasuk include bertingkat, atau semua email Anda mendapat `permerror`. - Naik ke `p=quarantine` pada hari ke-15 dan ke `p=reject` pada hari ke-22, masing-masing setelah seminggu laporan yang bersih. Untuk domain yang dipakai staf untuk email sehari-hari, RFC 9989 meminta waktu sebulan di masing-masing dari dua tahap pertama. - RFC 9989 (Mei 2026) menandai `pct` sebagai historic (usang). Lewati kenaikan bertahap `pct=10`, `pct=50`. - BIMI membutuhkan `p=quarantine` atau `p=reject` di domain organisasi, tanpa `sp=none`, logo SVG Tiny PS, dan, untuk Gmail, VMC atau CMC. ## Apa yang berubah pada DMARC di 2026 Pada Mei 2026, IETF mengganti RFC 7489, dokumen berstatus Informational dari 2015, dengan DMARCbis: [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), sebuah Proposed Standard yang sekaligus menggantikan RFC 9091, ditambah [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) untuk pelaporan agregat. Tiga perubahan berikut penting di sini: - **`pct` kini usang.** Lampiran A.6 menyebutkan bahwa tag ini “biasanya tidak diterapkan secara akurat, kecuali nilai yang ditetapkan adalah 0 atau 100.” - **`t=y` menggantikan `pct=0`.** Server penerima menerapkan satu tingkat di bawah kebijakan Anda, jadi `p=reject; t=y` berlaku sebagai quarantine. Ini adalah sakelar uji. - **`np` adalah tag baru.** Tag ini berlaku untuk subdomain yang tidak ada di DNS, dan server penerima versi lama wajib mengabaikannya. Penelusuran pohon DNS (DNS tree walk) juga menggantikan public suffix list untuk menemukan domain organisasi. ## Tiga record yang menjadi dasar DMARC DMARC lolos jika SPF atau DKIM lolos **dan** domain yang lolos itu selaras dengan domain From. Cukup satu yang lolos dan selaras. ### SPF dan batas 10 lookup SPF mengotorisasi server untuk domain envelope (`MAIL FROM` atau return-path), satu-satunya identitas SPF yang dipakai DMARC, bukan HELO. [RFC 7208, bagian 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) membatasi term yang memicu kueri DNS hingga 10: `include`, `a`, `mx`, `ptr`, `exists`, dan `redirect`, yang dihitung hingga ke setiap include bertingkat. `ip4`, `ip6`, dan `all` tidak dihitung. Jika melebihi batas itu, hasilnya `permerror`. Bagian tersebut juga hanya mengizinkan paling banyak dua “void lookup”, biasanya berupa include untuk hostname yang sudah tidak ada. ```dns example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all" ``` Record itu sudah memakai 4 lookup sebelum menghitung include bertingkat milik setiap vendor, jadi telusuri masing-masing dengan `dig +short TXT ` sampai ke ujung rantainya. Agar jumlahnya tetap dalam batas 10, buang alat yang sudah tidak dipakai atau beri setiap ESP subdomain return-path sendiri, seperti `bounce.example.com`, dengan jatah 10 lookup tersendiri. [Panduan penyiapan SPF](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) dari Microsoft menyarankan untuk mengakhiri record dengan `-all` pada domain yang juga menjalankan DKIM dan DMARC. Banyak ESP secara default memakai domain return-path milik mereka sendiri, yang tidak selaras dengan domain Anda. Siapkan return-path kustom atau andalkan DKIM. ### DKIM: kunci 2048-bit, selector, dan rotasi DKIM menandatangani setiap pesan dengan domain `d=` dan selector `s=`; server penerima mengambil kuncinya dari `._domainkey.`. Alat yang menandatangani dengan `d=vendor-mail.example` lolos DKIM, tetapi gagal DMARC. [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) menyatakan bahwa penanda tangan wajib memakai kunci RSA minimal 1024 bit dan sebaiknya memakai 2048 bit. [Pedoman pengirim dari Google](https://support.google.com/mail/answer/81126) menyatakan hal yang sama untuk email ke akun Gmail pribadi. Kunci 2048-bit melebihi batas 255 karakter per string TXT, sehingga kunci itu dimasukkan sebagai beberapa string berkutip dalam satu record, yang umumnya dipecah otomatis oleh penyedia DNS. ```dns s202610._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..." "...remainder-of-the-2048-bit-key...IDAQAB" ) ``` Beri setiap sistem pengirim selector sendiri dan jangan pernah memakai ulang sebuah nama. Tanggal, seperti `s202610`, membuat riwayatnya mudah dibaca. [Praktik rotasi kunci](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) dari M3AAWG menyarankan rotasi minimal setiap enam bulan: 1. Publikasikan selector baru dan tunggu hingga propagasinya selesai. 2. Alihkan penandatanganan ke kunci baru. 3. Biarkan kunci publik lama tetap di DNS selama 7–30 hari agar email yang masih dalam perjalanan tetap bisa diverifikasi. 4. Pensiunkan selector lama dengan `p=` yang kosong. Jangan hapus selector tersebut. ### Alignment: relaxed atau strict RFC 9989 mendefinisikan dua mode: | Mode | Tag | Domain SPF/DKIM yang lolos | Domain From | Selaras? | |---|---|---|---|---| | Relaxed (default) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Ya, domain organisasinya sama | | Strict | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | Tidak, namanya harus sama persis | | Keduanya | | `vendor.example.net` | `example.com` | Tidak | RFC 9989 mencatat bahwa “hampir semua Pemilik Domain mendapati alignment relaxed sudah memadai.” Jangan cantumkan `aspf` dan `adkim`. Dengan alignment SPF strict, return-path yang biasa ditempatkan di subdomain menjadi tidak selaras. ## Rencana 30 hari ![Lini masa DMARC 30 hari dalam empat tahap: hari ke-1 sampai ke-7 di p=none dengan pelaporan rua, hari ke-8 sampai ke-14 memperbaiki pengirim, hari ke-15 di p=quarantine, hari ke-22 di p=reject, lalu BIMI mulai hari ke-30, lengkap dengan record TXT persis untuk setiap tahap.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *Record untuk setiap tahap. Lanjutkan hanya setelah seminggu laporan yang bersih.* | Hari | Kebijakan | Yang Anda lakukan | Syarat untuk lanjut | |---|---|---|---| | 1–7 | `p=none` | Publikasikan dengan `rua`, catat setiap sumber | Laporan 7 hari dari Google, Yahoo, dan Microsoft | | 8–14 | `p=none` | Perbaiki DKIM dan SPF, pensiunkan pengirim yang tidak dipakai | Setiap sumber yang sah lolos SPF atau DKIM yang selaras | | 15–21 | `p=quarantine` | Pantau email sah yang terkena quarantine | 7 hari tanpa ada sumber sah yang gagal | | 22–30 | `p=reject` | Terus baca laporan, tambahkan `np=reject` | Stabil selama seminggu | | 30+ | `p=reject` | Mulai BIMI | Sertifikat diterbitkan | Jika minggu ke-2 memunculkan sumber yang tidak bisa diperbaiki siapa pun, tetaplah di `p=none`. Menolak invoice Anda sendiri lebih buruk daripada terlambat menegakkan kebijakan. ### Hari ke-1 sampai ke-7: publikasikan p=none dengan pelaporan ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" ``` Laporan berupa file XML yang dikompresi gzip, minimal sehari sekali dari setiap server penerima, jadi arahkan `rua` ke layanan pemroses laporan, bukan ke seseorang. Jika alamatnya berada di domain organisasi lain, RFC 9990 meminta server penerima mengabaikannya kecuali `example.com._report._dmarc.` mengotorisasinya. Layanan pemroses laporan memublikasikan record itu; untuk domain Anda sendiri, tambahkan sendiri. Publikasikan tepat satu record DMARC. Jika wizard penyiapan meninggalkan dua record `v=DMARC1` di `_dmarc.example.com`, server penerima akan mengabaikan keduanya. Lewati `ruf`. RFC 9989 mencatat bahwa server penerima yang peduli privasi menyamarkan sebagian besar isi laporan kegagalan atau tidak mengirimnya sama sekali, dan FAQ dalam [pengumuman untuk pengirim bervolume tinggi](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) dari Microsoft menyatakan bahwa Microsoft mengirim laporan `rua` dan tidak berencana mengirim `ruf`. ### Cara membaca laporan agregat RFC 9990 menjelaskan laporan XML “harian (atau lebih sering)”, satu laporan untuk setiap domain kebijakan. Berikut satu record, diadaptasi dari contoh di RFC tersebut: ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` Di `policy_evaluated`, `dkim` dan `spf` adalah hasil **alignment**, sedangkan `disposition` adalah tindakan yang diambil server penerima. `auth_results` berisi hasil mentah beserta domainnya. Di sini keduanya lolos untuk `vendor.example`, sehingga keduanya gagal alignment: vendor mengirim atas nama Anda tanpa menandatangani sebagai Anda. Aktifkan DKIM kustom atau autentikasi domain di vendor tersebut. ### Hari ke-1 sampai ke-7: temukan pengirim yang tidak dikenal Kelompokkan berdasarkan `source_ip`, `envelope_from`, serta `domain` dan `selector` DKIM, urutkan berdasarkan `count`, lalu pilah ke dalam kategori berikut: | Pola di laporan | Kemungkinan penyebab | Tindakan | |---|---|---| | DKIM atau SPF lolos dan selaras | Konfigurasi sudah benar | Tidak ada | | DKIM dan SPF lolos untuk domain vendor | Alat SaaS memakai identitasnya sendiri | Aktifkan DKIM kustom | | DKIM lolos dan selaras, SPF gagal, IP penyedia email atau milis | Penerusan email atau milis | Biasanya tidak ada. DKIM yang selaras tetap bertahan saat email diteruskan | | Tanpa DKIM, SPF gagal, IP yang tidak bisa dilacak pemiliknya | Spoofing | Tidak ada. Inilah yang dihentikan `p=reject` | Untuk melacak pemilik sebuah IP, jalankan `dig -x 192.0.2.123 +short` dan periksa selector-nya, yang sering kali menyebut nama vendor. Lalu tanyakan kepada tim keuangan, dukungan, dan penjualan apa saja yang mengirim email atas nama perusahaan: penagihan, help desk, undangan kalender, mesin pemindai di kantor. Email yang diteruskan dan email milis akan gagal dengan cara yang tidak bisa Anda perbaiki, dan [FAQ pengirim](https://support.google.com/mail/answer/14229414) dari Google tidak mewajibkan alignment untuk email semacam itu, jadi jangan biarkan email ini menahan rencana Anda. ### Hari ke-8 sampai ke-14: perbaiki setiap sumber yang sah Mulailah dari `count` tertinggi: 1. **Email kantor** (Google Workspace, Microsoft 365). Aktifkan DKIM di konsol admin, 2048-bit jika tersedia, dan pastikan include milik penyedia sudah ada di SPF. 2. **ESP dan alat pemasaran.** Siapkan autentikasi domain agar alat-alat itu menandatangani dengan `d=` milik Anda, ditambah return-path kustom jika tersedia. 3. **Help desk, penagihan, CRM.** Sama seperti ESP. Jika ada alat yang tidak bisa menandatangani dengan domain Anda, gunakan subdomain yang bisa ditandatanganinya, atau domain milik alat itu sendiri. 4. **Alat yang sudah tidak dipakai.** Hapus include dan selector-nya. Setelah itu, hitung ulang lookup SPF. ### Hari ke-15: p=quarantine ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` Quarantine biasanya berarti masuk folder spam. Pantau sumber sah yang mendapat disposition `quarantine`. Sebagai uji coba, `p=quarantine; t=y` meminta server penerima yang mengikuti RFC 9989 menerapkan `none`, meskipun RFC ini baru berumur beberapa bulan dan belum semua server penerima mematuhi `t`. ### Hari ke-22: p=reject ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com" ``` Server penerima yang mematuhi `p=reject` menolak email yang gagal di dalam sesi SMTP, tetapi RFC 9989 meminta mereka menerapkan quarantine jika kebijakan itu satu-satunya bukti yang mereka miliki, sehingga sebagian email akan masuk spam. RFC yang sama menyatakan bahwa domain dengan `p=reject` “TIDAK BOLEH hanya mengandalkan SPF” dan wajib menandatangani dengan DKIM, karena penerusan email merusak SPF, tetapi tidak merusak DKIM. Pastikan dulu DKIM yang selaras di setiap sumber. Pertahankan `rua` selamanya. Alat baru yang dipasang kuartal depan akan muncul di laporan Anda sebelum muncul di antrean tiket dukungan. ### Kapan rencana perlu diperpanjang RFC 9989, bagian 7.4, menyatakan bahwa domain yang penggunanya mengirim ke milis “SEBAIKNYA TIDAK” memublikasikan `p=reject`, dan domain yang tetap melakukannya sebaiknya lebih dulu berada “setidaknya sebulan” di `p=none` dan “dalam jangka waktu yang sama panjangnya” di `p=quarantine`. Itu berlaku untuk sebagian besar domain apex perusahaan, jadi di sana berikan waktu sebulan untuk masing-masing dari dua tahap pertama. Subdomain yang hanya dipakai ESP Anda tidak memiliki lalu lintas milis dan bisa tetap mengikuti ritme 30 hari. ### Kebijakan subdomain: sp= dan np= `p` berlaku untuk domain dan subdomainnya. `sp` menimpanya untuk subdomain yang ada, `np` untuk subdomain yang tidak ada. Subdomain yang memiliki record sendiri memakai record tersebut, dan RFC 9989 mengabaikan `sp` di sana. Subdomain pengirim khusus seperti `mail.example.com`, yang dipakai satu ESP dengan SPF dan DKIM terverifikasi, bisa memublikasikan `p=reject` sejak hari pertama. `p=none; sp=reject` pada domain apex melindungi subdomain selagi Anda menyelesaikan domain utama, tetapi menghalangi BIMI. Domain yang diparkir sebaiknya memublikasikan `v=spf1 -all`, sesuai panduan SPF dari Microsoft, ditambah `v=DMARC1; p=reject;` di `_dmarc`. ## Hari ke-30 dan seterusnya: BIMI BIMI menampilkan logo Anda di samping email yang terautentikasi di kotak masuk yang mendukungnya: | Persyaratan | Detail | Sumber | |---|---|---| | Kebijakan DMARC | `p=quarantine` atau `p=reject` di domain organisasi dan domain From | Draf BIMI | | Kebijakan subdomain | Jika `sp` dipublikasikan, nilainya bukan `none` | Draf BIMI | | Persentase | Quarantine tidak boleh memiliki `pct` di bawah 100 | Draf BIMI | | Logo | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, sebuah ``, tanpa skrip atau referensi eksternal, tanpa `x=` atau `y=` di elemen root | BIMI Group | | Sertifikat | Gmail memerlukan VMC (merek dagang terdaftar, tanda centang) atau CMC (tanpa merek dagang, tanpa tanda centang) | Google | [Draf BIMI](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) kini berada di revisi 14 (Mei 2026), masih berupa Internet-Draft yang ditulis berdasarkan RFC 7489, karena itulah ada `pct`. Jangan cantumkan `pct` dan jangan menetapkan `t=y`. Aturan domain organisasi sering menjebak pengirim yang memakai subdomain: jika `mail.example.com` berada di `p=reject` dan `example.com` di `p=none`, server penerima tidak boleh menampilkan logo, jadi domain apex juga harus menuntaskan rencana ini. [Panduan SVG dari BIMI Group](https://bimigroup.org/creating-bimi-svg-logo-files/) menyarankan logo persegi yang berada di tengah dengan latar belakang warna solid, berukuran di bawah 32 KB. Google [menambahkan dukungan CMC pada September 2024](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). Berikut record-nya, sesuai [panduan implementasi BIMI Group](https://bimigroup.org/implementation-guide/): ```dns default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem" ``` Pendaftaran merek dagang memakan waktu berbulan-bulan, jadi mulailah proses VMC sekarang juga. ## Yang disyaratkan Gmail, Yahoo, dan Microsoft Tidak satu pun dari ketiganya mewajibkan penegakan kebijakan; yang diwajibkan hanya record DMARC dan alignment. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Ambang batas | Mendekati 5.000 per hari ke akun Gmail pribadi, per domain utama, berlaku permanen setelah tercapai | Pengirim massal, tanpa angka | Lebih dari 5.000 per hari ke outlook.com, hotmail.com, dan live.com, per domain From | | SPF dan DKIM | Keduanya | Keduanya | Keduanya harus lolos | | DMARC | Record wajib, `p=none` diterima | Minimal `p=none`, `rua` sangat disarankan | Minimal `p=none` | | Alignment | SPF atau DKIM | SPF atau DKIM, relaxed sudah cukup | SPF atau DKIM | | Jika gagal | Penolakan sementara dan permanen sejak November 2025 | Tidak disebutkan | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Sumber: [pedoman pengirim](https://support.google.com/mail/answer/81126) dan [FAQ](https://support.google.com/mail/answer/14229414) dari Google, [praktik terbaik untuk pengirim](https://senders.yahooinc.com/best-practices/) dari Yahoo, serta [pengumuman April 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) dan [halaman dukungan 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) dari Microsoft. Microsoft mulai menegakkan aturan ini pada 5 Mei 2025, setelah pembaruan 29 April mengubah tindakannya dari memindahkan email ke folder junk menjadi penolakan. FAQ Google menyebutkan bahwa alignment dengan SPF sekaligus DKIM “pada akhirnya akan menjadi persyaratan bagi pengirim,” jadi selaraskan keduanya di minggu ke-2. Untuk berhenti berlangganan dan tingkat spam, baca [apa yang tetap berlaku saat agen mengirim email Anda](/id/blog/agent-email-deliverability) dan [panduan keterkiriman](/id/blog/email-deliverability) kami. ## DMARC di domain pengirim Brew [Penyiapan domain](https://docs.brew.new/get-started/verify-your-sending-domain) di Brew meminta: - **DKIM**, record TXT di selector `._domainkey` di bawah domain pengirim Anda. Wajib. - **SPF**, record MX dan record TXT di `send.<your sending domain>`, return-path milik Brew. Wajib. - **DMARC**, record TXT di `_dmarc.<your sending domain>`. Opsional, tetapi disarankan. - Record **CNAME** untuk pelacakan klik, hanya jika memakai subdomain pelacakan kustom. Domain sudah bisa mengirim setelah SPF dan DKIM terverifikasi, dan Brew menyarankan nilai DMARC yang sesuai: ```dns ; dedicated sending subdomain, e.g. mail.example.com _dmarc.mail.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com" ; apex domain, or a domain Brew can't prove is dedicated _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``` Subdomain khusus mendapat `p=reject` karena tidak ada yang mengirim dari subdomain itu sebelum SPF dan DKIM Brew terverifikasi. Domain apex mendapat `p=none` karena alat-alat Anda yang lain kemungkinan juga mengirim atas nama domain itu, jadi jalankan rencana di atas. Alignment tetap relaxed karena return-path `send.<domain>` hanya selaras dalam mode relaxed. Brew membaca record `_dmarc.<sending domain>` yang aktif saat domain ditambahkan, saat verifikasi, dan setiap kali diperiksa ulang. Halaman **Domain** menampilkan hasilnya, begitu pula alat `get_domain_health` lewat MCP dan `GET /v1/domains/{domainId}/health`: - **`dmarc_missing`**, peringatan beserta record persis yang perlu ditambahkan. - **`dmarc_invalid`**, jika ada dua record DMARC di nama tersebut, atau versi atau kebijakan yang salah, atau tag ganda. Brew menyebutkan record yang harus dihapus. - **Terverifikasi**, setelah ditemukan tepat satu record yang valid. Penyiapan DNS otomatis hanya menulis DMARC jika belum ada record, sehingga tidak pernah menduplikasinya. Pemeriksaan dilakukan di domain pengirim, bukan di domain induknya, jadi berikan record sendiri untuk setiap subdomain pengirim, termasuk untuk [email transaksional](/id/blog/transactional-emails) jika Anda memisahkan keduanya seperti yang disarankan dokumentasi. Layanan pemroses `rua` Anda adalah tempat Anda membaca laporan dan memutuskan kapan beralih ke reject. ## Pertanyaan yang sering diajukan ### Berapa lama saya harus bertahan di p=none sebelum beralih ke quarantine? Sampai laporan selama seminggu penuh menunjukkan setiap sumber yang sah lolos SPF atau DKIM yang selaras, biasanya satu hingga dua minggu untuk subdomain pengirim. Untuk domain yang dipakai staf untuk email sehari-hari, RFC 9989 meminta minimal sebulan. Dua tahun di `p=none` tanpa ada yang membaca laporannya sama saja dengan tidak melakukan apa-apa. ### Apakah tag pct pada DMARC sudah usang? Ya. RFC 9989 mencantumkan `pct` sebagai “historic” (usang) dan menggantikan nilai-nilainya yang selama ini andal dengan `t`: `t=y` berperilaku seperti `pct=0`, `t=n` seperti `pct=100`. Server penerima versi lama mungkin masih membaca `pct`, tetapi tidak pernah menerapkan nilai di antaranya secara konsisten, jadi naikkan kebijakan secara utuh, satu tahap sekaligus. ### Apakah p=reject akan memblokir email saya yang diteruskan? Penerusan biasa umumnya merusak SPF, tetapi tidak merusak DKIM, sehingga DKIM yang selaras tetap lolos. Milis yang mengubah subjek atau footer akan merusak DKIM, dan sebagian milis menulis ulang header From sebagai kompensasinya. DKIM yang selaras di semua sumber adalah perlindungan terbaik Anda. ### Apakah Gmail dan Yahoo mewajibkan p=reject? Tidak. Keduanya mewajibkan pengirim massal memublikasikan DMARC, dan keduanya menerima `p=none`; begitu pula Microsoft untuk pengiriman di atas 5.000 pesan per hari ke Outlook.com. Penegakan kebijakan menghentikan spoofing dan wajib untuk BIMI, tetapi tidak satu pun dari ketiganya mewajibkannya. ### Apakah saya memerlukan VMC untuk BIMI? Untuk Gmail, Anda memerlukan VMC, yang mensyaratkan merek dagang terdaftar dan menampilkan tanda centang, atau CMC, yang menampilkan logo tanpa tanda centang. [BIMI Group](https://bimigroup.org/understanding-bimi-certificate-types/) menyebutkan bahwa beberapa penyedia, termasuk Yahoo dan Fastmail, juga menampilkan logo yang dideklarasikan sendiri (self-asserted) tanpa sertifikat.