DMARC p=none to p=reject: a safe rollout, step by step

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

Check your domain's email setup

Runs in your browser. Lookups go straight from your browser to Cloudflare's public DNS resolver (Google Public DNS if Cloudflare fails). MailSetupCheck has no server and never sees the domain you check.

Step 1: publish p=none with reports

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

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). 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:[email protected]"

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:[email protected]"

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) 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), RFC 9990 (aggregate reports), Google's DMARC setup guide, Microsoft's DMARC guide.

Also available as Markdown.