01What p=none is not doing for you
p=none asks receivers to evaluate your mail, report what they saw, and then do exactly what they would have done anyway. It is a measurement instrument, and a good one. What it is not is a protection: a domain sitting at none has published a policy that instructs the world to take no action, which protects it from precisely nobody.
Until you enforce, anyone can put your domain in a From header and the receiver has been told, by you, not to mind.
- Receivers evaluate your mail and report what they saw
- A measurement instrument, and a good one
- Any protection at all — receivers were instructed to take no action
- Bulk-sender eligibility: a published, enforced policy is now a requirement at the large consumer mailbox providers rather than a nice-to-have
- BIMI, which will not consider a domain below quarantine
The reason people stay at none for years is not laziness. It is that the first time you enforce, you find out which of your own systems were never authenticated, and you find out by way of them not arriving. The whole discipline below exists to move that discovery from “customers did not get their invoices” to “a row in a report last Tuesday”.
Before any of this, the records have to be right. SPF authorises the envelope sender, DKIM signs the message, DMARC checks that one of those passed for the domain in the From header. If that last clause is not yet familiar, start at SPF, DKIM and DMARC, which has a builder that generates the exact rows for your transport.
02Reading an aggregate report without a spreadsheet
An aggregate report is an XML file, usually gzipped, that arrives daily from each receiver that saw mail claiming to be you. It contains no message content and no recipient addresses — it is counts, grouped by sending IP, with the SPF and DKIM results and the DMARC disposition for each group. Three columns matter: source, volume, pass rate.
<record>
<row>
<source_ip>203.0.113.9</source_ip>
<count>1842</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf> ← aligned DKIM carried it
</policy_evaluated>
</row>
</record>Sort by volume, descending, and work down. Each <record> is one sending source over one day, and reading one by hand once is worth doing so that the aggregators stop feeling like magic. Your transport should be at the top with a pass rate at or near 100%; if it is not, stop the rollout and fix that first, because nothing below matters while your main sending path is failing. Then you are looking at a long tail, and every entry in it is one of five things.
| Source | Volume | Result | What it is |
|---|---|---|---|
| Your transport | High | ~100% | The boring one. Leave it alone. |
| A corporate gateway | Low, steady | SPF fails, DKIM passes | A forwarder. Harmless — DKIM survived the hop, so DMARC still passes. |
| A mailing list | Low, bursty | Both fail | The list rewrote the body or the headers and broke the signature. Real mail, genuinely unauthenticated. |
| Your billing vendor | Low, monthly | Both fail | A sending path nobody documented. This is the one that hurts at reject. |
| Hosts you have never heard of | Anything | Both fail | Forgery, or a scanner replaying your mail. Nothing to authorise. |
- SPF fails, DKIM passes, volume low and steady, source is a university, a corporate gateway or a mail-hosting provider
- Somebody subscribed with a work address that forwards elsewhere
- SPF breaks on forwarding by construction — the forwarder is not on your list and never will be — while the signature travels with the message, so DMARC passes on DKIM alignment alone
- Costs you nothing at reject, and is the single best argument for publishing DKIM even when SPF already passes
- Both fail, from a residential or hosting range you do not recognise
- Volume is either very small (a targeted attempt) or very large and spiky (a campaign)
- There is nothing to authorise here and nothing to fix. These rows are the reason you are doing this
03none → quarantine at 25% → quarantine → reject
Four rungs, roughly two weeks each. The point of the intermediate rungs is not caution for its own sake — it is that each one exposes a different set of failures at a survivable cost.
| Rung | Dwell | What it costs you, and what it buys |
|---|---|---|
| p=none | Two weeks minimum | Stay here until you can name every source in the report. The exit condition is not a date, it is an inventory: a list of sending systems, each either authenticated or knowingly abandoned. |
| p=quarantine; pct=25 | Two weeks | The first rung with consequences, deliberately applied to a quarter of failures. Watch your support queue as closely as the reports — a quarantined message is in a spam folder, so it will be reported to you by a human before it shows up in an aggregate feed. |
| p=quarantine | Two weeks | Drop the pct tag entirely rather than writing pct=100. This is the last rung where a mistake is recoverable by the recipient — everything failing is retrievable from a spam folder. |
| p=reject | Permanent | Failing mail is refused at SMTP time. The sender gets a bounce; the recipient gets nothing and never knows. This is the correct end state and it is also the first rung with no undo, which is why the three below it exist. |
pct= is a fractional dose of a policy. It tells receivers to apply your policy to that percentage of failing messages and to fall back to the next-weaker policy for the rest. At p=quarantine; pct=25, three quarters of failing mail is treated as if the policy were none, and one quarter goes to spam — so a sending path you forgot about surfaces as a support ticket from one user in four rather than from everyone at once, which is the difference between a discovery and an outage. Note the tag is ignored at p=none: none has nothing weaker to fall back to.
v=DMARC1; p=none; rua=mailto:[email protected] v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected] v=DMARC1; p=quarantine; rua=mailto:[email protected] v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]
Why two weeks and not two days. Because you are not waiting for data volume, you are waiting for a full business cycle. Daily transactional mail shows up in a day. Monthly invoicing shows up once a month, and a quarterly newsletter shows up once a quarter — and those are precisely the senders that surprise you, because they were configured years ago by someone who has left and they only fail on the day they run. Two weeks per rung with a monthly cycle in view is a compromise; if you know you have quarterly senders, hold at quarantine until one of them has fired.
04The two things that always break
Two things break, every time, on every domain with any history. Neither is a surprise and both are cheaper to handle in advance than to diagnose at reject.
- A traditional discussion list takes your message, appends a footer, sometimes prefixes the subject, and forwards it to hundreds of subscribers with your From address intact
- The footer changes the body, which breaks the DKIM signature; the forwarding breaks SPF; the From header still says you
- At reject, that message is refused by every subscriber whose mailbox provider honours DMARC — and the list, seeing bounces, may unsubscribe them
- Well-maintained list software solved this years ago by rewriting the From header to the list’s own domain and putting you in Reply-To. Mailman 2, an unattended Google Group, and a home-grown forwarder written in 2014 do not
- You cannot fix them from your DNS: get the list to enable From-rewriting, move that conversation off the enforced domain, or accept it — and accepting it is a real option, because a handful of people on an internal list is a different cost from customer invoices
- This is the one that actually causes incidents
- Every organisation past a few years old has a system sending as its domain that is on no inventory: an applicant tracking system, a survey tool, an e-signature service, a CRM, a status page, a legacy ticketing system, the invoicing platform finance chose without asking anyone
- They were configured by people who have since moved on, they authenticate as their vendor rather than as you, and they work perfectly right up until you enforce
The report is the inventory. That is the entire reason you sat at p=none for two weeks. Take each unrecognised source with real volume through the same three moves:
05sp= and the subdomain you forgot
sp= sets the policy for subdomains, and if you omit it subdomains inherit the parent policy. That inheritance sounds like it makes the tag unnecessary. It is exactly why the tag is dangerous: people set sp=none during a rollout to protect a subdomain they were unsure about, and then never take it off.
A domain publishing p=reject; sp=none is not protected. Your DMARC record is public, it is one TXT lookup, and it is the first thing any phishing kit checks.
- The end state
- Covers every subdomain you own, including the ones that do not exist yet
- A rollout artefact, left on
- An attacker sees the parent enforced and the children not, and sends from billing.yourdomain.com instead
- That subdomain is yours, it has no record of its own, it inherits none from the tag you left behind — and to a recipient it reads as more official than the bare domain rather than less
Close the subdomain gap on the same day you tighten the parent. If a specific subdomain genuinely needs to stay permissive — a vendor you have not migrated yet, a marketing platform mid-move — scope the exception to that one name rather than weakening sp for everything you own.
| Case | What to publish | Why that and not sp= |
|---|---|---|
| A subdomain that must stay permissive | Its own DMARC record at _dmarc.that-subdomain.yourdomain.com | A published record at the subdomain wins over the parent’s sp, so the exception is scoped to one name and expires when you delete it. |
| A parked domain or subdomain you never send from | v=DMARC1; p=reject; sp=reject; plus an empty SPF record, v=spf1 -all | No rollout needed and no risk to weigh, because there is no legitimate mail to break. It is the cheapest DMARC work available and almost nobody does it. |
Once the whole tree is at reject, the remaining deliverability questions are no longer about authentication at all — they are about reputation and list quality, which is the subject of why email goes to spam.
What just happened
You have a rollout that ends at p=reject and a way of knowing, before each step, what that step will bounce: read the reports, authenticate what you recognise, and only then tighten. The thing most likely to bite you is not the parent policy at all — it is sp=. A domain at reject with a permissive subdomain policy is a domain where every forger simply moves to billing.yourdomain.com, and the gap is closed by one tag on the same day.