Contents
DMARC enforcement policies determine what receiving mail servers do with messages failing DMARC authentication. The p=quarantine policy instructs receivers to accept messages but route them to spam folder providing safety net while active enforcement begins. The p=reject policy instructs receivers to reject failing messages at SMTP level providing maximum strictness without safety net. The 2026 enforcement landscape has shifted substantially: Google Postmaster Tools v2 includes DMARC enforcement level in domain compliance scoring with substantial preference for p=reject; Microsoft began strict enforcement May 2026 requiring at least p=quarantine for bulk senders; PCI DSS v4.0 DMARC requirements now active in 2026 affecting credit card handling organisations. The operator decision between quarantine and reject is no longer optional security choice; it has become operational and compliance requirement.
This comparison covers the practical DMARC enforcement decision in 2026: the RFC 7489 specifications of both policies, quarantine's spam folder routing versus reject's SMTP-level rejection, the 2026 enforcement landscape including Google's reputation scoring favouring p=reject, Microsoft's May 2026 enforcement, PCI DSS v4.0 compliance requirements, the recommended deployment progression from p=none through p=quarantine to p=reject, the pct tag enabling graduated enforcement during transitions, receiver behaviour differences with practical implications, ARC authentication for forwarded messages, and the decision framework for operators implementing DMARC enforcement.
Two enforcement policies
Both enforce. Different consequences. Substantially different operator commitments.
DMARC's three policy modes (none, quarantine, reject) provide graduated enforcement options matching different deployment stages and operational maturity levels. The choice between quarantine and reject is the substantive enforcement decision; both represent active policy with consequences for failing messages, while p=none provides monitoring without enforcement.
p=quarantine: messages failing DMARC authentication and alignment should be accepted by receivers but marked as suspicious; typical implementation routes them to spam or junk folder. The policy provides active enforcement with safety net: legitimate messages affected by configuration problems land in spam where recipients can rescue them rather than being lost entirely.
p=reject: messages failing DMARC authentication and alignment should be rejected by receivers; typical implementation returns SMTP 5xx hard bounce. The policy provides maximum strictness without safety net: legitimate messages with authentication problems get bounced; the sender receives bounce notification but recipients never see the message.
The choice between policies trades multiple dimensions:
Security strength. Reject provides stronger spoofing protection through definitive rejection; quarantine provides protection through spam routing but malicious messages reach spam folder where recipients might still see them.
Safety net. Quarantine preserves messages affected by configuration problems in spam folder; reject eliminates them entirely. Configuration drift produces worse consequences with reject than quarantine.
Operator commitment. Reject requires confident understanding of complete sending infrastructure; misconfigured legitimate senders get rejected. Quarantine tolerates some configuration imperfection through spam folder fallback.
Provider treatment. Major mailbox providers favour p=reject in 2026 reputation scoring; reject domains receive better treatment than quarantine domains in inbox placement decisions.
Compliance posture. PCI DSS v4.0 and similar frameworks recommend p=reject as appropriate security posture; quarantine meets minimum requirements but reject represents best practice.
Deployment timing. Quarantine appropriate during deployment progression; reject appropriate after mature deployment validates all legitimate senders authenticate properly.
Quarantine policy specification
The p=quarantine policy has specific characteristics defined by RFC 7489.
RFC 7489 specification. The policy instructs receivers that messages failing DMARC authentication should be treated as suspicious but accepted; receivers should mark the messages with reduced trust or route them to spam folder. The specific implementation is receiver discretion within the general "treat as suspicious" guidance.
DMARC record example with quarantine:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1; aspf=r; adkim=r
Typical receiver implementations. Major receivers implement quarantine differently:
- Gmail. Routes to spam folder; tracks reputation impact for future delivery decisions; processes DMARC reports for the domain.
- Microsoft 365. Routes to junk folder; affects SNDS reputation scoring; may quarantine in different folder structures depending on tenant configuration.
- Yahoo. Routes to spam folder; affects sender reputation; standard behaviour matching Gmail approach.
- Apple iCloud. Routes to junk folder; integrates with Apple's spam protection systems.
- Corporate Microsoft Exchange. Behaviour depends on tenant policy configuration; may route to junk, hold for admin review, or apply other handling.
Quarantine policy advantages.
- Safety net for configuration errors. Authentication problems do not eliminate messages entirely; recipients can find them in spam folder.
- Tolerance for legacy senders. Old systems with imperfect authentication still get messages through (in spam folder) during transition periods.
- Recovery from forwarding issues. Forwarded messages with broken SPF (without SRS rewriting) land in spam folder rather than disappearing entirely.
- Graduated enforcement appropriate. Quarantine represents middle ground between monitoring-only and strict rejection; suitable intermediate state during deployment.
Quarantine policy disadvantages.
- Lower compliance scoring. Google Postmaster Tools v2 scores quarantine domains lower than reject; affects inbox placement for properly authenticated mail from same domain.
- Phishing messages still reach spam folder. Malicious messages spoofing the domain land in spam folder where some recipients might still open them.
- Mixed signal to receivers. The quarantine policy communicates uncertainty; receivers may apply variable interpretation.
- Recipient confusion. Users finding important messages in spam folder may develop habit of checking spam routinely, increasing chance of falling for actual phishing.
Reject policy specification
The p=reject policy has different characteristics matching its maximum strictness approach.
RFC 7489 specification. The policy instructs receivers that messages failing DMARC authentication should be rejected; receivers should refuse delivery of failing messages. The standard expectation is SMTP-level rejection through 5xx response codes during the SMTP transaction.
DMARC record example with reject:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1; aspf=r; adkim=r; sp=reject
Typical receiver implementations. Major receivers implement reject more consistently than quarantine:
- Gmail. Rejects with SMTP 550 during transaction; sender's mail system receives bounce notification; reputation scoring credits the strict policy.
- Microsoft 365. Rejects with SMTP 550; SNDS reputation scoring favours reject policies; May 2026 enforcement made this default for bulk senders.
- Yahoo. Rejects with SMTP 5xx codes; aligns with Google approach since 2024 joint requirements.
- Apple iCloud. Rejects following standard implementation.
- Corporate Microsoft Exchange. Tenant-dependent; reject policy typically enforced unless administrative override.
Reject policy advantages.
- Maximum compliance scoring. Google Postmaster Tools v2 grants highest compliance scores to p=reject domains; inbox placement preferential.
- Definitive phishing protection. Spoofed messages get rejected entirely; never reach recipient's spam folder.
- Clear bounce notifications. Sender systems receive explicit bounce notifications enabling rapid identification and resolution of authentication problems.
- Compliance posture. PCI DSS v4.0 and similar frameworks recommend p=reject; demonstrates security maturity.
- Reduced recipient confusion. No habit of checking spam folder for missing messages.
Reject policy disadvantages.
- No safety net. Authentication configuration errors produce delivery failures rather than spam folder routing; legitimate messages can be entirely lost.
- Forwarding sensitivity. Forwarded messages without proper SRS rewriting get rejected; mailing list distributions affected; user forwarding rules can break.
- Operational pressure. Any new sending service must authenticate properly before sending; configuration drift produces immediate delivery problems.
- Deployment caution required. Premature progression to reject before identifying all legitimate senders causes legitimate mail rejection.
2026 enforcement landscape
The 2026 DMARC enforcement landscape has evolved substantially from earlier years.
Provider enforcement timeline:
| Provider | Enforcement milestone | Date | Requirement |
|---|---|---|---|
| Google (Gmail) | Bulk sender requirements (5000+ daily to Gmail) | February 2024 | Active DMARC policy required |
| Yahoo | Bulk sender requirements (5000+ daily to Yahoo) | February 2024 | Active DMARC policy required |
| Microsoft (Outlook.com/M365) | Initial enforcement signals | May 2025 | 550 rejections for high-volume DMARC failures |
| Google (Gmail) | Stricter enforcement | November 2025 | Increased rejection rates for failing bulk mail |
| Microsoft (Outlook.com/M365) | Full bulk sender enforcement | May 2026 | At least p=quarantine required for bulk senders |
| PCI DSS v4.0 | DMARC compliance active | 2026 | Active enforcement (recommended p=reject) |
| Google Postmaster Tools v2 | Domain compliance scoring | 2026 | p=reject scores highest; affects inbox placement |
Practical consequences of 2026 landscape:
Bulk senders without DMARC enforcement face delivery problems. Sending 5000+ daily messages to any major provider without p=quarantine or p=reject produces filtering or rejection.
Compliance scoring affects inbox placement. Even properly authenticated messages from p=none domains land in spam more often than messages from p=reject domains; the reputation scoring extends beyond pure DMARC enforcement.
Regulatory frameworks now require DMARC. PCI DSS v4.0 makes DMARC compliance mandatory for credit card handling; HIPAA-adjacent frameworks recommend DMARC; FINRA cybersecurity guidance includes DMARC; many sectors increasingly mandate DMARC enforcement.
Cybersecurity insurance frequently requires DMARC. Insurance providers increasingly include DMARC implementation in cybersecurity coverage requirements; non-implementation may affect coverage or premiums.
Phishing protection mature. DMARC enforcement combined with BIMI (Brand Indicators for Message Identification) and verified mark certificates provides comprehensive brand protection in email; the protection requires p=reject as foundation.
Google and Yahoo's bulk sender requirements activated February 2024 apply to senders sending more than 5,000 messages per day to Gmail or Yahoo recipients respectively; Microsoft's May 2026 enforcement applies similar thresholds. Many operators incorrectly believe these requirements only affect dedicated bulk email services or ESPs; the 5,000-message threshold actually applies to all senders crossing that volume regardless of business type. Common scenarios crossing the threshold without realising: SaaS application sending 7,000 transactional emails daily (welcome, password reset, notifications, alerts combined); e-commerce platform during peak season sending order confirmations to thousands of buyers; B2B company sending bulk newsletters or campaigns. Once over 5,000 daily to a specific provider, the bulk sender requirements apply: DMARC enforcement policy (p=quarantine minimum); one-click unsubscribe for marketing; complaint rate under 0.3%; proper SPF, DKIM authentication. Operators tracking volume per provider sometimes find they cross thresholds during specific campaigns or seasons even if normal volume is below. The compliance approach: implement DMARC enforcement proactively regardless of current volume; the requirements will likely tighten over time and the implementation work is the same whether done proactively or reactively under enforcement pressure.
Deployment progression
The recommended DMARC deployment progression follows standard sequence with timing variations based on operator profile.
Standard progression:
| Phase | Policy | Duration | Purpose |
|---|---|---|---|
| 1 | p=none; rua=... | 4-12 weeks | Collect aggregate reports; identify all sending sources; address authentication failures |
| 2 | p=quarantine; pct=25 | 2-4 weeks | Quarantine 25% of failing messages; observe impact |
| 3 | p=quarantine; pct=50 | 2 weeks | Quarantine 50% of failing messages |
| 4 | p=quarantine; pct=100 | 2-4 weeks | Quarantine all failing messages |
| 5 | p=reject; pct=25 | 2 weeks | Reject 25% of failing messages |
| 6 | p=reject; pct=50 | 2 weeks | Reject 50% of failing messages |
| 7 | p=reject; pct=100 | Ongoing | Full enforcement; reject all failing messages |
Progression considerations:
Minimum p=none monitoring duration. 4 weeks minimum; 12 weeks recommended for complex sending infrastructure with many third-party services. The monitoring catches monthly senders (invoicing systems, newsletters); quarterly senders need full quarter to identify.
Major infrastructure changes reset progression. After migrations to new email platforms, addition of new sending services, or domain restructuring, drop back to p=none temporarily to monitor new configuration before progressing.
Compliance-driven timing. Operators facing compliance deadlines (PCI DSS v4.0, contractual requirements) may need accelerated progression; accept higher risk in exchange for meeting deadlines.
Parked domain shortcut. Domains that never send mail can skip directly to p=reject without progression; the strict policy on parked domains immediately blocks spoofing attempts.
Subdomain policy. Include sp=reject in root DMARC record from beginning of enforcement; subdomains without their own DMARC record inherit the strict subdomain policy; prevents subdomain spoofing.
Authentication issues must be resolved. Progression should not advance with unresolved authentication failures in aggregate reports; resolve issues before progressing.
Accelerated progression example (compressed timeline):
| Phase | Policy | Duration |
|---|---|---|
| 1 | p=none | 4 weeks |
| 2 | p=quarantine; pct=100 | 2 weeks |
| 3 | p=reject; pct=100 | Ongoing |
Compressed timeline appropriate when: complete sending infrastructure understanding; all senders properly authenticated; confidence high regarding configuration completeness; deadline pressure justifies acceptance of higher risk during transitions.
The pct tag for graduated enforcement
The pct tag enables graduated enforcement during policy transitions.
pct tag specification:
- Value range. 0-100; default is 100 if not specified.
- Meaning. Percentage of failing messages subject to enforcement policy; remaining messages treated as if p=none.
- Random selection. Receivers should randomly select messages according to percentage; not first-N or pattern-based.
- Applies to non-none policies only. The pct tag has no effect when policy is p=none.
Practical pct usage patterns:
Cautious progression. Start at pct=10 or pct=25 when first entering enforcement; increase gradually as authentication confidence grows.
Compliance milestone. Use pct=50 as middle ground meeting some compliance requirements while limiting impact during continued verification.
Long-term partial enforcement. Some operators maintain p=reject pct=50 indefinitely as compromise between full enforcement and partial safety net; the configuration is less common but valid.
Testing infrastructure changes. When making changes to sending infrastructure, temporarily reduce pct during transition period; revert to pct=100 after change validated.
Example DMARC records using pct:
# Cautious quarantine start v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com # Quarantine majority v=DMARC1; p=quarantine; pct=75; rua=mailto:dmarc@example.com # Cautious reject start v=DMARC1; p=reject; pct=25; rua=mailto:dmarc@example.com # Full reject enforcement v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com; sp=reject
Receiver behaviour comparison
Detailed receiver behaviour comparison between quarantine and reject policies:
| Scenario | Quarantine behaviour | Reject behaviour |
|---|---|---|
| Legitimate message with proper authentication | Inbox delivery normal | Inbox delivery normal |
| Spoofed message clearly fraudulent | Spam folder; not visible by default | SMTP 5xx reject; never delivered |
| Legitimate message with broken SPF (forwarding) | Spam folder; recipient can rescue | SMTP 5xx reject; bounced to sender |
| Legitimate message with DKIM broken (mailing list) | Spam folder if SPF also broken; otherwise inbox | Reject if both broken; inbox if either passes |
| New sender forgot to add to SPF | Spam folder; visible to recipient | SMTP reject; immediate bounce notification |
| Configuration drift during DKIM rotation | Spam folder; rescued when noticed | SMTP reject; configuration error obvious |
| Phishing attempt against domain | Spam folder; some users may rescue | SMTP reject; recipient never sees |
| Marketing campaign list issue | Spam folder; engagement signals damaged | SMTP reject; campaign fails to deliver |
The behaviour pattern observations:
Quarantine preserves message availability. All scenarios with quarantine produce messages somewhere (inbox or spam) where recipient could find them. The safety net mechanism.
Reject eliminates delivery for failing scenarios. Failing messages bounce entirely; recipient never sees them. Strong protection but eliminates recovery path.
Authentication problems produce different operational signals. Quarantine spam folder routing is silent (no bounce); reject produces clear bounce notifications enabling rapid problem identification.
Phishing protection differs in degree. Quarantine reduces phishing impact through spam routing; reject eliminates phishing delivery entirely.
Operational considerations
Operational considerations differ between quarantine and reject policies.
ARC authentication for forwarded messages:
- ARC (Authenticated Received Chain). RFC 8617 specification enabling intermediaries (forwarders, mailing lists) to vouch for original authentication status.
- Mailing list compatibility. Mailing lists that implement ARC preserve original DMARC authentication status across distribution; messages survive p=reject through mailing lists implementing ARC.
- Forwarder compatibility. Mail forwarders implementing ARC can vouch for original authentication; reduces p=reject impact on legitimate forwarding.
- 2026 adoption. Major mailing list software (Mailman, Discourse) and major forwarders (Microsoft 365, Google Workspace) implement ARC; the protection extends widely.
SRS (Sender Rewriting Scheme):
- SPF-specific solution. SRS rewrites MAIL FROM to forwarding server's domain preserving SPF authentication for forwarded mail.
- Adoption incomplete. SRS adoption varies; many forwarders do not implement SRS leaving SPF broken on forwarded mail.
- DKIM more reliable. DKIM survives forwarding without rewriting; the 78% of DMARC passes via DKIM alignment statistic reflects DKIM's forwarding resilience.
Subdomain policy (sp tag):
- sp tag specification. Sets policy for subdomains without their own DMARC record; defaults to p value if not specified.
- Best practice sp=reject. Always include sp=reject in root DMARC record; prevents subdomain spoofing for subdomains you haven't configured.
- Subdomain delegation. Subdomains with their own DMARC record override the parent's sp value.
Aggregate reporting (rua tag):
- Always include rua. Aggregate reports identify authentication issues; essential for ongoing operations.
- Report aggregation tools. Specialised services (dmarcian, Valimail, DMARC Report, PowerDMARC) parse XML reports into actionable insights.
- Self-hosted parsing. Open-source tools (parsedmarc, dmarc-analyzer) parse reports into databases for self-hosted analysis.
Forensic reporting (ruf tag):
- Sample failing messages. Forensic reports contain samples of messages that failed DMARC; useful for diagnosing specific issues.
- Privacy considerations. Forensic reports may contain personal data; ensure recipient address protected and compliant with privacy regulations.
- Many providers don't send ruf. Some major providers do not send forensic reports due to privacy concerns; rua reports more reliable.
A financial services client we worked with through 2025 illustrates cautious DMARC reject deployment. PCI DSS v4.0 compliance deadline drove DMARC enforcement requirement. Their environment included: 12 sending domains across business units; approximately 40 third-party services sending on behalf of the domains (CRM, marketing tools, transactional services, vendor systems); legacy infrastructure with imperfect authentication; risk-averse culture preferring gradual progression. Deployment timeline: month 1-3 p=none monitoring identifying all sending sources through aggregate reports; month 4 authentication remediation for identified senders with broken SPF/DKIM; month 5-6 p=quarantine pct=25 with weekly review of impact; month 7 p=quarantine pct=100 stable; month 8-9 p=reject pct=25 monitoring closely; month 10 p=reject pct=50; month 11-12 p=reject pct=100 across all domains. Throughout deployment we addressed: 17 third-party services with authentication problems requiring vendor coordination; 8 internal systems with DKIM key rotation issues; 3 legacy applications requiring infrastructure replacement; ongoing monitoring catching new sending services added during the year. Final state: all 12 domains at p=reject pct=100 with sp=reject; comprehensive ARC implementation across forwarding infrastructure; full Google Postmaster Tools v2 high compliance scores; PCI DSS v4.0 compliance achieved on schedule. Project cost: approximately $45,000 across 12 months including consulting, vendor coordination, internal time. The lesson: cautious progression suits risk-averse environments and complex infrastructure; the 12-month timeline justified by the substantial scope. Operators with simpler infrastructure can compress to 3-4 months; operators with complex infrastructure may need 6-12 months for safe progression. The key principle: never skip levels and never rush levels; authentication issues identified during slow progression are issues that would have caused production problems with fast progression.
Decision framework
The decision framework for DMARC quarantine vs reject in 2026:
Use p=quarantine when: in middle of deployment progression from p=none; complex sending infrastructure with many third-party services still being identified; ongoing risk tolerance for false positives preferred; operational maturity not yet sufficient for reject; specific compliance requirements meet quarantine threshold without requiring reject.
Use p=reject when: DMARC deployment matured with all legitimate senders properly authenticating; SPF and DKIM alignment confirmed across all sending sources; operational discipline established to maintain authentication; maximum security posture appropriate for domain; compliance frameworks recommend or require p=reject (PCI DSS v4.0); inbox placement optimisation matters; phishing protection priority.
Use p=reject from day one when: parked domains that never send mail; subdomain protection through sp=reject on root domain; specific high-security contexts justifying immediate enforcement; very small sending infrastructure with complete understanding from start.
Use quarantine to reject progression when: standard deployment following p=none monitoring; want graduated enforcement reducing transition risk; pct tag enables progressive transition; time available for proper deployment.
Use accelerated progression when: compliance deadline pressure; complete sending infrastructure understanding; willing to accept higher risk during compressed timeline; technical capacity to address issues quickly.
Stay at quarantine longer when: ongoing identification of new sending sources; authentication issues persisting; complex forwarding scenarios still being addressed; ARC adoption insufficient across mailing lists.
The 2026 default progression for typical operators:
- Deploy p=none with rua reporting; monitor 4-12 weeks identifying all senders
- Address authentication failures identified in aggregate reports
- Progress to p=quarantine pct=25 for 2 weeks observing impact
- Progress to p=quarantine pct=100 for 2-4 weeks
- Progress to p=reject pct=25 for 2 weeks
- Progress to p=reject pct=100 ongoing
- Include sp=reject on root domain DMARC throughout
- Continue monitoring aggregate reports for ongoing health
- Implement ARC for any mailing lists or forwarders under operator control