DMARC glossary
What is a DMARC policy?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed August 27, 2026
A DMARC policy is the instruction in the p tag of a DMARC record that tells receiving mail servers what to do with messages that fail authentication: none (deliver and report), quarantine (send to spam), or reject (refuse delivery). Receivers apply it only when neither SPF nor DKIM passes with an aligned domain.
p at a glance | |
|---|---|
| Tag | p (policy) |
| Valid values | none · quarantine · reject |
| Default | Recommended, not required. A record with no valid p tag is read as p=none if it carries a valid rua= address, and gets no DMARC processing at all if it has no rua either. |
| Where it goes | Conventionally right after the version tag (e.g. v=DMARC1; p=quarantine;), though only v has a fixed position |
How p works
The policy is the half of DMARC that actually does something. Authentication and alignment decide whether a message passes; the p tag decides what receivers do when it does not. none delivers the mail and only reports it, quarantine asks receivers to file it as spam, and reject asks them to refuse it during the SMTP conversation, so it never reaches a mailbox at all.
The three values are a ladder, not three equal choices. Domains start at p=none to collect aggregate reports, use those reports to fix every legitimate sender that fails alignment, then tighten to quarantine and finish at reject. Only reject stops spoofed mail outright, which is why an audit that ends at none has produced visibility, not protection. Subdomains can carry their own instruction through the sp and np tags; without those, the domain policy covers them.
RFC 9989, the current DMARC specification, makes p recommended rather than required, and the fallback is conditional: a record whose p value is missing or invalid is treated as p=none only when it names a valid rua reporting address, and is ignored entirely when it does not. The old pct percentage rollout tag was retired in the same revision; its staged-rollout role passes to the t=y testing flag.
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=quarantine; rua=mailto:dmarc@yourdomain.comA real policy plus a reporting address: failing mail goes to spam, and the reports show you what would have been affected before you tighten to reject.
Common mistake
v=DMARC1No p and no rua. Receivers apply no DMARC processing to this record at all, so it neither protects the domain nor reports on it.
Generate a DMARC record with the policy you chose
Pick none, quarantine or reject, add a reporting address, copy the exact TXT record to publish. 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.
Choosing a policy value
| Where you are | Policy to publish | Why |
|---|---|---|
| New to DMARC, senders unknown | p=none with rua= | Collects aggregate reports naming every source that sends as the domain, with no delivery risk while you read them. |
| Reports show legitimate senders aligned | p=quarantine | Failing mail goes to spam instead of the inbox, and a wrongly-failed message is still recoverable while you finish the cleanup. |
| A full sending cycle passes cleanly | p=reject | Spoofed mail is refused during delivery. This is the policy the bulk-sender rules point toward and the only one that stops impersonation. |
Why it matters for MSPs
A portfolio audit that only asks “is there a DMARC record?” misses the question that matters: what does its policy say? Client domains parked at p=none pass the checklist while staying fully spoofable, and a fleet of them means the audit line “DMARC deployed” is quietly untrue for every tenant.
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.comRead the case study →
DMARC software that does the work
The policy ladder is exactly the work Palisade's agent carries: it reads each domain's reports, identifies the senders that would break at a stricter policy, drafts the fixes, and proposes each step from none to reject for your team to approve before anything changes.
1 domain free up to 1,000 emails/month
Questions readers ask