DMARC glossary
What does p=reject mean in a DMARC record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 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 | Required — there is no default policy value. |
| Where it goes | Immediately after v=DMARC1, e.g. v=DMARC1; p=reject; |
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, pct, 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.
Applies quarantine/reject to a percentage of failing mail during rollout. Retired in DMARCbis — use briefly if at all.
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.com
v=DMARC1; p=none;
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 |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
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
“Their responsive support, agent task lists, white-label reporting, and centralized dashboard make managing our customer domains, effortless.”
Bobby Ghoshal — CEO, dupe.com
Enforce it — don't just monitor it
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.
Free 15-day trial · No credit card · Your own domain free forever (NFR)