DMARC

The Safe Path From p=none to p=reject: A DMARC Enforcement Playbook

August 26, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

Every domain that publishes a DMARC record starts in the same place: p=none. It is the correct starting point, and it is also where far too many domains quietly stay for years, collecting reports that nobody reads while offering zero protection against spoofing. Getting from that first record to a fully enforced p=reject policy is not a settings change. It is an operational project with a data-dependent timeline, and treating it as anything less is how MSPs end up with client invoices bounced, marketing campaigns silently junked, or a help desk queue full of "where did my email go" tickets.

What is the actual difference between p=none and p=reject?

Under RFC 9989, the standards-track document that now defines DMARC, p=none asks receivers to evaluate and report on authentication results without changing delivery, while p=reject instructs receivers to discard messages that fail SPF and DKIM alignment. The gap between them is the entire point of DMARC: one policy is pure observation, the other is enforcement that actually stops spoofed mail from reaching an inbox. A domain parked at p=none is, for spoofing purposes, indistinguishable from a domain with no DMARC record at all.

That gap is exactly why the safe path matters. In 40 to 60 words: the safe path means holding at p=none long enough to capture aggregate reports from every legitimate sending source, fixing SPF and DKIM failures for each one, then moving to p=quarantine at a low enforcement percentage before advancing to p=reject only once reports show clean alignment across a full reporting cycle, typically several weeks.

Why the rollout got more urgent this year

Google and Yahoo have required DMARC records from anyone sending more than 5,000 messages a day since February 2024, and Microsoft followed with its own high-volume sender enforcement on May 5, 2025. Google's own sender guidelines state plainly that bulk senders must authenticate mail and that noncompliant traffic risks being sent to spam or rejected outright, a mandate the Gmail Help sender guidelines spell out in detail. Microsoft's enforcement works the same way: high-volume senders that fail to meet the authentication bar have their mail routed to junk or rejected with a specific error code once the grace period ends, according to Microsoft's own Defender for Office 365 documentation.

On top of those provider mandates, the DMARC specification itself changed for the first time in over a decade. In May 2026 the IETF published RFC 9989 along with companion documents RFC 9990 and RFC 9991, together obsoleting the original RFC 7489 from 2015 and moving DMARC onto the formal Standards Track for the first time. The update is not cosmetic for anyone running an enforcement rollout. RFC 9989 retires the ambiguous pct tag, which was meant to ramp enforcement by percentage, in favor of a testing flag: when t=y is set alongside p=reject, receivers apply quarantine instead, and when set alongside p=quarantine they apply none, giving domain owners a defined one-step-down staging behavior rather than a probabilistic sample. The same RFC adds an np tag that lets a domain set a distinct policy for subdomains that do not exist in DNS at all, closing off a common spoofing pattern where attackers invent plausible-looking subdomains that were never registered.

Building the monitoring baseline

Nothing in a safe enforcement plan matters more than the quality of the aggregate report data collected during the p=none phase. Every legitimate sending source, including the marketing platform, the helpdesk ticketing system, the accounting software that emails invoices, and any third-party vendor sending on the domain's behalf, has to show up in reports with passing SPF or DKIM alignment before enforcement can safely tighten. RFC 9990 formalizes exactly what receivers should include in those aggregate reports and how domain owners should request them via the rua tag, which is why parsing the reports rather than skimming subject lines is the actual work of this phase.

Google's own troubleshooting guidance is direct about the failure mode this phase exists to prevent: if SPF and DKIM are not fully set up before DMARC enforcement begins, messages sent from the domain are likely to run into delivery problems, a warning documented in Google's DMARC troubleshooting guide. This is the phase where an MSP earns its fee. Manually parsing XML aggregate reports across a client portfolio does not scale, which is one reason platforms built for this workflow, including the scanning and monitoring built into ActiScan, exist to surface unauthenticated senders automatically rather than leaving a technician to eyeball raw report data every week.

The four-stage sequence

A defensible rollout typically runs through four stages, and skipping any of them is the single most common cause of enforcement rollbacks:

• Stage 1, publish and observe (p=none): Set rua reporting and let data accumulate for at least two to four weeks, long enough to capture weekly and monthly billing cycles from every sender.
• Stage 2, remediate: Add SPF includes and DKIM selectors for every legitimate source identified in reports, then re-check for a full cycle to confirm the fixes hold.
• Stage 3, partial enforcement (p=quarantine): Move to quarantine, using the t=y testing flag under RFC 9989 or a low pct value under the older syntax, so failures land in spam rather than being silently dropped while confidence builds.
• Stage 4, full enforcement (p=reject): Advance once reports show consistent alignment with no unexplained failures, understanding that the rollout is never truly finished since new vendors and IP changes require ongoing review.

The timeline for that sequence varies enormously by client complexity. A single-tenant domain sending only through Microsoft 365 might safely reach p=reject within six to eight weeks. A domain with a dozen marketing, CRM, and helpdesk integrations, each with its own sending infrastructure, often needs several months of report review before quarantine, let alone reject, is safe. Rushing that timeline to hit an internal quota is how legitimate invoices and password resets start bouncing.

Where enforcement rollouts actually break

The most common cause of a failed cutover is not a misconfigured DNS record. It is an unaccounted-for sending source that never showed up clearly in earlier reports because its volume was too low or its identifying details were buried in report XML that nobody reviewed closely. A payroll provider that emails once a month, a CRM plugin that sends transactional receipts, or a legacy internal relay are exactly the kind of senders that get missed until the domain hits p=reject and a client suddenly reports missing mail.

Subdomain policy is a second common gap. RFC 9989's np tag exists precisely because attackers frequently spoof subdomains that were never provisioned, and a domain that only sets sp= for its known subdomains while leaving nonexistent ones uncovered still has an open door. Setting np=reject alongside a monitored primary policy closes that gap at effectively no operational risk, since no legitimate mail should ever originate from a subdomain that does not exist in DNS.

Getting a client portfolio to enforcement without breaking mail flow

For an MSP managing dozens or hundreds of client domains, the honest answer to how long this takes is that it depends entirely on how many distinct senders each domain has and how disciplined the report review process is. Trying to run that review manually across a large portfolio, one client at a time, in a mail client inbox full of gzipped XML attachments is not a sustainable model. That is the specific gap that structured scanning tools are built to close, and it is worth working through what a realistic rollout timeline looks like for a given client base before quoting a deadline to anyone, a process the getting-started guide walks through step by step for teams new to running enforcement projects at scale.

None of this guarantees a specific outcome for any given domain. What it does is replace guesswork with report-driven decisions at each stage, which is the difference between an enforcement rollout that holds and one that gets rolled back within a month of going live. Teams that want to see what portfolio-wide DMARC monitoring looks like in practice, including which client domains are safe to advance and which still have unresolved senders, can compare plans on the pricing page or start directly from the signup page to begin pulling live report data rather than waiting for the next spoofing incident to force the conversation.

The standard itself just changed for the first time in a decade. The underlying discipline that makes enforcement safe, reading the reports before tightening the policy, has not changed at all.