Getting to DMARC p=reject: the safe route to enforcement

There is a graveyard of good intentions in UK DNS records: DMARC policies published at p=none in 2021, 2022, 2023 - each one a project that started correctly and then stalled at the monitoring stage, where it blocks nothing and will sit forever unless someone finishes the journey.

p=reject is the destination because it is where Domain-based Message Authentication, Reporting and Conformance (DMARC) actually does its job: receiving servers refuse unauthenticated mail claiming to be from your domain, and exact-domain spoofing stops reaching inboxes. It is the policy the National Cyber Security Centre (NCSC) recommends for all domains, and the level its Cyber Assessment Framework requires of in-scope organisations.

The journey from none to reject is not difficult, but it is sequential, and every stage is driven by one source of truth: your aggregate reports. Here is the route, stage by stage, including the blockers that stall most organisations - because knowing them in advance is most of the cure. (If you need the foundations first: Why p=none is not protecting you.)

Stage 1: Monitor at p=none - and actually read the reports

Publish (or confirm) your record at p=none with a working rua= reporting address, then collect data. The goal of this stage is a complete inventory of everything legitimately sending as your domain - and “complete” is the operative word. Two weeks of reports catches your daily senders; it misses the monthly payroll run, the quarterly statement mailer, the annual renewal system. Four to six weeks is the sensible minimum, longer if your business has seasonal sending.

What to look for in the reports at this stage: every distinct sending source, identified and classified. Each one is either ours (your mail provider, your invoicing platform, your CRM, the scanner in the corner) or not ours (the spoofers - and most domains discover some). The “ours” list is your work queue; the “not ours” traffic is your motivation. A walkthrough of reading the raw data is in What does a DMARC report actually show?.

Stage 2: Fix authentication for every legitimate sender

Each legitimate source must pass aligned SPF or DKIM - meaning the authentication must tie to your actual domain, not merely to the sending platform’s own. For each service on your list, this generally means following its instructions to add DKIM records for your domain, and ensuring its servers are within your SPF record without breaching the 10-lookup limit (the silent record-breaker covered in What is SPF?).

This is where the common blockers live:

• Third-party senders with poor authentication support. Most reputable platforms now support custom-domain DKIM; a long tail do not, or hide it behind premium tiers. Your options: upgrade, replace the service, or move its sending to a subdomain with its own policy.
• Shared hosting. Websites that send mail through the hosting company’s shared servers (contact forms, shop notifications) often cannot authenticate cleanly for your domain. The robust fix is routing site mail through a proper transactional provider - usually cheap and quick.
• The forgotten and the feral. Departmental tools nobody declared, a franchisee’s mailer, the alarm system that emails. The reports will surface them; expect a few surprises and budget the time to chase each one.

Do not move on until the reports show your known-legitimate sources passing consistently. A clean fortnight is a good benchmark.

Stage 3: Quarantine - enforcement with a safety net

Move to p=quarantine. Failing mail now goes to recipients’ junk folders rather than vanishing - meaning if you missed a legitimate sender, its mail is recoverable and the failure is visible, not silent.

Two tools make this stage gentler. The pct= tag applies your policy to a percentage of failing mail - p=quarantine; pct=25 quarantines a quarter of failures, letting you ramp 25 → 50 → 100 while watching for trouble. And the reports remain your eyes: at this stage you are looking for any legitimate source appearing among the quarantined. Each one you find is a Stage 2 fix you missed; fix it, give it a clean week, continue. Plan for two to four weeks at quarantine - long enough to cover your sending cycles.

Stage 4: Reject - and keep monitoring forever

When quarantine has run cleanly across a full sending cycle, move to p=reject. Spoofed mail is now refused outright; your domain’s name is no longer freely borrowable.

Two finishing touches the NCSC guidance is explicit about. First, check your subdomain policy (sp=) - a domain at reject with subdomains uncovered is a door locked next to an open window. Second, your parked domains - the ones you own but never send from - need locking down too; they are at reject in five minutes since nothing legitimate can break.

And then: monitoring does not end. This is the part the graveyard of stalled records gets backwards - monitoring is not the phase before protection, it is permanent. New services get added by colleagues who have never heard of DMARC; DKIM keys rotate; SPF records drift. At reject, an authentication failure means legitimate mail being refused, so the reports matter more after enforcement, not less.

The honest effort estimate

For a typical small organisation: one to three months elapsed, of which the actual work is a few hours of DNS changes and service configuration - the rest is disciplined waiting and report-reading. The discipline is precisely what stalls the stalled: reading XML reports weekly for months is nobody’s favourite job. That reading is what SealedMail does for subscribers - each weekly plain-English report tells you where you are in the journey, what the data shows, and when it supports the next move, for £49 per domain per month.

Wherever you currently are - no record, stalled at none, or unsure - the starting point is the same two-minute step: SealedMail’s Free Domain Health Check confirms your current policy, your reporting setup and the health of everything the journey depends on, by email, free, no sign-up.