DMARC Policy
The DMARC policy - the p= tag - tells receivers what to do with mail that fails DMARC: p=none (monitor only), p=quarantine (send to spam), or p=reject (block outright). Full protection against spoofing requires p=reject.
This guide is part of our complete guide to DMARC. Related: the DMARC record and how to set up DMARC.
Your DMARC policy — the p= tag in your DMARC record — tells receiving mail servers what to do with messages that fail DMARC authentication. There are three choices: p=none (monitor only, take no action), p=quarantine (send failing mail to spam), and p=reject (block failing mail outright). Only p=reject gives you full protection against spoofing of your domain.
Everyone with a DMARC record has a policy, but most domains sit at p=none, which does nothing to stop impersonation. The goal is to progress safely to p=reject. This guide explains each policy, why alignment quietly decides whether messages pass or fail, and how to reach enforcement without blocking your own legitimate email.
The three policies: none, quarantine, reject
The p= tag is the single most important part of your DMARC record. It instructs receivers what action to take when a message claims to be from your domain but fails DMARC.
| Policy | What receivers do | When to use |
|---|---|---|
p=none | Take no action — deliver as normal, but send you aggregate reports | The starting point. Use only while you gather data and confirm every legitimate sender passes. |
p=quarantine | Route failing mail to the spam/junk folder | The middle stage. Use once reports are clean, to soft-enforce before committing to a hard block. |
p=reject | Refuse failing mail at the server — it never reaches the inbox | The end goal. Use once you are confident all legitimate mail authenticates and aligns. Full spoofing protection. |
p=none is a monitoring mode, not protection. A domain stuck at p=none can still be spoofed freely — attackers can send mail as you and it lands in inboxes. Real anti-spoofing protection begins at p=quarantine and is complete at p=reject.
Alignment determines pass or fail
A DMARC “pass” is stricter than an SPF or DKIM pass on its own. For DMARC to pass, a message needs at least one of SPF or DKIM to both authenticate and align with the visible From: domain that recipients actually see.
- SPF alignment — the domain in the SMTP envelope (Return-Path) must match the visible
From:domain, and SPF must pass. - DKIM alignment — the domain in the DKIM signature (
d=) must match the visibleFrom:domain, and the signature must verify.
This is where SPF quietly breaks DMARC. An SPF record is limited to 10 DNS lookups. When your record exceeds that limit — easy to do once you add several providers via nested include: statements — SPF returns a PermError and stops evaluating. That silently kills SPF alignment. If DKIM alignment isn’t also in place, otherwise legitimate mail fails DMARC and gets quarantined or rejected the moment you move to enforcement.
This is why why SPF alignment matters so much before you tighten your policy. Check that your record is under the lookup limit and returns no PermError. AutoSPF keeps SPF valid by flattening your record automatically, so it stays under 10 lookups even as you add senders — protecting DMARC alignment as you move toward reject.
You can also control how strict alignment is with the aspf (SPF) and adkim (DKIM) tags. r (relaxed, the default) allows subdomains to align; s (strict) requires an exact match. Most domains should leave these relaxed. See the DMARC record for the full tag reference.
How to move from none to reject safely
Jumping straight to p=reject risks blocking real mail. Use a staged rollout instead:
- Start at
p=none. Publish a DMARC record withp=noneand a reporting address (rua=). This changes nothing about delivery but begins collecting aggregate reports. - Read your reports. Over two to four weeks, review the reports to see every source sending as your domain — your own marketing platform, CRM, helpdesk, invoicing tool, and any shadow senders.
- Fix failing legitimate senders. For each real sender that fails, add it to SPF or set up DKIM signing so it authenticates and aligns. Keep SPF under the 10-lookup limit while you do this.
- Move to
p=quarantinewithpct. Setp=quarantine; pct=25to enforce on a quarter of failing mail first, then raisepcttoward 100 as reports stay clean. This limits blast radius if you missed a sender. - Move to
p=reject. Once quarantine is atpct=100and reports show only expected failures (i.e., actual spoofing), switch top=rejectfor full protection.
For the record syntax and step-by-step publishing, see how to set up DMARC.
The sp tag (subdomain policy)
The sp= tag sets a separate policy for subdomains of your domain. If you omit it, subdomains inherit the main p= value. This matters because attackers often spoof subdomains (like mail.yourdomain.com) that you may not actively use. A common safe pattern is to publish sp=reject even while your top-level policy is still ramping up, so unused subdomains are locked down early. If you use subdomains for legitimate sending, treat them the same way — monitor, align, then enforce.
Frequently Asked Questions
What is a DMARC policy?
A DMARC policy is the p= tag in your domain’s DMARC DNS record. It tells receiving mail servers how to handle messages that claim to come from your domain but fail DMARC authentication. The three values are p=none (monitor only), p=quarantine (send to spam), and p=reject (block). It is the core instruction that turns DMARC into real protection.
What is the difference between p=none, p=quarantine and p=reject?
p=none takes no action on failing mail — it only sends you reports, so your domain can still be spoofed. p=quarantine routes failing messages to the spam folder, a soft enforcement stage. p=reject refuses failing mail at the server so it never reaches the inbox. Only p=quarantine and p=reject actually stop impersonation; p=reject is the full-protection goal.
Is p=reject safe to use?
Yes, once you have prepared for it. p=reject is safe after a staged rollout in which every legitimate sender authenticates and aligns, and your aggregate reports show only expected failures. The risk comes from jumping to reject too early and blocking real mail. Fix failing senders at p=none, ramp through p=quarantine with pct, then commit to reject.
Why is my DMARC policy not enabled?
Usually because it is set to p=none, which is monitoring only and enforces nothing — so your domain remains spoofable. It can also appear disabled if SPF exceeds the 10-lookup limit and returns PermError, silently breaking alignment so legitimate mail fails DMARC. Check your record with an SPF checker, fix alignment, then progress from none to reject.