How do I move from DMARC p=none to p=reject?

The move from monitoring to enforcement is the whole point of DMARC, and it is also where domains get hurt. Jump straight to p=reject and every legitimate tool that sends as your domain but fails alignment (a CRM, a billing system, a newsletter platform someone connected two years ago) starts getting its mail refused. The staged rollout exists so you find those senders in reports before receivers find them for you.

The mechanics are simple: DMARC policy is one DNS TXT record, and the policy tag steps through three values. What each value does is covered in the glossary entries for p=none (/learning/glossary/dmarc-p-none), p=quarantine (/learning/glossary/dmarc-p-quarantine), and p=reject (/learning/glossary/dmarc-p-reject). The separate pct glossary entry explains why the old sampling tag is now historic. This page is about the order, the evidence to collect at each stage, and when you are actually ready to advance.

Google and Microsoft still publish older examples that use pct, but RFC 9989 removed that tag in May 2026 after inconsistent receiver implementation. Keep the useful parts of their rollout advice: start at p=none with aggregate reporting, test a low-volume subdomain before the parent domain, and advance only when the data is clean. Finishing at reject remains the goal because only enforcement stops direct-domain spoofing.

Aggregate reports are the evidence that says advance or wait. Each report lists every source IP that sent mail claiming to be your domain, the volume, and whether SPF and DKIM aligned. Your job at p=none is to sort those sources into three buckets: legitimate and passing (fine), legitimate and failing (fix before you enforce), and not yours (the spoofers enforcement will cut off).

The legitimate-and-failing bucket is the work. For each source, get it aligned: add the service to your SPF record, or turn on custom DKIM signing with your domain at the service, so at least one of the two aligns with your From domain. The common trap where raw SPF passes but DMARC still fails is alignment, covered in the sibling page linked below on DMARC failing while SPF passes.

You are ready to leave p=none when the failing-but-legitimate bucket has been empty (or a knowingly accepted loss, like unfixable forwarded mail) for a full reporting cycle across all your mail streams. Monthly newsletters mean a monthly stream; if you send one on the 1st, a week of reports in mid-month never saw it. That is the strongest argument for stretching the monitoring stage past Google's one-week minimum.

A single domain that only sends through one platform, say Google Workspace plus one ESP, can go end to end in four to six weeks: one to two weeks at p=none, two to three weeks validating full quarantine on a lower-risk scope, then reject. A domain with eight SaaS tools sending as it, some owned by marketing and some by nobody, is a two-to-four-month project, and almost all of that time is chasing the owners of misaligned senders, not editing DNS.

The calendar is not the constraint; coverage is. Each stage ends when a full cycle of every mail stream has reported clean, and slow streams (monthly invoices, quarterly statements) stretch the schedule. Rushing a stage does not make the misaligned sender go away; it just moves the discovery from a report you read to a bounce your CEO forwards you.

Set the record's TTL to something short (an hour) while you ramp. It makes every step, forward or backward, take effect quickly, and it costs nothing.

The rollback mechanism is the same DNS edit as the rollout: drop the policy back one level, and receivers honor the new record as soon as the TTL expires. There is no penalty box for retreating; DMARC has no memory of your previous policy.

The asymmetry between the two enforcement levels is why the quarantine stage exists at all. Mail wrongly quarantined lands in spam folders and can be found, released, and used to diagnose which sender you missed. Mail wrongly rejected is gone; the sender gets a bounce and the recipient gets nothing. Watch reports and spam-folder complaints at full p=quarantine, and move to reject only after that scope has run clean for a full cycle.

Without pct sampling, reduce blast radius structurally: start with a lower-volume subdomain or a simpler domain, keep a short TTL, and predefine the one-step rollback to p=none. That produces a deterministic policy instead of depending on receiver-specific sampling.

Nothing above is secret. Google and Microsoft both publish the stages, and every DMARC monitoring product will show you the failing senders. What monitoring tools do not do is the middle of the playbook: chasing alignment fixes across eight SaaS vendors, deciding when a stream has truly run clean, sequencing lower-risk scopes, and rolling back when a vendor silently changes its sending infrastructure. That is why so many domains sit at p=none for years with a dashboard nobody opens.

This ramp, from first report to a held p=reject, is exactly what Palisade's agent executes: it hosts the DMARC record, reads the reports, walks the policy up as sources come into alignment, and holds enforcement afterward. Monitoring is the means; p=reject is the product.

Across a client book, run the rollout as a portfolio, not fifty parallel snowflakes. Baseline every client domain at p=none with reporting on day one of onboarding; the aggregate reports then tell you which clients are two DNS edits from reject and which have a shadow-IT sender problem. Sequence by risk and simplicity: parked domains straight to reject, single-vendor domains next, the multi-tool marketing domains last. The stage gates are identical for every tenant, which is what makes this automatable: Palisade hosts the SPF, DKIM, and DMARC records per client domain, walks each one to p=reject as its reports run clean, and holds enforcement after, with ConnectWise, HaloPSA, and Autotask integrations so stage changes and new-sender alerts land in your PSA. Your own MSP domain is a free NFR domain to run the ramp on first.