# DMARC p=none to reject: a safe rollout > How to move DMARC from monitoring (p=none) to quarantine and reject without blocking your own mail. What each policy does, how to read reports, what changed with RFC 9989 in 2026 (pct is gone, t=y is new), and how to roll back. By MailSetupCheck. Updated 7 October 2026. Canonical URL: https://mailsetupcheck.com/dmarc-p-none-to-reject/ ## What the policy values do DMARC tells receiving servers what to do with mail that claims to come from your domain but fails both SPF and DKIM alignment, and where to send reports about it. The policy is the `p=` tag: | Policy | What receivers do with failing mail | What it protects | |---|---|---| | `p=none` | Deliver it as usual; send you reports | Nothing yet, but you learn who sends as you | | `p=quarantine` | Treat it as suspicious, usually the spam folder | Most forged mail lands in spam | | `p=reject` | Refuse it during delivery | Forged mail is not delivered | `p=none` meets the Gmail, Yahoo and Microsoft requirement for bulk senders ([details](/gmail-yahoo-bulk-sender-requirements/)). It does not stop anyone from forging your domain. Quarantine and reject do, and they are also required before mailbox providers will show your logo through BIMI. Other tags you will use: - `rua=mailto:...` where daily aggregate reports go. Without it you fly blind. - `sp=` the policy for subdomains (defaults to `p=`), and `np=` for subdomains that do not exist. - `t=y` test mode, new in [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989): receivers apply one level softer (reject acts as quarantine, quarantine as none). - `pct=` the share of failing mail the policy applied to. RFC 9989 removed it in 2026: in practice, values other than 0 and 100 "usually" were "not accurately applied", and inaccuracies "varied widely from one implementation to another" (appendix A.6). Receivers that follow the new standard ignore it; older ones may still apply it. Do not rely on `pct=25` to limit the damage of a mistake. ## Before you start Check where you are. The checker reads your DMARC record, tells you what it does, and lists what to fix first: > **Interactive checker.** On the HTML version of this page (https://mailsetupcheck.com/dmarc-p-none-to-reject/), enter a domain. Your browser asks Cloudflare's public DNS-over-HTTPS resolver (Google Public DNS as a fallback) for the domain's MX, SPF, DMARC, DKIM, MTA-STS, TLS-RPT and BIMI records, and the checker returns a fix list in three tiers: must fix to send to Gmail at volume, should fix, and nice to have, with the exact record to add where it can be worked out. MailSetupCheck has no server; the domain is never sent to it. What it checks, in short: - **MX**: present, null MX (RFC 7505), and the mail provider recognized from the host names. - **SPF** (RFC 7208): exactly one v=spf1 record, valid syntax, every include and redirect followed, DNS-querying terms counted against the limit of 10 and empty lookups against 2, "+all", "?all", a missing "all", and "ptr". - **DMARC** (RFC 9989, which replaced RFC 7489 in 2026): found at _dmarc. or by the DNS tree walk, every tag parsed, p=none explained, and an authorization record checked for report addresses at another organization (RFC 9990). - **DKIM** (RFC 6376): your selector plus 34 common ones; key type and size (RFC 8301: at least 1024 bits, 2048 recommended). Not finding a key at these names does not prove DKIM is off. - **MTA-STS** (RFC 8461), **TLS-RPT** (RFC 8460) and **BIMI** records. DKIM selectors tried: `google` (Google Workspace (default)), `selector1` (Microsoft 365), `selector2` (Microsoft 365), `s1` (SendGrid), `s2` (SendGrid), `m1` (SendGrid (without automated security)), `k1` (Mailchimp (older setups)), `k2` (Mailchimp), `k3` (Mailchimp), `mte1` (Mailchimp Transactional (Mandrill)), `mte2` (Mailchimp Transactional (Mandrill)), `brevo1` (Brevo), `brevo2` (Brevo), `mail` (Brevo (older setups) and others), `km1` (Klaviyo (marketing)), `km2` (Klaviyo (marketing)), `kt1` (Klaviyo (transactional)), `kt2` (Klaviyo (transactional)), `ctct1` (Constant Contact), `ctct2` (Constant Contact), `mailjet` (Mailjet), `resend` (Resend), `zoho` (Zoho Mail (the example name in Zoho's guide; admins choose their own)), `fm1` (Fastmail), `fm2` (Fastmail), `fm3` (Fastmail), `protonmail` (Proton Mail), `protonmail2` (Proton Mail), `protonmail3` (Proton Mail), `sig1` (iCloud+ custom email domains), `x` (MXroute), `default` (cPanel and other hosting control panels), `cf2024-1` (Cloudflare Email Routing (signs forwarded mail)), `dkim` (Generic name some providers and admins use). ## Step 1: publish p=none with reports ``` _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" ``` Reports arrive as XML files, usually gzip-compressed, typically once a day from each receiving organization that sends them. Reading them by hand is possible for a small domain; a DMARC report service makes it much easier. If the report address is at another domain (a report service), that domain has to publish a record accepting your reports, or receivers will not send them ([RFC 9990, section 4](https://www.rfc-editor.org/rfc/rfc9990#section-4)). The checker tests for that record. ## Step 2: find every service that sends as you Give it at least a few weeks, long enough to cover monthly mail such as invoices, payroll notices and newsletters. Then list every source in the reports: - **Your mailbox provider** (Google Workspace, Microsoft 365): should pass on its own once DKIM is on. - **Services you use**: newsletter, CRM, help desk, invoicing, e-commerce, booking, HR. For each one, turn on DKIM signing with your domain in its settings (this is what makes DMARC pass most reliably), and add its SPF include only if its bounce address uses your domain. - **Forwarders and mailing lists**: mail forwarded by another server often fails SPF and sometimes DKIM. Small volumes are normal. - **Strangers**: servers you do not recognize sending as you. That is what DMARC enforcement will stop. Move on when every legitimate source shows DKIM or SPF passing and aligned with your domain. ## Step 3: quarantine ``` _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` Failing mail now goes to spam instead of the inbox, which is recoverable: if you missed a service, its mail is in recipients' spam folders, not gone. Watch the reports and your support inbox for "I never got your email" messages. If you want a gentler step first, publish `p=quarantine; t=y`. Receivers that follow RFC 9989 keep treating failing mail as p=none. The tag replaces the old `pct=0` trick: some mailing lists and mailbox providers treated `pct=0` as a signal to rewrite the From address of mail they pass on, and comparing reports before and after showed how much of your mail goes through such intermediaries. RFC 9989 means `t=y` to be read the same way. Older receivers ignore `t=`. ## Step 4: reject ``` _dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com" ``` When quarantine has run cleanly through at least one full monthly cycle, switch to reject. Forged mail is now refused outright. `p=reject; t=y` is an in-between step: RFC 9989 receivers apply quarantine. There is no official timeline for any of these steps. Move when the reports say so, not on a schedule. ## Subdomains - With no `sp=` tag, subdomains get the same policy as the main domain. That is usually what you want. - `sp=none` with `p=reject` leaves made-up subdomains like `billing.example.com` open to forgery. The checker flags it. - A subdomain that sends mail through its own services can have its own `_dmarc.sub.example.com` record during its own rollout. - `np=reject` asks receivers to reject mail from subdomains that do not exist at all, which costs nothing. ## Domains that never send mail Parked domains should be at the strictest settings from day one: `v=spf1 -all`, `v=DMARC1; p=reject;`, and a null MX (`0 .`, [RFC 7505](https://www.rfc-editor.org/rfc/rfc7505)) if they should not receive mail either. The checker suggests all three when it finds a domain with no mail records. ## Rolling back If legitimate mail starts failing, set `p=none` again. Receivers pick up the change once the old record's TTL (time to live, set at your DNS host) expires. Fix the service (usually by turning on its DKIM signing), then step forward again. ## How DMARC finds your record Receivers look for `_dmarc.` plus the domain in the From address. Under RFC 9989, if there is none, they walk up the domain name one label at a time (`_dmarc.mail.example.com`, then `_dmarc.example.com`, then `_dmarc.com`), at most eight queries, and use the organization's record. This "DNS tree walk" replaced the Public Suffix List that RFC 7489 relied on. The checker does the same walk and shows you which names it queried. Sources: [RFC 9989 (DMARC)](https://www.rfc-editor.org/rfc/rfc9989), [RFC 9990 (aggregate reports)](https://www.rfc-editor.org/rfc/rfc9990), [Google's DMARC setup guide](https://knowledge.workspace.google.com/admin/security/set-up-dmarc), [Microsoft's DMARC guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure).