Readiness checklist: when is a domain ready for p=reject?

3. SPF stays under 10 DNS lookups

SPF caps at ten DNS lookups. Beyond that, evaluation returns a PermError and SPF fails — even with an otherwise "correct" record. Stacking one include: per vendor blows past that ceiling faster than expected. The counter needs checking before any hardening, or the whole thing leans on DKIM alone without anyone knowing. The topic is covered in depth in the SPF "too many DNS lookups" error. Box ticked when the SPF resolves under ten.

4. The subdomains are covered

An attacker who can no longer forge the root domain falls back on subdomains — including ones that don't exist. The default subdomain policy inherits p, but driving it explicitly with sp is the better move, alongside locking down non-existent subdomains with DMARCbis's np tag. It's a fast, risk-free win: no legitimate mail leaves a subdomain that doesn't exist. Details in the DMARC subdomain policy (sp and np). Ticked when sp and np are set and consistent with the root.

5. Reports have been flowing and "clean" for several weeks

Hardening happens on a trend, not on a snapshot. Reports accumulate for several weeks — enough to catch monthly senders (billing, statements, quarterly campaigns) and not just daily traffic. "Clean" means the only IPs still failing alignment are unrecognized sources — that is, impersonators. If legitimate sources still fail, box 2 gets another pass: a single stubborn source is enough to justify waiting another cycle, because that source will generate real bounces the moment enforcement lands. On making sure reports actually arrive, see configuring the rua address and not receiving DMARC reports.

A word on the secrets underpinning all this: private DKIM keys are critical credentials. Storing them in a file lying around on a server or pasted in a ticket is a risk in itself; a dedicated vault like Hucency Vault (from cybersecurity vendor Hucency) keeps a signing key from leaking and letting a third party send aligned mail in the domain's name — the one case where p=reject protects nothing.

6. The tooling and monitoring cadence are ready

Hardening the policy is not "publish and forget." Who watches the reports after the change, how often, and for how long: those get decided up front. A good practice: quarantine first, watched for a few days, then reject. The historic ramp ran on pct; DMARCbis (2026) removes pct in favor of a test mode (t=y) and an observation-driven ramp. Progressive rollout is detailed in rolling out DMARC gradually. A name and a calendar reminder belong against this box: an owner who checks the reports on day one, day three and day seven after each policy bump turns "we hardened DMARC" from a hopeful push into a controlled change, reversible the moment something looks wrong.

7. The choice is made: quarantine or reject?

Not every organization needs to jump straight to reject. p=quarantine is already a real defense and stays reversible if something slipped through. The choice depends on risk tolerance and on how critical the mail flow is — that's the subject of p=quarantine or p=reject: which to choose. This box ticks when the decision is made consciously, not by default. A bank and a five-person consultancy can both be "ready," yet land on different answers; readiness is about knowing the risk, not about reaching a single mandatory endpoint.

The pitfalls that empty an already-ticked box

A checklist only helps if the boxes stay ticked. Three classic regressions undo otherwise solid work:

• A new source appears unannounced. Marketing spins up an A/B testing platform, HR switches payroll tools, a subsidiary sends under the brand. Each arrives unaligned and gets refused under reject. The fix isn't to freeze everything, but to keep an eye on reports after hardening: a new IP failing alignment is either an impersonator or a source to onboard — and knowing which one, before an important email drops, is the whole point.
• A DKIM key expires or is rotated badly. A botched rotation breaks alignment at a stroke, for an entire source. That's why box 5 asks for a trend, not a snapshot — and why rotation must be documented and monitored.
• An SPF renewal dips back under ten lookups… then over. One include: too many flips the record back to PermError. The box-3 counter isn't a one-time check, it's ongoing hygiene.

None of this is a reason to stay at p=none — that would mean forgoing all protection out of fear of a reversible incident. It's a reason to treat post-hardening monitoring as part of the project, not an optional chore.

What p=reject does not cover (and mustn't invite complacency)

Ticking the seven boxes closes direct spoofing of the domain: nobody can send a forged From: user@example.com that lands in the inbox. But DMARC blocks neither lookalike domains (examp1e.com, example-support.com), nor display-name spoofing (an "Example Corp" label on some random Gmail address), nor compromised legitimate accounts. p=reject is a necessary layer, not the only one. Naming it here heads off the false sense of security that often follows a successful migration — the "I know what this doesn't cover" box is mental, but it counts.

Picking the moment, and telling people

One box that isn't technical at all: timing and communication. The policy should not flip on the morning of a major campaign, an invoicing run, or while half the team is away — if something did slip through the checklist, quiet traffic and available people beat the busiest sending day of the year. The teams who depend on email get told that the change is happening and what a symptom would look like ("a recipient says our message never arrived"), so the first signal arrives through a colleague rather than through a lost deal discovered weeks later. Support and helpdesk deserve a heads-up too: they're often the first to hear about delivery problems. None of this appears in a DNS record, and all of it shortens the distance between an incident and its fix.

The verdict

All seven boxes ticked means eligible — the hardening can go ahead. A single one left empty names the next task, and names it precisely. The beauty of the checklist is that it turns an anxiety-inducing decision ("what if I break everything?") into a factual review: either the data says yes, or it points exactly to what's missing, with no room for intuition or hope.

One last reflex before publishing the new record: the domain, run through the free DMARC analyzer, shows from the outside what receivers will see — alignment, policy, subdomains, SPF. It's the final check that catches typos and last-minute regressions. And to track progress over time rather than in a snapshot, the DMARC Observatory places a domain against its sector. p=reject is not an act of bravery; it's a fully ticked checklist.