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 two things and neither of them is protection. It satisfies the bulk sender checkbox at Gmail and Yahoo, and it asks receivers to tell you what they saw. It stops exactly zero spoofing. If your DMARC record has said p=none for over a year, it isn't 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: asks receivers to route failing mail to spam instead of the inbox. Disposition is always the receiver's call, but in practice this means the junk folder. Real enforcement with a soft landing: a false positive annoys someone, it doesn't bounce a message they were expecting.p=reject: failing mail is refused during the SMTP transaction with a 5xx. The receiver isn't bouncing anything back, it's declining to accept the message at all. A legitimate sender gets an NDR from their own provider. A spoofer gets nothing, which is the point. 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 part that trips people up: alignment
An SPF pass is not a DMARC pass. DMARC needs SPF or DKIM to pass and the domain that passed to match the domain in the visible From header. The pass is half the requirement.
A vendor sending on your behalf with their own bounce domain produces a clean SPF pass and a DMARC fail, because the SPF domain is theirs and the From domain is yours. That mismatch is behind most of the failures sitting in your aggregate reports right now. "SPF is passing" and "this source is safe to enforce against" are different claims.
The t tag is your safety valve
You don't have to jump straight from none to full enforcement:
v=DMARC1; p=quarantine; t=y; rua=mailto:[email protected]
t=y is the testing flag from RFC 9989, the DMARC revision published in May 2026. It puts the policy in testing mode: receivers apply the level below what you published. p=quarantine; t=y behaves like none, and p=reject; t=y behaves like quarantine. That gives you a five-step ladder instead of a percentage dial:
p=nonep=quarantine; t=yp=quarantinep=reject; t=yp=reject
One caveat: t is only honored by receivers that have implemented RFC 9989, and adoption is phased. Receivers still running the old spec ignore unknown tags and apply your published policy in full, so p=reject; t=y will produce real rejections at some of them. Treat the p=quarantine step as the actual safety net, not the testing flag.
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.
If your record still has pct
Take it out at your next DNS edit. RFC 9989 removed pct because receivers implemented it inconsistently and values other than 0 and 100 were unreliable across the ecosystem. The 25/50/100 ramp that every rollout guide recommended for a decade was never applied the way operators assumed it was.
pct=0 maps to t=y. Anything else maps to nothing. Conforming receivers now ignore the tag entirely, so leaving it in adds noise without doing anything. rf and ri were removed in the same revision and can go at the same time.
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, or where the platform authenticates with its own domain and never gets alignment.
- Forwarded mail. DMARC's interaction with forwarding is a known rough edge, and forwarding breaks SPF by design.
That last one has a real fix, and it isn't a percentage tag. DKIM signatures survive forwarding; SPF doesn't. Getting an aligned d= on every sending source eliminates most forwarding failures outright. What's left is mailing lists that modify the message body and break the signature, which is why RFC 9989 explicitly warns against publishing p=reject on a domain whose users post to mailing lists without measuring the impact on indirect mail first.
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 in testing mode, keep watching reports, and only push toward reject once you're not seeing surprises.
Three things you can do before you touch p
Publish np=reject. This is new in RFC 9989 and it's the cheapest win available. np sets the policy for subdomains that don't exist in DNS. There is no legitimate mail from a subdomain you never created, so rejecting it carries no deliverability risk at all, and it closes a spoofing gap that attackers use constantly. It works while your main policy is still p=none.
Set sp= deliberately. Without it, subdomains inherit whatever p says. If your org domain is at none and a subdomain is ready for enforcement, or the reverse, say so explicitly. RFC 9989 also replaced the Public Suffix List with a DNS tree walk for policy discovery, so publishing at your organizational domain covers the tree in one record.
Verify your rua destination. If your reports go to an address on a different domain, that domain has to publish a _report._dmarc TXT record authorizing it. Miss this and receivers silently drop your reports. It's a top reason people conclude "DMARC isn't working" when the record itself is fine.
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 that: how many identified sending sources are aligned, what's still failing, and whether it's safe to advance to the next step on the ladder, so the decision 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.