DMARC p=none to p=reject: A Safe Rollout Plan

p=reject is the goal: it tells receivers to refuse mail that falsely claims to be from your domain. Jumping straight there is risky, though—any legitimate service you've forgotten about will have its mail rejected too. The safe path is gradual, and it is driven by the reports DMARC gives you.

Step 1: publish p=none with reporting

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

p=none changes nothing about delivery. It asks receivers to send daily aggregate reports to the rua address. The reports are XML files, so most organisations send them to a DMARC reporting service that turns them into readable dashboards.

If reports go to another company's domain, that domain must publish an authorization record (example.com._report._dmarc.reports-provider.com). Reporting services handle this for their customers; the SPF, DKIM and DMARC checker verifies it.

Step 2: find every legitimate sender

Leave p=none in place for at least two to four weeks—long enough to catch monthly invoices and other infrequent mail. In the reports, list every source sending as your domain and sort them into:

• Yours and passing: nothing to do.
• Yours but failing: a service that needs SPF, DKIM or alignment fixed. Typical examples are a CRM using its own envelope domain, or a helpdesk that isn't signing with your DKIM key.
• Not yours: spoofing, or forwarding. This is what enforcement will stop.

Fix the "yours but failing" group, usually by setting up DKIM signing with your domain in each service.

Step 3: move to p=quarantine, gradually

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

pct applies the policy to only a share of failing mail; the rest is treated one step more leniently. Raise it over a few weeks—25, 50, 100—while watching reports and support tickets for legitimate mail landing in spam.

Step 4: move to p=reject

v=DMARC1; p=reject; rua=mailto:[email protected]

Once quarantine at 100% has run cleanly, move to reject. Spoofed mail is now refused outright at receivers that apply DMARC. Keep reading the reports: new services get added, and they need to be set up before they start sending.

DMARC subdomain policy (sp=)

Subdomains without their own DMARC record inherit the parent's policy, or the sp= value if you set one. Attackers like unused subdomains, so sp=reject is a sensible default once the main domain is enforced. Subdomains that send mail can publish their own _dmarc record with a different policy.

Common pitfalls

• Mailing lists and forwarding can break SPF and sometimes DKIM. ARC, which many large receivers support, helps, but expect a small number of forwarded failures in reports.
• Two DMARC records on the same name cause receivers to ignore DMARC entirely.
• A typo in the record, such as a missing p= tag, can make receivers ignore it. Check it after every change.
• Removing rua after reaching reject. Keep it—reports are how you notice a new service failing.

For background on how the pieces fit together, see SPF, DKIM and DMARC explained.