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), with the pct sampling tag at /learning/glossary/dmarc-pct. This page is about the order, the evidence to collect at each stage, and when you are actually ready to advance.

Both major receivers publish rollout guidance. Microsoft's walks the full sequence: none, then quarantine, then reject. Google's has you start at p=none with aggregate reporting and phase in quarantine with pct, and presents reject as the stricter option you "can use instead of the quarantine if required." Finishing at reject is this page's recommendation (it matches Microsoft's sequencing), because only enforcement stops spoofing. Google's tutorial says a week of daily reports is usually representative; Microsoft's guidance is to start with a low-volume subdomain and save the parent domain for last. Neither vendor publishes a total timeline, because the honest answer is that your report data decides it.

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 ramping pct through quarantine, 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 pct back down, or drop the policy back a 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. So spend your risk budget at p=quarantine: ramp pct there, watch reports and spam-folder complaints, and only take the last step when quarantine at 100% has run clean.

One caveat on partial enforcement: pct sampling makes a misfire smaller, not visible earlier. A sender that fails alignment at pct=10 fails at 100 too. The ramp buys you a smaller blast radius while you confirm the reports were telling the truth, which is exactly what it is for.

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, moving the pct, and rolling back when a vendor silently changes their 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.