p=reject is the goal, and it is one DNS edit away at any moment. The reason not to make that edit today is that you almost certainly have senders you have forgotten about, and at p=reject their mail stops being delivered — silently, from your point of view, because the rejection happens at the receiving end.
The path below is not a waiting game. Each stage exists to answer a specific question, and you move on when it is answered rather than when a number of weeks has elapsed.
The principle
You are not tightening a policy. You are building an inventory of everything that sends as your domain, and the policy follows the inventory. A team that knows all its senders can go to p=reject in a fortnight; one that does not should not go there in a year.
What p=none actually costs you
Nothing, in deliverability terms — and that is the trap. A domain can sit at p=none for years generating reports nobody reads, and it is exactly as spoofable as a domain with no DMARC at all. The record is not the protection; the enforcement is.
The stages
| Stage | Record | Question it answers | Move on when |
|---|---|---|---|
| 1. Observe | p=none; rua=… | Who sends as this domain? | Two full reporting cycles with no new sending sources appearing. Two weeks minimum — monthly and quarterly processes are the ones that surprise you. |
| 2. Fix | p=none | Can every legitimate sender authenticate and align? | Every source you recognise passes DMARC. Not SPF or DKIM individually — DMARC, which means aligned. |
| 3. Quarantine | p=quarantine | Did we miss anything that only shows up under enforcement? | A week or two with no complaints and no new failing sources. Failures now land in spam rather than being lost, which makes this the safe place to find out. |
| 4. Reject | p=reject; sp=reject | Done. | — |
Stage 2 is where the actual work is, and it is where most rollouts stall. Stages 1 and 3 are mostly waiting; stage 2 is chasing down a marketing tool nobody remembers buying and getting DKIM turned on for it.
Reading the reports
Aggregate reports arrive as gzipped XML, once a day per receiver. They are not readable by hand at any volume, but the structure is simple: for each sending IP, a count of messages and the SPF and DKIM results, with the domains each authenticated.
The questions worth asking of them, in order:
- Which sources do I not recognise? Some will be spoofing. Most, at the start, will be a service a colleague signed up for.
- Which recognised sources fail? Fix these before anything else. A high-volume legitimate sender failing is what turns enforcement into an incident.
- Which fail on alignment rather than authentication? A source showing SPF
passbut DMARCfailis an alignment problem, and the fix is different — usually enabling DKIM with your own domain rather than touching SPF. - What proportion of my volume passes? This is the number that tells you whether to advance. It should be high and stable, not high once.
If reports are not arriving at all, check external destination authorisation before assuming nothing is being sent — it is the most common cause and it is invisible from your side.
Signals you are not ready
- New sending sources still appearing. Every new one is something you would have broken. Wait for the rate to reach zero.
- A recognised sender that passes SPF but not DKIM. It will survive direct delivery and fail the moment anything forwards it. Get DKIM on before you enforce.
- SPF returning
permerror. Your record is over a limit and is failing for everyone. Fix that first — the SPF Inspector will say which limit. - No reports from the large receivers. If Google and Microsoft are missing from your reports, you are not seeing the majority of your mail, and the numbers you are reading are not representative.
- An annual process you have not seen run. The invoice run, the renewal notices, the thing that only fires in January. Enforcing in December is a specific kind of mistake.
On pct, and why it is not a dial
pct applies the policy to a random sample. It is genuinely useful as a ramp — p=quarantine; pct=25 limits the blast radius of a mistake to a quarter of your mail — but two things are worth knowing.
First, it is not a percentage of failures, it is a percentage of messages evaluated. Second, and more importantly, it is very easy to leave behind. p=reject; pct=10 reads like enforcement and delivers nine out of ten spoofed messages. If you use it, put a date in the calendar for removing it.
A finished record looks like GitHub's — enforcement, subdomains covered explicitly, full percentage, reporting on:
"v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1"
Set sp= before you need it
Subdomains inherit p= unless sp= says otherwise, so a domain at p=reject is already covered. The reason to set sp=reject explicitly is that it stays correct if someone later relaxes p= during an incident — attackers reach for subdomains precisely because they look more plausible than a look-alike domain.