DMARC Policy None vs Quarantine vs Reject: Which Should You Use?

Choosing the right DMARC policy is critical for securing your email infrastructure against spoofing, phishing, and domain impersonation. A Domain-based Message Authentication, Reporting, and Conformance (DMARC) record uses Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to dictate how receiving mail servers should handle unauthorized messages claiming to be from your domain. Before you adjust your DNS records, it is always a best practice to test your current setup using the Email Security Checker to instantly spot missing SPF, DKIM, or DMARC configurations and ensure your email posture is ready for policy changes.

Selecting the wrong policy prematurely can accidentally block legitimate business emails, while keeping your policy too lax leaves your customers vulnerable to phishing scams. Understanding the precise mechanical differences between none, quarantine, and reject allows you to build a safe, phased rollout strategy that guarantees robust protection without disrupting daily operations.

The Three DMARC Policies Explained

DMARC offers three distinct policy states through the p= tag in your DNS TXT record: monitoring (none), isolation (quarantine), and blocking (reject). Each policy level increases the enforcement level applied by receiving mail servers when an inbound message fails DMARC alignment.

DMARC Policy: None (p=none) Explained

The p=none policy is strictly a monitoring or reporting mode. When a receiving server evaluates an email that fails SPF and DKIM alignment, it takes no action against the delivery; the message goes straight to the recipient's inbox just as normal. However, the receiving server generates a daily XML file called a DMARC aggregate report (RUA) and sends it back to the domain owner.

• Primary Use Case: Initial domain assessment, auditing third-party senders, and discovering all legitimate mail streams.
• Security Benefit: Zero risk of disrupting legitimate email flow.
• Drawback: Provides zero protection against spoofing or phishing attacks.

DMARC Policy: Quarantine (p=quarantine) Explained

The p=quarantine policy tells receiving mail servers to treat failing emails with high suspicion. If an email fails both SPF and DKIM alignment, the receiving provider will typically route the message directly into the recipient's Spam or Junk folder rather than delivering it to the primary inbox.

• Primary Use Case: Intermediate testing phase after monitoring, or for secondary domains that do not send critical customer-facing emails.
• Security Benefit: Drastically reduces the chances that a spoofed email will be seen by users, without outright deleting the message.
• Drawback: Legitimate emails that suffer from alignment issues or misconfigured third-party services will end up in spam folders, causing delivery complaints.

DMARC Policy: Reject (p=reject) Explained

The p=reject policy is the ultimate goal of DMARC implementation. It instructs receiving mail servers to drop or completely block unauthorized messages at the SMTP connection level before they ever reach the user's mailbox or spam folder.

• Primary Use Case: Mature domains with 100% verified mail streams and fully aligned SPF and DKIM records.
• Security Benefit: Complete immunity from exact-domain spoofing and phishing attacks using your brand name.
• Drawback: Any legitimate service failing to align its SPF or DKIM will experience complete email delivery failure.

Comparison Table: DMARC None vs Quarantine vs Reject

Feature / Behavior	p=none (Monitoring)	p=quarantine (Isolation)	p=reject (Blocking)
Action on Failure	Deliver to Inbox	Route to Spam / Junk	Drop / Block at SMTP Level
Delivers Aggregate Reports	Yes	Yes	Yes
Delivers Forensic Reports	Yes (if configured)	Yes (if configured)	Yes (if configured)
Protection Against Spoofing	None	Moderate	Maximum
Risk of Blocking Legitimate Mail	None	Low to Moderate	High (if misconfigured)
Recommended Phase	Week 1 - 4	Month 2	Month 3+

Step-by-Step Implementation Strategy

Transitioning safely from none to reject requires a methodical, step-by-step approach over several weeks. Jumping straight to reject is a common mistake that breaks legitimate email workflows.

Step 1: Deploy a Monitoring Policy (p=none)

Create a DMARC record targeting your domain with a p=none tag to start collecting visibility data. Set up a dedicated email address to receive XML reports.

Example DNS TXT Record for _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

Verify your record using the command line with dig:

dig +short TXT _dmarc.example.com

Step 2: Analyze Aggregate Reports

Wait at least two to four weeks to gather RUA XML reports from major providers like Google, Microsoft, and Yahoo. Parse these reports using log analysis tools or visualization software to identify:

• Legitimate IP addresses sending mail on your behalf (e.g., 192.0.2.50).
• Third-party vendors (e.g., Salesforce, Mailchimp) that need proper SPF inclusion or DKIM CNAME setup.
• Unauthorized or malicious IP addresses attempting to spoof your domain.

Step 3: Move to Quarantine (p=quarantine)

Once all legitimate senders show 100% alignment in your DMARC reports, increase your enforcement level. You can start by applying the policy to a small percentage of traffic using the pct tag, then scale it up.

Example DNS TXT Record for 10% quarantine:

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

After verifying that internal users report no missing legitimate emails at 10%, increase pct=100:

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

Step 4: Enforce Full Protection (p=reject)

After running at p=quarantine with pct=100 for a few weeks without issue, update your record to enforce permanent blocking.

Example DNS TXT Record for full rejection:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com

Common Mistakes and How to Fix Them

• Mistake 1: Skipping the p=none Monitoring Phase. Jumping straight to p=reject without checking logs will instantly block transactional emails, password resets, and marketing campaigns.
  • Fix: Always spend 30 days analyzing p=none reports before changing policy states.
• Mistake 2: Forgetting SPF Alignment Rules. SPF requires the domain in the Return-Path (Envelope From) header to match the domain in the From header visible to the end user.
  • Fix: Use subdomain delegation or align your third-party mailers using custom DKIM signing keys.
• Mistake 3: Invalid DMARC Syntax in DNS. Small typos in the record string will cause receiving mail servers to ignore the policy entirely.
  • Fix: Ensure the record name is strictly _dmarc.yourdomain.com and all tags are separated by semicolons.

DMARC Implementation Checklist

• Ensure valid SPF records are published for all sending IPs and third-party services.
• Configure custom DKIM keys and verify successful signing across all mail streams.
• Publish a p=none DMARC record with a working rua= reporting mailbox.
• Collect and analyze DMARC XML reports for a minimum of 30 days.
• Fix any alignment failures discovered in your reporting logs.
• Upgrade to p=quarantine at 10% traffic, scaling up to 100%.
• Graduate to p=reject once all legitimate mail streams pass alignment tests.