DMARC Policy Configuration: A Technical Guide to None, Quarantine, and Reject Policies

Email authentication remains one of the most critical defenses against domain spoofing, phishing attacks, and email fraud. While SPF and DKIM provide foundational authentication mechanisms, DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties these protocols together and instructs receiving mail servers on how to handle authentication failures. At the heart of DMARC implementation lies the policy configuration—a decision that directly impacts your domain’s security posture and email deliverability. Understanding the nuances of dmarc policy options is essential for IT security teams tasked with protecting organizational domains while maintaining legitimate email flow.

DMARC builds upon SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) by requiring alignment between the domain in the From header and the domains authenticated by these protocols. This alignment requirement prevents attackers from using your domain in the visible From address while sending from unauthorized servers. The DMARC policy you configure determines what happens when this alignment check fails, making it a powerful tool for domain protection when implemented correctly.

DMARC Policy Options Explained

DMARC supports three distinct policy values, each represented by the p= tag in your DNS TXT record. These policies escalate in enforcement level, providing organizations with flexibility in their implementation approach.

The p=none policy represents the monitoring mode. A DNS record using this policy looks like:

v=DMARC1; p=none; rua=mailto:[email protected]

The p=quarantine policy instructs receiving servers to treat failing messages with suspicion. The DNS syntax appears as:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

The p=reject policy provides maximum enforcement, and the record syntax is:

v=DMARC1; p=reject; rua=mailto:[email protected]

Each policy fundamentally changes how receiving mail servers process messages that fail DMARC authentication checks, making policy selection a critical security and operational decision.

None vs Quarantine vs Reject: Technical Comparison

Understanding what each dmarc policy none quarantine reject option instructs receiving mail servers to do is essential for proper implementation.

With p=none, receiving mail servers perform DMARC checks but take no action on messages that fail authentication. These messages are delivered normally to recipient inboxes. The policy serves exclusively as a monitoring mechanism, generating aggregate reports (rua) that provide visibility into your email ecosystem. This allows domain owners to identify legitimate sending sources and detect unauthorized use of their domain without risking disruption to email delivery.

The p=quarantine policy instructs receiving servers to treat failing messages as suspicious. In practice, this typically means routing messages to the spam or junk folder rather than the primary inbox. The specific implementation varies by receiving server, as the DMARC specification intentionally leaves quarantine behavior somewhat flexible. Some servers may apply additional scrutiny or scoring penalties, while others route directly to spam folders. This policy provides protection while maintaining message accessibility should legitimate emails fail authentication.

With p=reject, receiving mail servers are instructed to refuse delivery entirely for messages that fail DMARC authentication. These messages are blocked at the SMTP transaction level, never reaching the recipient’s mailbox in any folder. This policy provides the strongest protection against domain spoofing but requires absolute confidence that all legitimate email sources are properly authenticated and aligned.

When to Use Each Policy

Selecting the appropriate DMARC policy depends on your organization’s current authentication maturity and risk tolerance.

Use p=none for:

• Initial DMARC deployment when you’re establishing baseline visibility
• Complex email environments where all sending sources haven’t been cataloged
• Organizations with numerous third-party senders requiring authentication configuration
• Monitoring periods to validate SPF and DKIM implementation completeness
• Domains with uncertain email infrastructure requiring investigation

Use p=quarantine for:

• Transition periods after analyzing aggregate reports from p=none
• Organizations wanting protection while maintaining recovery options for legitimate mail
• Environments where some authentication gaps remain but major sources are verified
• Testing enforcement impact with reduced risk of complete delivery failure

Use p=reject for:

• Mature DMARC implementations with comprehensive authentication coverage
• High-value domains frequently targeted by phishing campaigns
• Organizations requiring maximum protection against domain spoofing
• Domains where all legitimate sending sources have confirmed proper authentication

DMARC Policy Progression Strategy

Following dmarc policy recommendations, organizations should adopt a phased approach to policy enforcement rather than immediately implementing p=reject.

Phase 1: Deploy p=none with aggregate reporting (rua) configured. Maintain this policy for at least 2-4 weeks, though complex environments may require longer monitoring periods. During this phase, analyze aggregate reports to identify all legitimate sending sources and authentication failures.

Phase 2: Address authentication gaps discovered in reports. Configure SPF records for missing IP addresses, implement DKIM signing for all legitimate sources, and ensure proper alignment. Third-party services often require configuration changes to authenticate on your behalf, as detailed in resources like modern email delivery services.

Phase 3: Move to p=quarantine once aggregate reports show high authentication success rates. Monitor for any legitimate mail being quarantined and address remaining issues. This phase typically lasts 2-4 weeks but may extend longer for risk-averse organizations.

Phase 4: Escalate to p=reject when confident that all legitimate email authenticates properly. Continue monitoring aggregate reports indefinitely to catch configuration drift or new sending sources.

This progression strategy balances security objectives with operational continuity, preventing legitimate email disruption while building toward full enforcement.

Subdomain Policies

The sp= tag allows specification of a separate policy for subdomains, independent of the organizational domain policy. The syntax appears as:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]

Subdomains warrant separate consideration because they often have different email usage patterns. Marketing subdomains might send high volumes through third-party platforms, while internal subdomains might send no external email at all. Without an explicit sp= tag, subdomains inherit the parent domain’s policy.

Common configurations include setting sp=reject for non-sending subdomains while maintaining a more permissive policy on the organizational domain during transition periods. Alternatively, organizations might use sp=quarantine for subdomains with uncertain authentication status while enforcing p=reject on the primary domain.

Percentage Tags for Gradual Rollout

The pct= tag enables gradual policy enforcement by specifying the percentage of failing messages to which the policy applies. The syntax is:

v=DMARC1; p=reject; pct=25; rua=mailto:[email protected]

In this example, only 25% of messages failing DMARC checks receive the reject policy, while the remaining 75% are delivered normally. This allows organizations to test enforcement impact with reduced risk.

A common progression uses pct=10, then pct=25, pct=50, pct=75, and finally pct=100 (or omitting the tag entirely, as 100% is the default). Each percentage level should be maintained long enough to collect meaningful data from aggregate reports. This approach provides additional safety when moving from p=quarantine to p=reject, allowing detection of edge cases that might not appear in every reporting period.

DMARC Policy Best Practices

Implementing effective DMARC policy configuration requires attention to several technical and operational considerations:

• Maintain adequate monitoring periods: Resist pressure to accelerate through policy levels. A minimum of two weeks per phase allows capture of weekly email patterns and periodic sending sources.
• Implement aggregate report analysis: Raw XML reports are difficult to parse manually. Use DMARC analysis platforms or internal parsing tools to identify trends and authentication failures efficiently.
• Understand alignment modes: DMARC supports relaxed and strict alignment. Relaxed mode (default) allows subdomain alignment, while strict requires exact domain matching. Most organizations use relaxed alignment for operational flexibility.
• Configure failure reporting cautiously: The ruf= tag enables forensic reports containing message samples. These reports have privacy implications and generate significant volume. Many receiving servers don’t send them due to privacy concerns.
• Document your email infrastructure: Maintain comprehensive documentation of all legitimate sending sources, including corporate mail servers, marketing platforms, transactional email services, and any systems sending on your domain’s behalf.
• Avoid common mistakes: Don’t implement p=reject without monitoring data. Don’t ignore aggregate reports after deployment. Don’t forget about subdomains. Don’t overlook forwarding scenarios that may cause legitimate authentication failures.
• Plan for ongoing maintenance: DMARC isn’t a set-and-forget control. New services, infrastructure changes, and third-party platform updates require continuous monitoring and adjustment.

Conclusion

DMARC policy configuration represents a critical control point in email security architecture. The progression from p=none through p=quarantine to p=reject provides a structured path to domain protection that balances security objectives with operational requirements. By understanding the technical implications of each policy level, leveraging subdomain policies and percentage tags for controlled rollout, and following established best practices, email administrators can implement DMARC effectively.

At Email Delivery Pro, we recommend treating DMARC implementation as a journey rather than a destination. Begin with monitoring, progress based on data rather than timelines, and maintain vigilance even after reaching full enforcement. The investment in proper DMARC policy configuration pays dividends in reduced phishing risk, improved deliverability, and enhanced domain reputation. Start your DMARC journey today with p=none, and build toward the comprehensive protection that p=reject provides.