How long does it take to reach p=reject?

The phase-by-phase breakdown

The journey to enforcement isn't a switch, it's a staircase. Each step has its own duration, and adding up those steps — rather than setting an arbitrary date — is what produces an honest timeline. The full method, step by step, is detailed in getting to p=reject without breaking email; here is the timing view.

Phase 1 — Observing at p=none (2 to 4 weeks)

A record goes up at p=none with a collection address, and then comes the listening. This phase protects nothing yet: it maps. Its sole purpose is to surface, through the aggregate reports, the exhaustive list of systems that send in the domain's name. The budget is two to four weeks minimum, for a simple reason: a full cycle of activity has to be seen. A sender that only fires once a month — a payslip, a statement, a periodic invoice run — won't appear in the first week's reports. Cutting before that cycle closes means tightening without knowing every source. To pull the right signal from these files, reading the daily returns is the reference.

Phase 2 — Fixing alignment, source by source

This is the phase that absorbs most of the calendar, and the most variable. Every legitimate sender identified in phase 1 has to reach SPF or DKIM alignment. Concretely: enabling DKIM signing at a provider, adding an SPF include, pointing a sending subdomain. The duration depends entirely on the third parties involved. A modern ESP surfaces the records to publish in two clicks; an old internal system might need development work. Sources get handled in descending order of volume: securing what sends the most mail first cuts the risk faster. The checklist that guards against a missed step here is the DMARC none-to-reject checklist.

Phase 3 — The quarantine step (with test mode)

Once the main sources are aligned, the jump straight to reject doesn't happen. The path goes through p=quarantine, which sends non-compliant mail to the junk folder rather than rejecting it outright — a safety net. This is where DMARCbis changes things: instead of the old pct tag (removed), test mode t=y takes over, signalling to receivers "I'm experimenting with this policy, report the gaps to me without enforcing it strictly yet". This mode allows the effect of a harder policy to be observed without risk, for as long as needed. How this lever works precisely is explained in the test-mode tag, which replaces pct to ramp up gently. The step lasts until the reports are clean: the quarantine-versus-reject debate is settled in quarantine or reject.

Phase 4 — Switching to reject

When the reports show nothing but aligned mail, and the only remaining failures are plainly spoofing, the policy moves to p=reject. It's the only state that actually protects a domain: fraudulent messages are refused at the door. Where the earlier phases were done well, this switch is a non-event — nothing breaks, because everything legitimate is already aligned. The overall rhythm and the rollout variants are covered in the staged rollout.

What matters isn't speed

Here's the message I hammer home with every client: the safety of the ramp beats its speed. p=reject is not a finish line with a medal for crossing first. It's an enforcement state that refuses mail — including the domain's own legitimate mail, if it isn't aligned. Rushing to reject with sources still misconfigured guarantees that an invoice, an order confirmation or a critical notification ends up rejected. The cost of one extra week of observation is nil. The cost of a premature reject is a production incident, customers who stop receiving their messages, and trust to rebuild.

That's exactly why "going fast" and "going well" must never be confused. A domain that reaches reject in three weeks but gets there by breaking two sources hasn't saved time: it has created an incident to be handled under pressure, often by rolling back to none — that is, by undoing all the work. The clean journey, by contrast, is monotonous: each step is cleared once the previous one is solid, and the final switch surprises no one.

Why so many domains stay stuck

Looking at the market's real posture, one thing jumps out: a large share of domains stay at p=none, sometimes for years. It's not laziness. It's almost always the absence of method. Teams publish a p=none, receive illegible raw reports, don't know which sources to align or in what order, and the project stalls for lack of a clear owner. p=none becomes a comfortable purgatory: it looks "done", but it protects nothing. This reality is observable sector by sector in the DMARC Observatory — how many domains still enforce no policy at all. The lesson isn't that reaching reject is hard; it's that reaching it without method is. With a source inventory, a priority order and a test step, the project becomes linear again.

How to shorten the timeline (without rushing it)

Speeding up cleanly is possible — by attacking the right bottlenecks:

• Inventorying early and completely. Lost time rarely comes from DNS configuration; it comes from sources discovered too late. An observation phase run to the end of its cycle spares the reruns.
• Attacking slow third parties first. Where a provider takes two weeks to enable DKIM, that ticket belongs on day one, not day last. These external delays parallelise: they all get kicked off at the same time.
• Prioritising by volume. Aligning the source carrying 80% of the mail first cuts the risk far faster than starting with a marginal sender.
• Naming an owner. The best accelerator isn't technical: it's a person responsible for the posture, with an up-to-date dashboard and the mandate to get records published. Without an owner, every phase drags.
• Using test mode instead of waiting idle. t=y allows a hard policy to be tested without enforcing it: confidence builds while the last sources get fixed, instead of the project staying stuck in pure observation.

Where the domain stands, today

The best starting point is an honest diagnosis of the current situation. A domain run through our free DMARC analyzer reveals in seconds whether it sits at none, quarantine or reject, and what stands between it and the next step. Placing that posture against the sector in the DMARC Observatory makes the rest plain: staying at none is the norm, not a fate.

Breaking down a timeline — inventorying the sources, prioritising them, knowing precisely when to tighten without breaking — is exactly what Thomas, the virtual CISO, automates: he names every source from the reports, assesses readiness on rolling data, generates the DNS to publish and indicates the precise moment to take the next step, from p=none all the way to p=reject. Free DMARC analysis · the DMARC Observatory · getting started with Thomas.