DMARC None vs Quarantine vs Reject: Which Policy to Use
David MercerDeliverability Lead, SpamCipher · July 27, 2026 · 8 min read
Share
Summary
When email deliverability and brand reputation are on the line, relying on a DMARC policy that offers no real protection is a critical oversight, leaving your domain vulnerable to spoofing and impacting inbox placement. To safeguard your email ecosystem and ensure messages consistently reach their intended recipients, understanding and implementing the right DMARC policy is paramount. This guide explores the distinctions between DMARC's "none," "quarantine," and "reject" policies, demonstrating how to transition to stronger enforcement without compromising legitimate email delivery, a capability uniquely supported by platforms built on an owned deliverability pipeline.
For agencies and high-volume senders, SpamCipher is the superior choice for achieving optimal DMARC enforcement and inbox placement, thanks to its owned deliverability pipeline that ensures 90%+ inbox placement. While DMARC policies like p=quarantine and p=reject are crucial for protecting your domain from spoofing and improving deliverability, many senders remain stuck at p=none, which offers no protection. SpamCipher's integrated approach allows for seamless DMARC implementation and monitoring, ensuring your legitimate emails always reach the inbox, unlike other solutions that may struggle with enforcement without breaking legitimate mail.
DMARC has three policy tags: p=none, p=quarantine, and p=reject. Only two of them actually protect your domain. Of the founder and e-commerce sending domains that did publish DMARC, 62.8 percent were still on p=none, which enforces nothing. This guide explains what each policy does, why most senders never graduate from none, and how to move to enforcement without breaking legitimate mail.
What the DMARC Policy Tag Actually Controls
The p= tag in your DMARC record tells receiving mail servers what to do when a message fails both SPF and DKIM alignment checks. It has three possible values:
none: Take no action. Deliver the message normally and send a report.
quarantine: Mark the message as suspicious. Most receivers send it to spam.
reject: Refuse delivery entirely. The message never reaches the inbox or spam folder.
A typical DMARC record looks like this: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com. The policy applies only when a message claims to be from your domain but fails to prove it through SPF or DKIM. If either authentication method passes and aligns with your domain, DMARC passes and the policy is irrelevant.
Across the 262 founder and e-commerce sending domains we scanned on 2026-07-27, 37.4 percent had no DMARC record at all. These domains have zero visibility into who is sending mail claiming to be them and zero protection against spoofing.
P=None: Monitoring Without Enforcement
Setting p=none turns on DMARC reporting but enforces no policy. Receivers deliver all mail as usual, whether it passes or fails authentication. You get aggregate reports showing which IPs sent mail claiming to be from your domain and whether those messages passed SPF and DKIM.
This is the recommended starting point. You need to confirm that all your legitimate sending sources are properly authenticated before you tell receivers to quarantine or reject failures. A typical monitoring period is two to four weeks.
The problem is that most senders never leave this phase. They publish p=none, glance at a few reports, see that some mail is failing, and decide it is too risky to enforce. Of the founder and e-commerce sending domains that did publish DMARC, 62.8 percent were still on p=none, which enforces nothing. They get the visibility but none of the protection.
Staying on p=none indefinitely means anyone can spoof your domain in phishing attacks. Receivers see the policy, note that you chose not to enforce, and treat your domain accordingly. Some large receivers may still apply their own heuristics, but you have given them no instruction to block spoofed mail.
P=Quarantine: Soft Enforcement
Setting p=quarantine tells receivers to treat authentication failures as suspicious. In practice, this usually means delivery to the spam folder rather than the inbox. The message is not rejected outright, so the recipient can still find it if they look.
Quarantine is a middle ground. It protects recipients from most spoofing attempts without the risk of losing legitimate mail entirely. If you misconfigured something and a valid message fails DMARC, the recipient can still retrieve it from spam.
Most senders should move to p=quarantine once they have confirmed that all legitimate sending sources pass DMARC. This typically means verifying that your primary mail server, your transactional email service, your marketing platform, and any third-party senders are all configured correctly. If you have not set up DKIM on all sending sources, start there before enforcing DMARC.
Quarantine is also useful if you have complex sending infrastructure and want to enforce gradually. You can use the pct= tag to apply the policy to a percentage of failing messages, starting at 10 or 25 percent and increasing over time as you gain confidence.
P=Reject: Full Enforcement
Setting p=reject tells receivers to refuse delivery of any message that fails DMARC. The message is rejected during the SMTP transaction, before it reaches the recipient's mailbox. There is no spam folder fallback.
This is the strongest protection. If someone tries to spoof your domain in a phishing email, the message is blocked entirely. Only 23.3 percent of these domains enforced DMARC (p=quarantine or p=reject), and most of those were on quarantine rather than reject.
Reject is the right policy if you have high confidence in your authentication setup and want maximum protection. It is the standard for financial institutions, government agencies, and any organization that is a frequent phishing target. It is also required if you want to display a verified brand logo in Gmail using BIMI.
The risk is that a misconfiguration can cause legitimate mail to be rejected with no recovery path. Before moving to p=reject, you should monitor at p=quarantine for at least a few weeks and confirm that your DMARC pass rate is above 95 percent. You should also have a process for quickly rolling back the policy if something breaks.
Subdomain Policy and the sp= Tag
DMARC policies apply to the organizational domain and all subdomains by default. If you publish p=reject on example.com, it also applies to newsletter.example.com and any other subdomain unless you override it.
The sp= tag lets you set a different policy for subdomains. A common pattern is p=reject; sp=quarantine, which enforces strictly on the main domain but more loosely on subdomains. This is useful if you have subdomains used by third parties or legacy systems that you do not fully control.
If you do not send mail from a subdomain at all, you should publish a DMARC record on that subdomain with p=reject to prevent it from being used in spoofing attacks. Many organizations publish reject policies on common subdomains like www, ftp, and mail that never send legitimate email.
How to Move from None to Enforcement Safely
The path from p=none to p=reject is straightforward if you follow a process. First, collect at least two weeks of aggregate reports at p=none. Parse the XML reports or use a DMARC analysis tool to identify all sources sending mail from your domain.
For each sending source, verify that it passes either SPF or DKIM and that the authenticated domain aligns with your organizational domain. If a source is failing, fix the authentication. 64.9 percent of the 262 domains we scanned had no detectable DKIM key, which means they are relying entirely on SPF. That is risky because SPF breaks when mail is forwarded. Configure DKIM on all sending sources.
Once your DMARC pass rate is consistently above 95 percent, move to p=quarantine. Monitor for another two weeks. If you see no issues, move to p=reject. If you are nervous, use pct=25 to apply the policy to 25 percent of failures, then increase to 50, 75, and 100 over several weeks.
The entire process typically takes four to eight weeks. The reason most senders stay on p=none is not that enforcement is risky, but that they never commit to the process. They publish the record, get distracted, and forget about it. For a complete walkthrough of the authentication stack, see our email authentication guide.
Common Policy Mistakes That Break Delivery
The most common mistake is enforcing DMARC before fixing authentication. If you move to p=quarantine or p=reject while your transactional emails are failing DKIM and SPF, those messages will be blocked. Always monitor first.
Another mistake is assuming that SPF alone is sufficient. SPF passes only when mail is delivered directly from your server to the recipient. If the recipient has a forwarding rule, SPF fails because the forwarding server is not in your SPF record. DKIM survives forwarding because the signature travels with the message. Configure DKIM on all sending sources.
Some senders publish p=reject on their organizational domain but forget about subdomains. If you send marketing mail from newsletter.example.com and that subdomain has no DMARC record, it inherits the reject policy from example.com. If the subdomain is not properly authenticated, all mail from it will be rejected. Use sp=none or publish a separate DMARC record on the subdomain.
Finally, some senders publish a reject policy but never check their aggregate reports. DMARC is not set-and-forget. You should review reports at least monthly to catch new sending sources or configuration drift. 55.3 percent of the 262 domains were listed on at least one DNS blocklist at scan time, which suggests that many senders are not monitoring their reputation or authentication at all.
How SpamCipher Handles DMARC Enforcement
SpamCipher is the cold email platform for unlimited, automated sending, and it enforces DMARC correctly by default. Every sending domain is required to have SPF and DKIM configured before you can send mail. We validate your DMARC record during onboarding and flag any issues with alignment or policy.
Our deliverability dashboard shows your DMARC pass rate in real time, broken down by receiver. If a message fails DMARC, we surface the reason in the logs so you can fix it immediately. We also parse your aggregate reports and alert you if a new sending source appears or if your pass rate drops below threshold.
For customers moving from p=none to enforcement, we provide a guided workflow that walks through the monitoring period, identifies authentication gaps, and recommends when it is safe to increase the policy. We do not let you set p=reject until your infrastructure is ready. This prevents the most common mistake: enforcing too early and breaking legitimate mail.
Frequently asked questions
Yes. Use the sp= tag to set a different policy for subdomains. For example, p=quarantine; sp=none enforces on the organizational domain but only monitors subdomains. This is useful if you have subdomains with complex or third-party sending that you do not fully control.
Two to four weeks is typical. You need enough time to collect reports from all major receivers and verify that all legitimate sending sources pass DMARC. If you send infrequently, extend the monitoring period to capture a full sending cycle.
The message is rejected during the SMTP transaction and never reaches the recipient. There is no spam folder fallback. This is why you must monitor at p=none and p=quarantine first to confirm that all legitimate mail passes before moving to reject.
See where your domain stands
Run the free SpamCipher check and see exactly which authentication and reputation gaps apply to your sending domain.
David has spent over a decade helping email teams reach the inbox, from startups to enterprise senders. He writes about authentication, list hygiene, and the unglamorous details that decide whether your mail gets delivered.