DMARC policy: none, quarantine or reject, and how to move between them
What p=none, p=quarantine and p=reject actually do, why most domains are stuck at none, and the staged path to enforcement that does not take your own email down.
A DMARC record has one tag that decides whether it protects you or merely observes you being impersonated. That tag is p=, the policy.
There are three possible values, and the gap between the first and the last is the difference between a record that exists and a record that works.
What each policy actually does
p=none — monitor only
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.comReceivers check the message, apply no consequence, and send you a report. Forged mail claiming to be your business is delivered exactly as it would be with no DMARC record at all.
This is not a criticism of p=none. It is the correct place to start, because it gives you visibility without risk. It is simply not protection, and a great many domains have been sitting here for years believing otherwise.
p=quarantine — treat as suspicious
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.comFailing messages are delivered to the spam or junk folder rather than the inbox. This is real protection: the forged invoice is far less likely to be seen, let alone paid.
It is not complete, because the message is still delivered. It sits in a folder people do check, and a convincing invoice found in spam still occasionally gets acted on.
p=reject — refuse outright
v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.comThe receiving server refuses the message during the SMTP conversation. It is never delivered, to any folder. Your customer never sees the forgery, because it never arrives.
This is the goal, and it is the step most providers never take.
Why most domains are stuck at none
Moving to enforcement carries a real risk, and it is not the risk people assume.
The danger is not that attackers get through. It is that your own mail stops. When you publish p=reject, every message that fails authentication is refused, and on day one the messages most likely to fail are your own: the invoicing platform nobody set up DKIM for, the CRM that sends quotes, the booking system, the newsletter tool a marketing contractor configured in 2023.
So the person responsible looks at p=none, sees that nothing is currently broken, and leaves it. Nothing is broken because nothing is being enforced. The record has become a checkbox rather than a control.
The staged path that does not break anything
1. Fix authentication first
Before touching the policy, every legitimate sender needs to authenticate. That means SPF listing every sending service and staying inside the ten-lookup limit, and DKIM signing configured on each service that sends on your behalf. SPF, DKIM and DMARC explained covers this groundwork.
DMARC cannot enforce anything safely until your real mail has something valid to pass against.
2. Publish p=none and actually read the reports
Set rua= to a mailbox someone will monitor, then wait two to four weeks. Aggregate reports arrive daily as XML from each major receiver, and they name every source sending mail as your domain.
This is where the surprises live. Almost every business discovers senders nobody remembered: an old marketing platform, a department’s own tool, a supplier sending statements on their behalf. Do not move on until you can account for every legitimate source in those reports.
3. Ramp with pct=
pct= applies the policy to a percentage of failing mail, so you can move in steps rather than all at once:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.comMove 25 → 50 → 100 over a few weeks, watching reports at each stage. If something you missed surfaces, only a quarter of it is affected and you can roll back in minutes.
Note that pct= behaves differently than most people expect at p=reject: mail not selected by the percentage falls back to quarantine, not to none. That is helpful, but worth knowing before you rely on it.
4. Move to p=reject
Once quarantine at 100% has run for a couple of weeks with clean reports, reject is a small step. By this point you already know nothing legitimate is failing, because you have been watching.
5. Tighten alignment last, if at all
aspf= and adkim= control whether subdomains count as a match (r, relaxed, the default) or whether the domain must match exactly (s, strict). Strict alignment is more secure and more brittle. Only move to it once everything else is stable, and only if your sending setup genuinely warrants it.
The tags worth knowing
| Tag | What it does |
|---|---|
p= | The policy: none, quarantine or reject |
rua= | Where daily aggregate reports are sent. Without this you are flying blind |
ruf= | Forensic reports on individual failures. Many receivers do not send these, and they can carry personal data |
pct= | Percentage of failing mail the policy applies to. Use it to ramp |
sp= | A separate policy for subdomains. Set this, or subdomains inherit p= |
aspf= / adkim= | Alignment mode, relaxed (r) or strict (s) |
One that is easy to miss: if you do not set sp=, your subdomains inherit the main policy. If you set p=reject without thinking about subdomains, a subdomain used by some internal system may start failing.
How long does this take?
For a business with one mail provider and two or three sending tools, four to six weeks end to end, most of which is waiting on reports rather than doing work. For a group with multiple domains and a long tail of senders, longer, and the inventory step is where the time goes.
The waiting is not padding. It is the part that stops your quotes disappearing.
Where does your domain stand today?
The free domain security checker tells you in about twenty seconds whether you have a DMARC record, what policy it is set to, and whether reports are being collected. It runs in your browser, needs no signup, and stores nothing.
If you would rather someone else carried the risk of the move to enforcement, that is precisely what our domain and email security engagement is, at a fixed fee, staged so nothing goes dark.