What Does p=reject Actually Mean (And When Should You Set It)?
p=reject is the strongest DMARC policy. Plain-English guide to what it instructs receivers to do, when to set it, and how to ramp safely with pct=.
TL;DR
p=reject is the strongest DMARC policy. It tells receiving mail servers to refuse any message that fails authentication – before it lands anywhere. Set it after 30 days of clean aggregate reports at p=quarantine, with every legitimate sender passing. Ramp via pct=10, pct=50, pct=100. Go too soon and you bounce real mail. Stay at p=none indefinitely and you have no protection whatsoever.
Every botched p=reject deployment follows roughly the same arc. The rollout goes well. The team is confident. Someone decides the ramp is for cautious people, skips the last few steps, publishes pct=100, and goes home. The next morning, finance calls.
It is always finance.
The sender nobody knew about – a payroll relay, a forgotten Mailchimp integration, an invoicing platform set up two years ago and stopped thinking about – bounces. Not quietly. Loudly. On payday. Or on the first day of a Black Friday campaign. Or the morning board papers were supposed to go out. The fix takes four hours. The explanation takes considerably longer.
Here is what p=reject actually does, and the exact steps that let you get there without becoming the cautionary tale someone else tells at a conference.
What p=reject tells receivers to do
Your DMARC record lives at _dmarc.yourdomain.co.za as a TXT record. A typical full record looks like this:
v=DMARC1; p=reject; rua=mailto:reports@example.co.za; pct=100;
When Gmail, Microsoft 365, Yahoo, or any receiving server gets a message claiming to be from your domain, it runs SPF and DKIM checks, then checks alignment with the From address. If neither SPF-aligned nor DKIM-aligned passes, it looks up your DMARC policy. At p=reject, the instruction is unambiguous: refuse the message at SMTP. The sender’s server gets a 550 5.7.1 rejection. The message bounces back. The recipient never sees it. The spam folder never sees it. Gone.
Direct spoofs of your domain stop working. Lookalike domains (yourdomian.co.za) and display-name attacks still get through – DMARC was never designed to stop those. But the cheapest spoof, where someone simply types your real domain into the From line, dies at the door.
A note on compliance: Gmail and Yahoo follow the spec exactly. Microsoft 365 does too, with one documented edge case – if the spoofed sender somehow appears on the recipient’s safe-senders list, M365 may quarantine rather than reject. Apple iCloud and most ISPs comply cleanly. “It bounces” is the right mental model.
p=quarantine versus p=reject
| Policy | // behaviour What receivers do | // outcome What the recipient experiences |
|---|---|---|
p=none |
Nothing. Reports only. | Message delivered as if no DMARC existed. |
p=quarantine |
Treat as suspicious. Usually junk folder. | Message lands in junk. User can still find it. |
p=reject |
Refuse at SMTP. NDR returned. | No message exists. Sender gets a bounce. |
The gap between quarantine and reject matters more than it looks. At p=quarantine, a recipient who finds a spoof in junk might still open it. At p=reject, there is nothing to find. The spoofer also gets a bounce notification confirming your domain is locked down, which tends to move them toward easier targets.
When you’re ready for p=reject
Three conditions, in order.
Every legitimate sender authenticates cleanly. Microsoft 365 with both selector1 and selector2 DKIM signing enabled in the Defender portal. Google Workspace with the google DKIM selector generated and – this is the one that catches people – actually switched on. Generating the keys and enabling signing are two separate actions in the Google Workspace Admin console, and the gap between them has stalled more deployments than anything else on this list. Every marketing and transactional platform – Mailchimp, HubSpot, Zendesk, your transactional mail relay – with its own SPF include and DKIM CNAME, each producing aligned pass results in aggregate reports. If you cannot name every sender and the selector it uses, you are not ready.
30+ days of clean RUA reports at p=quarantine; pct=100. Not 30 days at p=none. Quarantine is where surprises surface, because something is now actually being acted on. A monitoring-only policy does not reveal misaligned senders – it just reports on them, and the report arrives the day after the mail already landed. At p=quarantine; pct=100, real failures show up as user complaints. Resolve them. Run another full month with nothing new.
Subdomain handling decided. The sp= tag controls subdomain policy. Set sp=reject explicitly. A forgotten mail.yourdomain.co.za with no policy of its own is an open invitation to any spoofer who has already checked the parent domain and noticed the gap.
All three true? You are ready.
How pct= works during the rollout
pct= tells receivers to apply the policy to that fraction of failing messages and treat the rest as p=none. It is the most underused tag in DMARC, and the primary reason well-run deployments do not lose mail during transitions.
Standard ramp:
p=quarantine; pct=10– 10% of failing mail to junk, 90% delivered. One week.p=quarantine; pct=50– half to junk. One week.p=quarantine; pct=100– full quarantine. Two to four weeks of monitoring.p=reject; pct=100– full enforcement.
One thing worth knowing: at p=reject; pct=10, receivers are told to quarantine the other 90%, not deliver them. Most deployments skip the pct= ramp at the reject stage entirely and go straight to pct=100 once they are confident all senders are clean.
Read aggregate reports between every step. If the Sage payroll relay shows up as failing at pct=10, you fix it before it affects anyone. That is the entire point of the ramp – to surface exactly that problem at a scale where the answer is “interesting, let’s investigate” rather than “finance director calling.”
What happens if you go too soon
This is the section people skim because they feel confident. It is also the section they re-read later.
The Sage payroll failure. Finance sends payslips through an SMTP relay – a gateway nobody in IT knew about because nobody in IT set it up. At p=reject; pct=100, the gateway’s IP fails SPF, has no DKIM signing, fails DMARC. Five hundred bounce notifications land in the finance director’s inbox on payday. Recovery: roll back to p=quarantine (keep TTLs at 300 during deployment for fast propagation), add the gateway to SPF, re-test at pct=10, ramp again. Total disruption: four hours. Total awkwardness: considerably longer. We have had this call. It does not get easier to receive the second time.
The forgotten Mailchimp campaign. Marketing used Mailchimp 18 months ago for one campaign, then stopped. The SPF include was removed during a DNS cleanup because nobody had touched it in a year. Marketing resurrects the account for a Black Friday send without mentioning it to IT. At p=reject, every message bounces. Twelve thousand customers miss the campaign. The postmortem produces a new documentation requirement, a shared calendar invite titled “notify IT before touching DNS-dependent platforms,” and the kind of inter-departmental goodwill that takes about a quarter to rebuild.
Both recoverable. Both entirely avoidable with the ramp in place.
What happens if you never move past p=none
p=none tells receivers to deliver everything – including authentication failures – and send you a report about it. The report arrives 24 hours later, in XML format, confirming what already happened: the spoof landed, your customer clicked the fake invoice, the wire transfer went somewhere interesting. Then the aggregate report arrived.
Plenty of domains sit at p=none indefinitely. The deployment got stuck on a third-party vendor’s DKIM. Or IT ticked the box on an audit questionnaire and the project was never revisited. Or a previous failed attempt bounced legitimate mail and management said “leave it at none – safer.” It is not safer. It is exactly as protective as no DMARC at all.
Underwriters are now aware of this distinction. Renewal questionnaires ask what p= is set to, specifically. “Has DMARC: yes” stopped being a complete answer in 2025. At p=reject with managed reporting, you have turned a security control into a renewal-discount conversation. At p=none, you have a number in a DNS record that does nothing.
p=none is the start of a deployment. Two to four weeks at most. Anything longer is a stalled project with a false audit tick sitting next to it.
Where does that leave you?
At p=none for more than a month? Stalled. Pick it back up.
At p=quarantine; pct=100 with 30 clean days behind you? You are ready to move.
Not sure what state you are in? Do a DMARC lookup on your domain, read the p= tag, then check the DMARC service page for the full path forward.
Free 30-day RUA review
Before you flip to p=reject, we run a free 20-minute “are you ready?” review. Send us your most recent month of aggregate reports – or point your rua= at our endpoint for a month. We come back with a yes-or-no on the ramp, a list of any senders not yet authenticating cleanly, and the exact record change to publish.
Use the contact form or email directly. Bring your domain.
