p=none is the right place to start with DMARC. It's also, for a lot of domains, where things quietly stop: the record goes in, the reports start flowing, and nobody ever revisits it. That's a problem, because p=none does exactly one thing: it asks receivers to tell you what they saw. It does nothing to stop anyone from spoofing your domain. If your DMARC record has said p=none for over a year, it's not really protecting anything, it's just watching.
What each policy level actually does
v=DMARC1; p=none; rua=mailto:[email protected]
p=none: no enforcement. Every message is delivered regardless of DMARC result; you just get reports. This is correct for the first weeks of any rollout, because it lets you find every legitimate sending source before you risk blocking one.p=quarantine: mail that fails DMARC gets routed to spam instead of the inbox. This is real enforcement with a soft landing: a false positive annoys someone by landing in their spam folder, it doesn't bounce a message they were expecting.p=reject: failing mail is rejected outright, typically bounced back to the sender. This is full enforcement and the actual goal of the whole exercise, but it's also the level where a missed sending source turns into a real delivery failure instead of a report you can review later.
The pct tag is your safety valve
You don't have to jump straight from none to 100% enforcement:
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]
pct=25 tells receivers to only apply the stated policy to roughly a quarter of failing messages, leaving the rest to be delivered as if the policy were none. This lets you dial up enforcement gradually (25%, then 50%, then 100%) while watching your reports at each step for anything unexpected. There's no fixed timeline that fits every domain: the right pace is "long enough to be confident the reports have gone quiet for the sources you don't recognize," which might be a week for a simple setup or a couple of months if your domain has a lot of legacy senders you're still tracking down.
What actually stalls a rollout
Almost always, it's an unidentified sending source still showing up in aggregate reports as failing DMARC. Common culprits:
- A legacy internal tool or cron job that's been sending transactional email through an unauthenticated relay for years.
- A marketing or support platform where someone enabled a feature (like sending "on behalf of" your address) without updating SPF.
- Forwarded mail: DMARC's interaction with forwarding is a known rough edge, and a small percentage of legitimate forwarded mail failing SPF is often unavoidable, which is one more reason
pctexists.
The instinct to leave the policy at none "until everything is clean" is understandable but usually means it never happens: there's rarely a moment where the reports show zero unexplained failures, because new tools and integrations get added faster than old ones get cleaned up. The better approach is incremental: move to quarantine at a low pct, keep watching reports, and only push toward reject once you're not seeing surprises.
Tracking readiness without guessing
The genuinely hard part of this isn't the DNS record, it's knowing when you're actually ready to tighten it. MyDMARC's policy view tracks exactly this: how many identified sending sources are aligned, what's still failing, and whether it's safe to move your pct up, so the decision to advance enforcement is based on your actual report data instead of a guess. And since your policy lives entirely in a DNS TXT record, it's worth having OneDollarDNS watch that record too; a policy that silently reverts to p=none after a DNS migration defeats the entire point of getting here in the first place.