DMARC glossary
What does p=reject mean in a DMARC record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed August 21, 2026
p=reject is the strongest DMARC policy: it tells receiving mail servers to refuse any message that fails authentication outright, so spoofed email never reaches the recipient at all. It's the end goal of a DMARC rollout, full protection against domain impersonation.
p=reject at a glance | |
|---|---|
| Tag | p (policy) |
| Valid values | none · quarantine · reject |
| Default | Recommended, not required. A record with no valid p tag falls back to p=none at best, so reject has to be set explicitly. |
| Where it goes | Conventionally right after the version tag (e.g. v=DMARC1; p=reject;), though only v has a fixed position |
How p=reject works
At p=reject, a message that fails DMARC is bounced at the door. The receiving server refuses it, and it never lands in an inbox or a spam folder. This is the only policy that actually stops domain impersonation rather than just flagging it.
It's the destination of every DMARC rollout. Once your reports show all legitimate senders passing at quarantine, moving to reject closes the door on spoofing entirely. Your domain can no longer be used to impersonate you in phishing or business-email-compromise attacks.
The risk isn't reject itself, it's getting there blind. Flip to reject before you've authorised every legitimate sender and you'll block your own mail. The art is reaching reject on evidence, not on a hunch.
Step 1
p=noneMonitor
Failing mail is still delivered: you only collect reports.
Step 2
p=quarantineContain
Failing mail is diverted to the spam or junk folder.
Step 3
p=rejectBlock
Failing mail is refused outright and never arrives.
Correct record vs common mistake
Correct
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.comFull enforcement with reporting still on: spoofed mail is refused, and you keep visibility into every source.
Common mistake
v=DMARC1; p=rejectJumping straight to reject with no prior monitoring risks blocking a forgotten legitimate sender (a SaaS tool, a marketing platform). Get to reject, but get there on evidence.
Generate your DMARC record
Build the exact TXT record to publish: pick a policy, add a reporting address, copy. Free, no signup.
Used to show the exact host name to publish. The record itself doesn't contain it.
Start at none to observe, then tighten once reports look clean.
Where daily XML summaries are sent. Comma-separate multiple addresses.
Advanced options (sp, alignment, ruf)
Subdomains inherit p unless you set this. Attackers love unused subdomains: reject is a strong choice once you're at enforcement.
Relaxed allows subdomain matches (mail.yourdomain.com signs for yourdomain.com). Strict requires an exact match. Most domains should stay relaxed.
Same idea for the SPF (Return-Path) domain.
Per-message failure samples. Rarely sent by large providers; contains message data.
Your DMARC record
Publish this as a TXT record in your DNS.
_dmarc.yourdomain.comv=DMARC1; p=none;Click the record to select all of it.
Record type: TXT · TTL: your provider’s default (e.g. 3600) is fine.
After you publish
- Add the TXT record at your DNS host and allow up to an hour for propagation.
- Verify it with the free DMARC checker.
- Watch your aggregate reports, fix SPF and DKIM for every legitimate sender, then step up to quarantine and reject.
Troubleshooting p=reject
| Issue | Likely cause | Fix |
|---|---|---|
| Legitimate mail suddenly bouncing | A forgotten sender (billing tool, marketing platform) was never aligned | Authorise it in SPF/DKIM; if needed, step back to quarantine while it propagates, then re-enforce |
| Forwarded mail failing DMARC | Forwarding rewrites the path and breaks SPF alignment | Rely on DKIM (it survives forwarding): make sure every source signs with an aligned DKIM key |
| New vendor's mail blocked at launch | Onboarding gap: the vendor went live before DNS was updated | Add new senders to SPF/DKIM before they start sending; make it a step in your vendor-onboarding checklist |
Why it matters for MSPs
Every client domain at p=reject is the outcome you're actually selling, provable protection against impersonation. The hard part isn't the value, it's getting every tenant there safely without breaking legitimate mail. Done by hand across dozens of domains, that's weeks of report-reading and DNS edits.
Trusted by MSPs
“We increased our meetings booked by 21% and slept better at night knowing our emails are now secured”
Marc-André Campagna , CEO, gaiiaRead the case study →
DMARC software that does the work
Reaching reject safely, on every client domain, is exactly what Palisade automates: it reads each domain's reports, aligns every legitimate sender, and advances the policy to reject for you: no manual report parsing, no broken mail.
1 domain free up to 1,000 emails/month
Questions readers ask
Frequently asked questions
Is p=reject safe to use?
Yes: once you've confirmed every legitimate sender passes DMARC. Reject only blocks mail that fails authentication, so with a clean setup your real email is unaffected and only spoofing is stopped.
What's the difference between p=reject and p=quarantine?
Reject refuses failing mail outright so it never arrives; quarantine delivers it to the spam folder. Reject is full protection; quarantine is containment.
Will p=reject block my legitimate email?
Only if a legitimate sender isn't aligned with SPF or DKIM. That's why you monitor first, to catch and authorise every real source before enforcing.
Do I still need rua= at p=reject?
Yes. Keep the reporting address so you keep seeing new sending sources and can catch problems even after reaching full enforcement.