DMARC glossary

What does p=reject mean in a DMARC record?

Samuel Chenard

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
Tagp (policy)
Valid valuesnone · quarantine · reject
DefaultRequired — there is no default policy value.
Where it goesImmediately 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=none

Monitor

Failing mail is still delivered — you only collect reports.

Step 2

p=quarantine

Contain

Failing mail is diverted to the spam or junk folder.

You are here

Step 3

p=reject

Block

Failing mail is refused outright and never arrives.

Monitoring onlyFull protection
A DMARC rollout moves left to right — from monitoring only, to containing spoofed mail, to blocking it outright.

Correct record vs common mistake

Correct

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

Full enforcement with reporting still on — spoofed mail is refused, and you keep visibility into every source.

Common mistake

v=DMARC1; p=reject

Jumping 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.

Host / Name
_dmarc.yourdomain.com
Value (TXT)
v=DMARC1; p=none;

Click the record to select all of it.

Record type: TXT · TTL: your provider’s default (e.g. 3600) is fine.

No rua address set — you'll get no aggregate reports, which means no visibility into who is sending as your domain. Add one before publishing.
p=none is monitoring mode: receivers report but deliver everything, including spoofed mail. It's the right starting point — plan to move to quarantine, then reject, once your reports show all legitimate senders passing.

After you publish

  1. Add the TXT record at your DNS host and allow up to an hour for propagation.
  2. Verify it with the free DMARC checker.
  3. Watch your aggregate reports, fix SPF and DKIM for every legitimate sender, then step up to quarantine and reject.

Troubleshooting p=reject

IssueLikely causeFix
Legitimate mail suddenly bouncingA forgotten sender (billing tool, marketing platform) was never alignedAuthorise it in SPF/DKIM; if needed, step back to quarantine while it propagates, then re-enforce
Forwarded mail failing DMARCForwarding rewrites the path and breaks SPF alignmentRely on DKIM (it survives forwarding) — make sure every source signs with an aligned DKIM key
New vendor's mail blocked at launchOnboarding gap — the vendor went live before DNS was updatedAdd 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 absolutely love it. We are actively selling it and growing the usage.
Ravi RamharakRavi Ramharak Co-Founder, MSP Corp
Partner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner LogoPartner Logo

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.

Get startedBook a demo

1 domain free up to 1,000 emails/month

Questions readers ask

Frequently asked questions

Related terms

What is DMARC? Email authentication explained