DMARC Policy Explained: None vs Quarantine vs Reject

Introduction

Setting up DMARC is more than just adding a DNS record—the policy you choose determines how strictly your domain is protected. Choose too aggressively and legitimate emails might be blocked. Choose too conservatively and attackers can still spoof your domain.

This guide explains the three DMARC policies (p=none, p=quarantine, p=reject), when to use each one, and how to safely transition between them.

What is a DMARC Policy?

A DMARC policy tells email receivers what to do with emails that fail DMARC authentication. It's the enforcement mechanism that makes DMARC effective.

Think of it like security instructions for a building:

• p=none: "Record who enters but let everyone through" (monitoring)
• p=quarantine: "Escort unauthorized visitors to a waiting area" (send to spam)
• p=reject: "Turn unauthorized visitors away at the door" (block completely)

The policy appears in your DMARC DNS record:

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

The p= tag specifies your policy.

The Three DMARC Policies

Policy 1: p=none (Monitor Mode)

What it does:

• Allows all emails through, even if they fail DMARC
• Email providers send you reports about authentication results
• No impact on email delivery

DMARC record example:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

When to use it:

✅ Initial DMARC implementation

• First 2-4 weeks of DMARC setup
• Learning what legitimate sources send from your domain
• Identifying authentication issues

✅ After major infrastructure changes

• New email service provider
• New marketing automation platform
• After merger/acquisition

✅ Ongoing monitoring for complex environments

• Many third-party senders
• Multiple business units
• Frequent changes to email infrastructure

Benefits:

• Zero risk to email delivery
• Complete visibility into email ecosystem
• Identifies all senders using your domain
• Detects spoofing attempts (but doesn't block them)

Limitations:

• Provides no protection against spoofing
• Attackers can still impersonate your domain
• Doesn't improve deliverability

Real-world example:

A retail company implemented p=none and discovered:

• Their e-commerce platform wasn't DKIM-signed
• Marketing emails from Mailchimp had SPF issues
• An old support ticketing system was still sending
• Several phishing attempts were using their domain

They fixed the legitimate issues before moving to enforcement, preventing delivery problems.

Policy 2: p=quarantine (Soft Enforcement)

What it does:

• Sends failing emails to spam/junk folder
• Legitimate emails still delivered (but in spam)
• Reports continue to be sent

DMARC record example:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

When to use it:

✅ Transition phase between p=none and p=reject

• After fixing all known authentication issues
• Before full enforcement
• 2-4 weeks of testing

✅ Conservative protection for complex environments

• Many legitimate senders that occasionally have issues
• High volume of email with varying sources
• When p=reject feels too risky

✅ Subdomain protection with different risk profiles

• Main domain at p=reject
• Subdomains at p=quarantine

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

Benefits:

• Provides real protection without blocking
• Failed emails are still accessible (in spam)
• Less risk than immediate rejection
• Significantly reduces phishing success rate

Limitations:

• Doesn't completely block spoofed emails
• Some recipients check spam folders
• Not as strong as p=reject for brand protection

Important consideration:

Different email providers interpret "quarantine" differently:

• Gmail: Usually sends to spam folder
• Outlook: May send to junk or block entirely
• Others: Varies by provider

This means p=quarantine doesn't guarantee delivery to spam—some providers may still reject.

Policy 3: p=reject (Full Enforcement)

What it does:

• Blocks failing emails completely
• They never reach the recipient's inbox or spam folder
• Maximum protection for your domain

DMARC record example:

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

When to use it:

✅ After successful monitoring and quarantine phases

• All legitimate senders authenticated properly
• No authentication issues in reports for 2+ weeks
• Confident in your configuration

✅ Maximum brand protection

• High-profile brands targeted by phishing
• Financial institutions
• Healthcare organizations
• Government agencies

✅ Compliance requirements

• Industry regulations requiring strong authentication
• Security certifications
• Customer contracts mandating protection

Benefits:

• Complete protection from domain spoofing
• Strongest possible brand protection
• Prevents phishing emails from reaching targets
• Meets strictest compliance requirements
• Improves deliverability of legitimate email

Risks:

• Misconfigured legitimate email will be blocked
• No "undo" button—rejected emails are gone
• Requires ongoing monitoring to catch new issues

Critical requirements before using p=reject:

❗ All legitimate email sources must:

1. Have valid SPF or DKIM authentication
2. Pass DMARC alignment (From domain matches authenticated domain)
3. Be thoroughly tested
4. Be monitored continuously

Real-world example:

A financial services company moved to p=reject after 8 weeks of preparation:

• Week 1-4: p=none monitoring
• Week 5-8: p=quarantine testing
• Week 9+: p=reject enforcement

Result: Phishing attempts using their domain dropped to zero, and their legitimate email deliverability actually improved by 15% due to better sender reputation.

Policy Comparison Table

Feature	p=none	p=quarantine	p=reject
Protection Level	None	Moderate	Maximum
Failed Emails	Delivered	Spam folder	Blocked
Risk to Legitimate Email	None	Low	Medium
Brand Protection	None	Good	Excellent
Recommended Duration	2-4 weeks	2-4 weeks	Ongoing
Reports Sent	Yes	Yes	Yes
Compliance Level	Minimal	Good	Excellent
Phishing Prevention	0%	70-80%	95-99%

Advanced Policy Options

Percentage-Based Enforcement (pct)

Apply your policy to only a percentage of failing emails:

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

This means:

• 25% of failing emails are rejected
• 75% are handled as if policy was p=none

Use cases:

• Gradual rollout of p=quarantine or p=reject
• Testing impact before full enforcement
• Very large email volumes where caution is needed

Typical progression:

1. p=reject; pct=10 for 1 week (test with small subset)
2. p=reject; pct=25 for 1 week
3. p=reject; pct=50 for 1 week
4. p=reject; pct=100 (or just p=reject)

Subdomain Policy (sp)

Set different policies for your main domain vs subdomains:

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

• p=reject: Policy for yourdomain.com
• sp=quarantine: Policy for subdomain.yourdomain.com

Common patterns:

Pattern 1: Strict main domain, lenient subdomains

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

• Main domain fully protected
• Subdomains in monitoring mode

Pattern 2: Protect all, different levels

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

• Main domain: maximum protection
• Subdomains: moderate protection

Use case example:

yourdomain.com           → p=reject (customer-facing)
marketing.yourdomain.com → p=quarantine (many third parties)
test.yourdomain.com      → p=none (testing environment)

Each subdomain can have its own DMARC record, or inherit from the parent domain's sp policy.

When to Move Up: The Only Question That Matters

"Should I change from p=none to quarantine?" is the most common DMARC question there is, and it usually arrives with the wrong trigger attached — a warmup tool flagged the domain, an automated audit scored it red, someone read that p=none "does nothing".

None of those are reasons to raise your policy. A policy change is a decision about your own mail, and there is exactly one thing qualified to make it: your aggregate reports.

The calendar is a guide, not a criterion. Four weeks is typical, but a domain with three senders may be ready in two, and one with a decade of shadow IT may need three months. Move when the numbers below are true, not when the date arrives.

Phase 1 → 2: from p=none to p=quarantine

Policy: p=none. Nothing is blocked; you are collecting evidence.

What you are doing: publishing the record, collecting reports, and identifying every system that sends as your domain — including the ones nobody remembered: the CRM, the invoicing tool, the monitoring alerts, the ticketing system.

Do not move up until all of these are true:

• DMARC pass rate above 95%, and ideally above 98%
• Every legitimate sending source identified and authenticating
• Every failing source either fixed or confirmed as not yours
• No unknown sources left unexplained
• Three to four weeks of clean reports, not three clean days

Compliance rate = (messages passing DMARC / total messages) × 100

That last box matters more than it looks. A quiet week proves nothing if your monthly invoicing run has not happened yet. Make sure your reporting window has seen every cycle your business runs on — monthly billing, quarterly newsletters, the annual renewal notice.

Phase 2 → 3: from p=quarantine to p=reject

Policy: p=quarantine. Failing mail goes to spam instead of the inbox. It is reversible: recipients can still fish it out.

Do not move up until:

• DMARC pass rate above 98%
• No legitimate mail landing in spam because of DMARC
• No delivery complaints from users or customers
• Three to four weeks of stable numbers
• A written rollback plan — who changes the DNS record, and how fast

Use pct= to ease into it if the volume makes you nervous: p=quarantine; pct=25 applies the policy to a quarter of failing messages, and you raise it as confidence grows.

Phase 3: staying at p=reject

Policy: p=reject. Failing mail is refused outright — the protection you were aiming for.

Reaching it is not the end. New senders appear: a new marketing platform, a supplier that emails on your behalf, a department that signed up for something. Every one of them fails DMARC until it is authenticated, and at p=reject failing means never delivered.

Keep the reports under watch and alert on new failing sources. The organisations that get burned at p=reject are not the ones that moved too fast — they are the ones that stopped looking afterwards.

Common Mistakes to Avoid

Mistake 1: Jumping Directly to p=reject

❌ Wrong:

Day 1: Set p=reject without any monitoring

This will likely block legitimate emails you didn't know about.

✅ Right:

Week 1-4: p=none (monitor)
Week 5-8: p=quarantine (test)
Week 9+: p=reject (enforce)

Mistake 2: Staying on p=none Forever

Some organizations set p=none and never move forward. While this provides visibility, it offers zero protection.

Balance: Move to enforcement when you're confident, but don't rush.

Mistake 3: Not Monitoring After p=reject

Even with p=reject, you must continue monitoring reports:

• New services might be added
• Configuration changes can break authentication
• Attackers still attempt spoofing

Set up automated alerts for:

• Compliance drops below threshold
• New failing sources or IP addresses
• Volume spikes in email traffic
• DNS record changes (DMARC, SPF, DKIM)

Mistake 4: Forgetting About Subdomains

If you only set a DMARC record on your main domain, subdomains are unprotected unless you set the sp tag.

❌ Vulnerable:

yourdomain.com has DMARC
subdomain.yourdomain.com has no DMARC and no sp tag
→ Attackers can spoof subdomain.yourdomain.com

✅ Protected:

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

Choosing the Right Policy for Your Organization

Start with p=none if:

• You've never implemented DMARC
• You don't know all your email sources
• You're unsure about current authentication status
• You have a complex email infrastructure

Move to p=quarantine if:

• You've monitored for 2-4 weeks
• All legitimate sources are authenticated
• You want gradual protection
• You have a conservative risk tolerance

Advance to p=reject if:

• You've successfully completed quarantine phase
• DMARC pass rate is consistently >95%
• You need maximum protection
• Compliance requires it
• You're ready for ongoing monitoring

Monitoring Your Policy

Key Metrics to Track

DMARC Pass Rate:

Pass Rate = (Passing Emails / Total Emails) × 100

• Target: >95% before moving to quarantine
• Target: >98% before moving to reject

Compliance Rate:

Compliance Rate = (Compliant Volume / Total Volume) × 100

Source Authentication:

• Which sources pass consistently
• Which sources fail occasionally
• New sources appearing

Tools for Monitoring

Free checking:

• DMARC Checker - Verify current policy
• Domain Score - Overall email security
• Google Postmaster Tools - Gmail-specific data

Automated monitoring:

• DMARC report aggregation
• Real-time alerts
• Trend analysis
• Start free trial

The Bottom Line

DMARC policies are not one-size-fits-all, and the right policy depends on your organization's stage and needs:

p=none: Essential first step for visibility p=quarantine: Safe middle ground for testing p=reject: Maximum protection for ready organizations

Key takeaways:

1. Always start with p=none to understand your email ecosystem
2. Monitor for 2-4 weeks before advancing to the next policy
3. p=quarantine is a safe testing ground before full enforcement
4. p=reject provides maximum protection but requires preparation
5. Continue monitoring even after reaching p=reject
6. Don't forget subdomains - use the sp tag

The journey from p=none to p=reject typically takes 6-12 weeks, but the protection is worth the careful progression.

Next Steps

Ready to implement or upgrade your DMARC policy?

1. Check your current policy: DMARC Checker
2. Verify your authentication: Domain Score
3. Get policy recommendations: Start free trial for automated analysis

Need help deciding which policy is right for you? Our platform analyzes your DMARC reports and recommends the optimal policy based on your authentication success rate.

---

Related Articles:

• What is DMARC? A Simple Guide for Non-Technical People
• DMARC Implementation Timeline: From p=none to p=reject
• SPF, DKIM, and DMARC: The Complete Email Authentication Guide
• Compare DMARC monitoring tools: DMARC Examiner vs dmarcian