How to safely move your DMARC policy from p=none to p=reject

Publishing a DMARC record is the easy part. Most domains do it: in a scan I ran across the top 10,000 domains earlier this year, two thirds had a DMARC record, and only about half of those actually enforce it. The hard part, the part most never finish, is moving off p=none.

p=none monitors and enforces nothing. It asks receivers to report what they see and take no action on failures, which is exactly the right first step and exactly where most deployments quietly stall. A record stuck at p=none looks like protection and provides none: anyone can still spoof your domain and receivers will deliver it. The whole point of DMARC, stopping unauthenticated mail that uses your From address, only kicks in at p=quarantine or p=reject.

Here is how to get there without blocking your own legitimate mail on the way.

What the three policies actually do

• p=none: report only, no enforcement.
• p=quarantine: mail that fails DMARC is treated as suspicious, usually sent to spam.
• p=reject: mail that fails DMARC is rejected outright at the SMTP layer.

DMARC fails for a message when neither SPF nor DKIM produces a result that both passes and aligns with the domain in the visible From header. So the safe path is really one task: make sure every legitimate source of your mail produces an aligned pass before you turn on enforcement.

Why you can't just flip to p=reject

If you jump straight from p=none to p=reject, every legitimate sender that is not yet aligned starts getting rejected. That is almost never zero senders. Your marketing platform, your helpdesk, your invoicing system, that one server someone set up in 2019, mail forwarded by employees to personal accounts: all of these can be sending as your domain without aligned authentication. p=reject on day one turns those into hard bounces, and the first you hear of it is a customer who never got their receipt.

The reports are what let you find those senders before they become a problem.

Step 1: publish p=none and collect reports

Start with:

v=DMARC1; p=none; rua=mailto:[e-mail]

rua is the aggregate-report address. Receivers send a daily XML summary of every source sending as your domain and whether it passed SPF, DKIM, and alignment. Leave it running at least a couple of weeks so you capture the monthly senders (billing, newsletters) as well as the daily ones. You can add ruf for per-message failure reports, but most receivers do not send them and they can contain message content, so aggregate rua is what you will actually work from.

Step 2: read the reports and inventory your senders

Aggregate reports are XML and painful by eye past a handful. Feed them to a DMARC report viewer and you get a clean list: for each source, how many messages, and whether SPF and DKIM passed and aligned. Sort every source into two buckets: legitimate senders you recognize (your servers, your ESPs, your SaaS tools), and everything else. For each legitimate one, ask: does it produce an aligned pass on SPF or DKIM? You only need one of the two to align, not both.

Step 3: fix each legitimate source until it aligns

This is the real work. For each legitimate source that is not yet aligned:

• ESPs and SaaS senders (Mailchimp, SendGrid, your helpdesk): almost all support aligned DKIM by publishing a CNAME under your domain pointing at their signing key. Turn it on. Aligned DKIM is the better fix because it survives forwarding, where SPF breaks.
• Your own servers: put their IPs in SPF and, ideally, DKIM-sign with a key published under your domain.
• Anything that cannot align (a legacy system, a notifier with no DKIM support): move it behind a relay that can sign, give it its own subdomain so it does not affect your main domain's policy, or retire it.

Keep watching the reports. As you fix sources, their aligned-pass rate climbs. When every source you recognize is passing and aligned, you are ready to enforce.

Step 4: ramp to quarantine, then reject

Do not go straight to reject even now. Move to quarantine first:

v=DMARC1; p=quarantine; rua=mailto:[e-mail]

Watch the reports for a week or two. Quarantine is forgiving: a sender you missed lands in spam rather than vanishing, so you get a warning instead of a catastrophe. Fix what shows up, then move to reject:

v=DMARC1; p=reject; rua=mailto:[e-mail]

Some guides suggest the pct tag to enforce on a fraction of mail first (pct=25, then 50, then 100). It can help, but receiver support for it is uneven, so treat the quarantine-then-reject progression itself as the reliable ramp and pct as a nice-to-have, not the plan.

A few things that bite people

• Subdomains: a subdomain with no DMARC record of its own falls back to your organizational domain's policy, so p=reject does cover them by default. Use the sp= tag if you want subdomains to have a different policy, and don't assume without checking.
• Forwarding and mailing lists: these break SPF always and DKIM when they modify the message, so some forwarded copies of your mail will fail DMARC no matter what you do. That is expected. Aligned DKIM survives clean forwarders, and ARC-aware receivers honor a trusted forwarder's chain. Don't weaken your policy over forwarded failures; they are noise, not your problem.
• Keep reading the reports after you reach reject. New senders appear (a new tool, a new campaign), and you want to catch them before someone complains.

The takeaway

None of this is hard, it is just patient. The domains stuck at p=none are not stuck because the last step is difficult; they are stuck because nobody went back to read the reports and finish. Block out the couple of weeks, work the sources one at a time, and you get real protection instead of a record that only looks like it.

Disclosure: I'm the founder of Relaymetry, a free SPF/DKIM/DMARC/MTA-STS checker. I wrote a step-by-step version with the exact record changes here if you want a checklist to work from.