DMARC Policy Guide: The Complete Journey from None to Quarantine to Reject

The DMARC policy tag (p=) tells receiving mail servers what to do with messages that fail DMARC authentication. The three values are p=none (monitor only), p=quarantine (route to spam), and p=reject (block entirely). This single tag is the enforcement mechanism that makes DMARC effective. Without it progressing beyond none, your domain has visibility into spoofing but no protection against it.

This guide covers the complete enforcement journey: when to use each policy, how long to stay at each stage, what data to collect before moving forward, and the common mistakes that cause organizations to roll back. Whether you are managing a single domain or hundreds across an MSP portfolio, the fundamentals of policy progression are the same.

Compliance is driving a lot of the DMARC adoption we see, says Vasile Diaconu, Operations Lead at DuoCircle. PCI DSS v4.0, Google’s sender requirements, Microsoft’s May 2025 enforcement — our support team fields questions about these mandates daily. The organizations that moved early are already at p=reject. The rest are scrambling.

Understanding DMARC Policy

Per RFC 7489, the DMARC policy applies to messages that fail BOTH SPF alignment and DKIM alignment. If either protocol passes and aligns with the From header domain, the message passes DMARC regardless of the policy setting.

The policy tag has three values:

Policy	Tag Value	Receiver Action	Use Case
None	p=none	Deliver normally, send reports	Initial monitoring and discovery
Quarantine	p=quarantine	Route to spam/junk folder	Gradual enforcement
Reject	p=reject	Block at SMTP level	Full protection

For a foundational overview of DMARC policies and how to choose, see our guide on DMARC policies explained: how to choose the right policy for your domain and what is a DMARC policy and how does it affect sending emails.

Phase 1: p=none - Monitoring and Discovery

What p=none Does

Publishing a DMARC record with p=none tells receiving servers: “Send me reports about messages from my domain, but do not take any action based on authentication results.” Messages are delivered normally whether they pass or fail DMARC.

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

This is a monitoring-only mode. Its purpose is discovery: finding out who sends email as your domain and whether their authentication is configured correctly.

When to Use p=none

Our guide on 4 situations when to use the DMARC p=none policy effectively identifies the core scenarios:

1. Initial DMARC deployment. Every organization should start here. You do not yet know what will break when you enforce.
2. Complex sending infrastructure. Organizations with many third-party senders need time to identify and authenticate each one.
3. Compliance requirements that mandate DMARC but not enforcement. Google’s bulk sender requirements, for example, require at least p=none.
4. After major infrastructure changes. If you migrated email platforms, added new sending services, or restructured domains, drop back to p=none temporarily.

How Long to Stay at p=none

Minimum 90 days. This is not arbitrary. You need to catch:

• Monthly senders (invoicing systems, monthly newsletters)
• Quarterly senders (quarterly reports, seasonal campaigns)
• Annual senders (renewal notices, annual surveys)
• Infrequent senders (password resets, onboarding sequences)

A full quarter of monitoring data gives reasonable confidence that you have identified most legitimate senders. For organizations with complex infrastructure, 6 months may be appropriate.

What to Do During the p=none Phase

1. Review aggregate reports regularly. DMARC Report parses your RUA reports automatically and identifies senders, pass rates, and alignment issues. See our complete guide to DMARC aggregate reports.
2. Classify every sender. Mark each source IP as authorized or unauthorized. Investigate unknowns.
3. Fix authentication for legitimate senders. Add missing SPF includes. Enable DKIM signing. Fix alignment issues.
4. Document your sending infrastructure. Maintain a list of every service authorized to send as your domain.

The Trap of Staying at p=none Too Long

Many organizations publish p=none to meet compliance requirements and never progress. This provides zero protection against spoofing. Attackers can still freely impersonate your domain. The reports tell you about it, but nothing stops it.

According to a 2024 Valimail report, only 28.5% of domains with a published DMARC record have reached p=reject. A significant portion of the remaining 71.5% are stuck at p=none, either because they are still monitoring or because they never intended to enforce.

Our guide on why a DMARC analyzer is essential before enforcing p=reject explains why analysis tools are critical for getting past the monitoring phase. See also why organizations deploy DMARC analyzers before enforcing policy.

Phase 2: p=quarantine - Gradual Enforcement

What p=quarantine Does

Setting p=quarantine tells receiving servers to treat failing messages with suspicion. In practice, this usually means routing them to the recipient’s spam or junk folder rather than the inbox. The messages are not blocked, but they are de-prioritized.

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

When to Move to p=quarantine

Our guide on 5 situations when your DMARC policy should use p=quarantine covers the decision criteria in detail. The short version: move to quarantine when:

• All known legitimate senders pass DMARC in your reports
• You have monitored for at least 90 days
• You have a plan for handling false positives
• You understand which messages will be affected

For a deeper look at how quarantine works against phishing specifically, see how does DMARC quarantine work against phishing attempts.

Using the pct Tag for Gradual Rollout

The pct tag lets you apply the policy to a percentage of failing messages:

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

This applies quarantine to 25% of failing messages while the remaining 75% are treated as p=none. Increase gradually:

1. pct=25 for 2-4 weeks
2. pct=50 for 2-4 weeks
3. pct=75 for 2-4 weeks
4. pct=100 (or remove the pct tag, which defaults to 100)

At each step, monitor your reports for any legitimate mail landing in spam. If problems appear, pause and fix them before increasing.

What Quarantine Looks Like to Recipients

When a message is quarantined:

• Gmail routes it to the Spam folder with a warning banner
• Outlook/Microsoft 365 routes it to Junk Email
• Yahoo routes it to the Spam folder
• Apple Mail marks it as junk

The recipient can still find and read the message, which provides a safety net. If a legitimate message is quarantined, the recipient can report it, giving you a signal that something needs fixing.

For platform-specific behavior, see our coverage of Microsoft’s DMARC policy handling defaults and why Gmail marks emails as spam under strict DMARC policy.

How Long to Stay at p=quarantine

Minimum 90 days at pct=100. This gives you a full quarter of enforcement data. Look for:

• Zero legitimate senders being quarantined
• Stable pass rates across all authorized senders
• No new legitimate senders appearing that you missed
• Comfortable level of spoofing being caught

Phase 3: p=reject - Full Protection

What p=reject Does

Setting p=reject tells receiving servers to reject messages that fail DMARC at the SMTP level. The sending server receives a 550 bounce response. The message is never delivered.

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

This is the maximum protection. Spoofed messages are blocked before they reach the recipient. Our guide on the DMARC reject policy: ultimate protection against phishing and spoofing covers the technical details and benefits.

When to Move to p=reject

Move to reject when:

• You have been at p=quarantine; pct=100 for at least 90 days
• Zero legitimate mail has been quarantined during that period
• All authorized senders consistently pass DMARC
• You have a process for authenticating new senders before they go live
• Your organization accepts the risk that undiscovered legitimate senders will be blocked

What Happens to Legitimate Mail That Fails

At p=reject, legitimate mail that fails DMARC is bounced. Common causes of legitimate failures at this stage:

• New third-party services added without updating SPF/DKIM
• Email forwarding that breaks SPF (the forwarding server’s IP is not in the original SPF record)
• Mailing list servers that modify the message body, breaking DKIM signatures
• Legacy systems that were not discovered during the monitoring phase

For guidance on preventing these issues, see our guide on how to reduce legitimate email blocking with strict DMARC enforcement.

The Transition from Quarantine to Reject

Our guide on switching from p=quarantine to p=reject covers the specific transition steps. You can use the pct tag here too, starting at pct=25 for reject while the remainder falls back to quarantine.

Subdomain Policies

The sp tag controls what policy applies to subdomains:

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

This applies p=reject to the parent domain but p=quarantine to subdomains. This is useful when subdomains have different sending patterns or are managed by different teams.

Our guide on the DMARC subdomain policy tag explained covers subdomain policy in detail. For broader multi-domain configurations, see how to implement DMARC for multiple domains and subdomains.

Enforcement Timelines

Realistic Timeline: 9-18 Months

Our DMARC enforcement timeline roadmap lays out a realistic schedule:

Phase	Duration	Policy
Preparation	1-2 weeks	No record yet
Monitoring	90-180 days	p=none
Gradual enforcement	90-120 days	p=quarantine (pct ramp)
Full enforcement	Ongoing	p=reject

Total: 9-18 months from first record to full reject. Smaller organizations with simple sending infrastructure can move faster. Large enterprises with dozens of sending services typically need the full 18 months.

DMARC Enforcement for Smaller Brands

Smaller organizations often face unique challenges: limited IT resources, fewer sending services but less visibility into what those services do, and tighter tolerance for delivery failures. Our guide on fixing DMARC enforcement for smaller and emerging brands addresses these constraints.

Monitoring and Maintenance After Enforcement

Reaching p=reject is not the end. Ongoing monitoring is essential:

Watch for New Senders

Every time you add a new marketing platform, CRM, ticketing system, or transactional email service, you must authenticate it before it starts sending. If it sends before authentication is configured, messages will be rejected.

Track Authentication Regressions

Third-party services change their infrastructure. IP ranges rotate. DKIM keys expire. SPF includes change. Any of these can cause previously passing senders to start failing. DMARC Report’s monitoring dashboards flag these regressions automatically.

Review Reports Regularly

Even at p=reject, continue reviewing aggregate reports. They show you what is being blocked, which helps you:

• Quantify the spoofing attempts against your domain
• Identify new legitimate senders that need authentication
• Detect configuration drift in existing senders

Our guide on DMARC enforcement and monitoring covers the ongoing maintenance process. See also receiving the maximum benefits from DMARC reporting and monitoring.

Common Policy Mistakes

Jumping straight to p=reject. This blocks legitimate email you did not know about. Always start at p=none.

Staying at p=none indefinitely. Monitoring without enforcement provides no protection. Set a deadline for moving to quarantine.

Ignoring the pct tag. Going from p=none to p=quarantine at 100% in one step is risky. Use pct to ramp gradually.

Not authenticating third-party senders before enforcement. Every service that sends email as your domain must pass SPF or DKIM with proper alignment.

Forgetting subdomain policies. If you set p=reject on the parent domain but do not address subdomains, attackers can spoof subdomains instead. Use the sp tag or publish separate subdomain DMARC records.

Rolling back to p=none after a problem. If legitimate mail is being blocked, identify and fix the specific sender rather than dropping the entire policy. Use the pct tag to reduce enforcement percentage while you troubleshoot.

For troubleshooting enforcement issues, see our guides on resolving the DMARC policy not enabled error and fixing the DMARC policy not enabled error.

Platform-Specific Policy Guidance

Gmail and Google Workspace

• Complete guide to setting DMARC policy for Gmail domains
• How to implement DMARC policy for Gmail and Google Workspace
• Best practices for DMARC enforcement on G Suite

For the full Google guide, see our DMARC for Gmail and Google Workspace hub.

Microsoft 365 / Office 365

• Impact of DMARC on email deliverability for Office 365 users
• Protecting your email infrastructure with DMARC for Office 365
• Troubleshoot email delivery failures after implementing DMARC in Office 365

For the full Microsoft guide, see our DMARC for Office 365 hub.

Tools for Policy Decisions

Use these tools to assess your domain’s current authentication status and enforcement readiness:

• DMARC checker - Validate your current DMARC record and policy
• SPF checker - Verify SPF configuration and lookup count
• DKIM lookup - Confirm DKIM public key is published

For the complete DMARC deployment process, see our DMARC setup complete guide. For understanding the complete reporting landscape, see our complete guide to DMARC aggregate reports.