Blog

How to Configure DMARC Quarantine and Reject Policies Without Losing Mail

Q: What is the difference between DMARC quarantine and reject policies?

DMARC p=quarantine instructs receiving servers to direct unauthenticated emails to the recipient's Spam or Junk folder. In contrast, p=reject commands servers to block failing emails at the gateway level, returning a 550 hard bounce error to the sender.

Q: Will setting DMARC p=reject block legitimate marketing emails?

Setting p=reject will block legitimate marketing emails only if those messages lack aligned SPF or DKIM signatures. As long as your ESP is configured with an aligned custom Return-Path and dedicated DKIM keys, marketing messages will pass DMARC and deliver normally.

Q: How do I use the pct tag for a safe DMARC rollout?

The pct tag specifies the percentage of unauthenticated messages subject to your DMARC policy. You can start with p=quarantine; pct=10; to apply filtering to 10% of failing messages, gradually increasing the value to 25%, 50%, and 100% as report data confirms zero false positives.

Q: How long should I stay on p=quarantine before switching to p=reject?

Most organizations should remain on p=quarantine; pct=100; for 2 to 4 weeks. This timeframe ensures you collect sufficient XML report data across multiple sending cycles, verifying that all legitimate transactional, corporate, and marketing streams pass alignment.

Q: Does DMARC p=reject guarantee 100% inbox deliverability?

No. DMARC p=reject prevents domain spoofing and satisfies mandatory mailbox provider security checks, but inbox placement still depends on sender reputation, engagement rates, list hygiene, and content quality.

Q: What happens if SPF fails but DKIM passes under DMARC reject?

DMARC evaluates as a PASS if either SPF or DKIM passes and is aligned with the From: header. If SPF fails (for example, due to email forwarding) but DKIM passes and is aligned, the message satisfies DMARC and is delivered successfully.

Learn how to transition your DMARC policy from p=none to p=quarantine and p=reject safely. Step-by-step enforcement workflow without losing legitimate email.

How to Configure DMARC Quarantine and Reject Policies Without Losing Mail

> TL;DR: Transitioning your dmarc quarantine reject policy from p=none to p=quarantine and eventually p=reject is the single most effective way to eliminate domain spoofing and meet 2026 mailbox provider requirements. However, jumping straight to full enforcement without auditing your authentication alignment can block legitimate transactional and marketing emails. This guide provides a step-by-step, risk-free staged rollout plan using the pct tag, alignment validation tools, and DMARC report triage to achieve strict enforcement without losing mail.

Email security and deliverability standards have fundamentally shifted. This dmarc enforcement guide explains how to move from monitoring to full rejection safely. Major mailbox providers like Google, Yahoo, and Microsoft now require domain owners sending bulk email to implement explicit DMARC (Domain-based Message Authentication, Reporting, and Conformance) policies. While many organizations successfully create a basic DMARC record with p=none, remaining in monitoring mode indefinitely leaves your domain vulnerable to impersonation, phishing, and domain spoofing.

Moving to enforcement—either p=quarantine or p=reject—instructs receiving mail servers how to handle unauthorized messages claiming to originate from your domain. Yet, IT and deliverability teams frequently delay this transition out of fear that misconfigured authentication will cause legitimate business emails to be junked or rejected outright.

Last updated: July 2026

What Are DMARC Policies? (p=none vs. p=quarantine vs. p=reject)

sendgrove how to configure dmarc quarantine reject policy inline a

A DMARC policy is a published DNS TXT record that tells receiving email servers what actions to take when an incoming email claiming to come from your domain fails both SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) authentication, or fails DMARC alignment. DMARC operates on three distinct policy modes defined by the p= tag.

Understanding the operational mechanics of each policy mode is essential before initiating any policy changes on your DNS server.

| Step | Stage | |---|---|

| Step | Stage | |---|---| | 1 | Monitoring | | 2 | Staged |

1. Monitoring Mode (p=none)

Setting p=none instructs receiving servers to treat failing emails normally while generating aggregate diagnostic reports (sent via the rua tag). Under p=none:

Unauthenticated or spoofed messages are delivered to the recipient's inbox or spam folder according to the receiver's standard filtering algorithms.
Domain owners receive DMARC XML reports detailing all IPs attempting to send mail on behalf of the domain.
Risk Level: Zero risk to legitimate email, but offers zero protection against phishing or domain impersonation.

2. Quarantine Mode (p=quarantine)

Setting p=quarantine directs receiving mailbox providers to isolate emails that fail DMARC authentication. Under p=quarantine:

Unauthorized messages are diverted away from the primary inbox into the recipient's Spam or Junk folder, or placed in a secure server quarantine queue.
Legitimate emails that fail alignment will no longer arrive in the inbox, surfacing existing authentication errors immediately.
Risk Level: Moderate. Protects recipient inboxes from direct phishing landing in primary folders, but misconfigured legitimate mail will end up in spam.

3. Reject Mode (p=reject)

Setting p=reject provides full DMARC enforcement. It commands receiving mail transfer agents (MTAs) to reject unauthorized messages at the SMTP gateway level before they ever reach the recipient's mailbox. Under p=reject:

Non-compliant emails are blocked immediately, resulting in an explicit SMTP 550 hard bounce error returned to the sender.
Impersonations and spoofed phishing campaigns are completely blocked from reaching end users.
Risk Level: High if improperly configured. Any legitimate sending service (CRM, helpdesk, ESP, or transactional gateway) lacking proper SPF/DKIM alignment will be permanently blocked.

DMARC Policy Comparison Matrix: dmarc p=quarantine vs p=reject

Comparing dmarc p=quarantine vs p=reject helps deliverability teams choose the right enforcement pace.

Why Moving to DMARC Enforcement (Quarantine or Reject) Is Mandatory in 2026

sendgrove how to configure dmarc quarantine reject policy inline b

For years, DMARC compliance was treated as an advanced security option primarily utilized by financial institutions and enterprise brands. In 2026, mailbox providers have made DMARC enforcement a foundational requirement for baseline email deliverability.

1. Gmail and Yahoo Sender Enforcement Standards

Google and Yahoo enforce mandatory authentication policies for all bulk senders (defined as sending 5,000+ messages per day to Gmail or Yahoo addresses). Under these guidelines, senders must:

Implement valid SPF and DKIM records aligned with the Header From domain.
Publish a DMARC policy with a minimum of p=none (with active progression toward p=quarantine or p=reject).
Maintain spam complaint rates below 0.10%, with an absolute hard threshold at 0.30%.
Provide a one-click unsubscribe header (RFC 8058) in all marketing and promotional communications.

Senders that remain permanently on p=none face increased scrutiny from receiver reputation filters. If a domain on p=none experiences spoofing or high complaint bursts, Gmail and Yahoo aggressively throttle delivery or route messages directly to spam folders.

2. Protecting Domain Reputation from Phishing and Spoofing

When a domain lacks DMARC enforcement, malicious actors can send spoofed phishing messages using your exact root domain in the From: header. Because B2B filters and consumer mailboxes evaluate domain-level reputation across all incoming mail, spoofed spam campaigns dilute your domain authority.

Enforcing p=quarantine or p=reject stops impersonation attacks instantly, preventing threat actors from damaging your domain trust score. Senders recovering from past deliverability issues often combine DMARC enforcement with a comprehensive domain reputation recovery plan to restore inbox placement.

3. Unlocking BIMI (Brand Indicators for Message Identification)

BIMI allows organizations to display their official verified brand logo alongside outgoing emails in supporting inboxes (including Gmail, Apple Mail, and Yahoo Mail). However, BIMI deployment strictly mandates DMARC enforcement:

The DMARC policy must be set to p=quarantine with pct=100, or p=reject.
p=none or p=quarantine with pct<100 will cause BIMI validation to fail completely.

If your marketing strategy includes BIMI logo verification, achieving full DMARC enforcement is an absolute prerequisite. To learn more about VMC certificates and BIMI records, consult our comprehensive guide on how to implement BIMI.

Prerequisites Before Changing Your DMARC Policy

Transitioning to p=quarantine or p=reject without thorough preparation is the primary cause of self-inflicted email delivery outages. Before modifying your DMARC DNS record, you must audit every layer of your email infrastructure.

1. Understanding DMARC Alignment: SPF vs. DKIM

DMARC requires at least one authentication mechanism—SPF or DKIM—to pass authentication and satisfy domain alignment with the From: header visible to the recipient.

SPF Alignment: The domain found in the Return-Path (Envelope From) address must match or share the same organizational root domain as the From: header.
DKIM Alignment: The domain specified in the DKIM signature (d= tag) must match or share the same organizational root domain as the From: header.

Under relaxed alignment (aspf=r and adkim=r, which are default settings), subdomains are aligned with the root domain. For example, mail sent from news.yourdomain.com with a From: header of yourdomain.com passes relaxed alignment. If strict alignment (aspf=s or adkim=s) is explicitly set, the domains must match exactly.

When sending across complex environments—such as root domains alongside subdomains—improper subdomain inheritance can cause unexpected failures. Ensure you review guidelines on subdomain email deliverability and authentication before locking down policies across multi-brand setups.

2. The SPF 10-DNS-Lookup Boundary

SPF evaluation mandates that receiving servers perform no more than 10 nested DNS lookups (include, a, mx, ptr, exists mechanisms) when resolving an SPF record. If your SPF record exceeds 10 lookups, receivers return an SPF PermError. Under DMARC p=quarantine or p=reject, an SPF PermError causes SPF alignment to fail immediately.

If DKIM is also misconfigured or unaligned on that stream, the message will be quarantined or rejected. Always test your SPF record using DNS tools to verify lookup depth prior to policy escalation.

3. Inventorying All Authorized Sending Platforms

Most mid-market and enterprise companies send email through multiple platforms:

Marketing Automation & Campaigns: Platforms like Sendgrove email marketing for newsletter and behavioral broadcasts.
Transactional & Web Application Gateways: SMTP relays, password reset triggers, billing receipts, and e-commerce receipts.
Corporate Workspace Email: Google Workspace, Microsoft 365, or specialized corporate mailboxes.
Third-Party SaaS Tools: Zendesk, HubSpot, Salesforce, Lever, or billing applications sending on behalf of employee email addresses.

If any of these platforms send emails with your @yourdomain.com in the From: header without aligned DKIM or custom Return-Path SPF, moving to p=quarantine or p=reject will cause their messages to fail delivery.

4. Cleaning Inactive & Invalid Contacts Before Enforcement

When enforcing strict security policies, high bounce rates combined with authentication failures can severely penalize sender reputation. Before altering DNS records, use Sendgrove email validation to verify your contact lists, remove invalid or role-based addresses, and eliminate soft bounce hazards. You can explore flexible validation options on our pricing page.

Step-by-Step Workflow to Move from p=none to p=quarantine and p=reject

To achieve DMARC enforcement safely without risking business continuity, implement a four-phase rollout strategy. This progressive method utilizes the percentage (pct) tag to gradually increase enforcement while monitoring XML report data.

Phase 1: Audit and Monitoring (p=none)

Begin by publishing a baseline DMARC monitoring record on your primary domain's DNS.

DNS Record Configuration:

Host / Name: _dmarc.yourdomain.com
Record Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Execution Steps:

Maintain p=none for 2 to 4 weeks while accumulating daily aggregate reports.
Ingest XML reports into a DMARC monitoring platform or parser tool.
Identify every IP address sending mail using your domain in the From: header.
Categorize senders into three groups:

Authorized Legitimate Services: Core ESPs, corporate mailboxes, transactional gateways.
Third-Party SaaS Platforms: Marketing tools, HR platforms, event platforms.
Unauthorized / Malicious Sources: External spammers or unauthorized domain usage.

Configure custom Return-Path domains (SPF alignment) and active DKIM keys for all authorized services.

Phase 2: Initial Quarantine Rollout using the pct Tag

The pct (percentage) tag instructs receiving servers to apply the DMARC policy to only a subset of unaligned emails. Unfiltered emails default back to p=none.

DNS Record Configuration:

Host / Name: _dmarc.yourdomain.com
Record Type: TXT
Value: v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Execution Steps:

Set p=quarantine with pct=10. This applies quarantine filtering to only 10% of failing emails, leaving 90% in monitoring mode.
Monitor aggregate reports and internal support channels for 5 to 7 days.
Check for unexpected legitimate delivery failures or customer support tickets regarding missing transactional receipts.
If no legitimate mail is impacted, increment the percentage tag to pct=25, then pct=50, and finally pct=100 over a 2 to 3 week window.

Phase 3: Complete Quarantine Stabilization (p=quarantine; pct=100)

Once pct=100 is reached under quarantine mode, 100% of unauthenticated messages are routed to recipient spam/junk folders.

DNS Record Configuration:

Host / Name: _dmarc.yourdomain.com
Record Type: TXT
Value: v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Execution Steps:

Maintain p=quarantine; pct=100; for 2 to 4 weeks.
Perform a comprehensive review of aggregate reports (rua) to confirm that legitimate volume shows 100% DMARC compliance (both authentication and alignment).
Confirm that BIMI records or security audits recognize p=quarantine as an active enforcement state.

Phase 4: Full Enforcement (p=reject; pct=100)

With zero legitimate sending streams failing alignment, escalate your policy to full rejection mode.

DNS Record Configuration:

Host / Name: _dmarc.yourdomain.com
Record Type: TXT
Value: v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Execution Steps:

Update the record value from p=quarantine to p=reject.
Ensure pct=100 (or omit pct, as 100% is default when unspecified).
Maintain ongoing aggregate report monitoring to detect any new third-party integrations added by internal teams without prior IT review.

How to Triage DMARC Alignment Failures and Prevent False Positives

Routine dmarc aggregate report xml triage prevents legitimate business mail from failing authentication.

When auditing XML reports during Phase 1 and Phase 2, you will inevitably uncover sending streams that fail DMARC alignment. Resolving these issues requires systematic triage.

1. Correcting Third-Party ESP Alignment

Many cloud applications send email with your domain in the From: header, but sign the email with their own default domain in the Return-Path and DKIM signatures.

To fix this:

Configure Custom Return-Path (SPF Alignment): Create a CNAME or MX/TXT record (e.g., bounces.yourdomain.com) pointing to your ESP's bounce handling servers. This aligns the Envelope From domain with your root domain.
Install Dedicated DKIM Keys (DKIM Alignment): Generate a unique 2048-bit DKIM selector (e.g., sg1._domainkey.yourdomain.com) inside your sending platform and publish the corresponding TXT record in your DNS.

2. Managing Email Forwarding & Indirect Mail Flows

When a recipient sets up automatic email forwarding (for instance, forwarding work email to a personal Gmail account), the forwarding server alters the message envelope. This breaks SPF authentication because the forwarding server's IP address is not listed in your domain's SPF record.

DMARC accounts for forwarding through DKIM survival:

Unlike SPF, DKIM signatures survive email forwarding, provided the body or headers are not modified by the intermediate mail server.
As long as DKIM passes and is aligned with the From: domain, DMARC evaluates to PASS, even if SPF fails due to forwarding.
Ensure that every sending stream has valid DKIM signatures before enabling p=quarantine or p=reject.

3. Understanding ARC (Authenticated Received Chain)

Modern mailbox providers (Google, Microsoft, Fastmail) use ARC (RFC 8617) to preserve authentication status across intermediate hops. When an email passes through an intermediate security gateway or mailing list, the gateway attaches an ARC seal attesting to the original authentication pass. Receiving servers evaluate ARC signatures to prevent false positives under strict DMARC rejection.

DMARC Policy Configuration Examples & DNS Tag Reference

When constructing your DMARC DNS TXT record, tags control policy behavior, report destinations, and alignment strictness. Below are ready-to-use record examples for common deployment scenarios.

Example 1: Phase 1 Monitoring Record (p=none)

Use this record when first deploying DMARC to discover sending sources without impacting delivery.

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-rua@yourdomain.com; ruf=mailto:dmarc-ruf@yourdomain.com; fo=1;

Example 2: Staged Quarantine Record (p=quarantine at 25%)

Use this record during Phase 2 to begin testing enforcement on a quarter of unauthenticated traffic.

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-rua@yourdomain.com; fo=1;

Example 3: Full Enforcement Record (p=reject) with Subdomain Policy

Use this record for complete protection on root domains and explicit rejection across all unused subdomains.

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-rua@yourdomain.com; fo=1; adkim=r; aspf=r;

DMARC Tag Dictionary & Syntax Rules

Common Pitfalls That Cause Legitimate Emails to Get Blocked During Enforcement

Avoiding deployment traps ensures a smooth progression from monitoring to full enforcement.

| 2 | Exceeding the SPF 10-DNS-lookup limit, causing silent SPF PermErrors. | | 3 | Neglecting shadow IT marketing tools sending with root domain From addresses. | | 4 | Leaving subdomains unprotected (sp=none) while enforcing root domain reject. | | 5 | Failing to test DKIM signature validity following DNS provider migrations. |

Pitfall 1: Rushing directly from p=none to p=reject

Organizing teams often set p=none and then prematurely jump to p=reject without reviewing aggregate XML reports. Unaligned transactional gateways (such as password reset engines or automated billing notices) are instantly blocked, creating immediate user disruption. Always use p=quarantine with pct progression before adopting p=reject.

Pitfall 2: Overlooking Shadow IT and Unaligned Third-Party Vendors

HR tools, customer feedback platforms, and sales automation software frequently send outbound email using employee email addresses in the From: header. If these applications are not explicitly configured with custom Return-Path or DKIM records, their messages will fail DMARC enforcement. Maintaining strict list hygiene and validating sender domains through Sendgrove email validation prevents delivery breakdowns across auxiliary communication streams.

Pitfall 3: Subdomain Policy Misconfigurations (sp Tag Conflicts)

If an organization publishes p=reject on _dmarc.yourdomain.com but omits the sp tag, receiving mail servers apply p=reject to all subdomains by default. If marketing campaigns send via news.yourdomain.com without dedicated DKIM keys, those campaign streams will fail. Explicitly verify subdomain alignment across all active sending subdomains.

Pitfall 4: Syntax Errors in DNS TXT Records

Common syntax errors include missing semicolons between tags, trailing spaces in URI addresses, or placing the v=DMARC1; tag second instead of first. Invalid syntax causes receiving servers to ignore the DMARC record entirely, reverting the domain back to unauthenticated status.

DMARC RUA Report XML Parsing & Diagnostic Walkthrough

Analyzing daily DMARC aggregate reports (rua) is the core mechanism for identifying unaligned sending sources during Phase 1 and Phase 2. Aggregate reports are delivered as compressed XML files containing diagnostic data sent by mailbox providers globally.

Understanding Key XML Nodes in DMARC Reports

A standard DMARC aggregate report contains specific XML elements that reveal source IPs, message counts, authentication results, and alignment decisions.

<record>
  <row>
    <source_ip>192.0.2.1</source_ip>
    <count>1450</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>yourdomain.com</domain>
      <result>pass</dkim>
      <selector>sg1</selector>
    </dkim>
    <spf>
      <domain>mail.thirdparty.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Step-by-Step Diagnostic Analysis

When inspecting the XML record above:

Source IP Evaluation (<source_ip>): The sending IP 192.0.2.1 represents the server transmitting messages on behalf of your domain.
Volume Metric (<count>): 1,450 messages were received from this IP address during the 24-hour reporting window.
DKIM Alignment: The DKIM signature domain (<domain>yourdomain.com</domain>) matches the Header From (yourdomain.com), producing a DKIM alignment result of pass.
SPF Alignment Discrepancy: While SPF passed at the IP level (<result>pass</result>), the Envelope From domain (mail.thirdparty.com) did not match the Header From domain (yourdomain.com). This indicates an unaligned Return-Path.
DMARC Final Evaluation: Because DKIM passed and satisfied domain alignment, the policy evaluation (<policy_evaluated>) evaluated to disposition: none (or pass under enforcement).

By systematically reviewing these XML aggregate nodes across all reporting providers, deliverability teams can verify that 100% of legitimate outbound traffic passes alignment before initiating p=quarantine or p=reject transitions.

FAQ

What is the difference between DMARC quarantine and reject policies?

DMARC p=quarantine instructs receiving servers to direct unauthenticated emails to the recipient's Spam or Junk folder. In contrast, p=reject commands servers to block failing emails at the gateway level, returning a 550 hard bounce error to the sender.

Will setting DMARC p=reject block legitimate marketing emails?

Setting p=reject will block legitimate marketing emails only if those messages lack aligned SPF or DKIM signatures. As long as your ESP is configured with an aligned custom Return-Path and dedicated DKIM keys, marketing messages will pass DMARC and deliver normally.

How do I use the pct tag for a safe DMARC rollout?

The pct tag specifies the percentage of unauthenticated messages subject to your DMARC policy. You can start with p=quarantine; pct=10; to apply filtering to 10% of failing messages, gradually increasing the value to 25%, 50%, and 100% as report data confirms zero false positives.

How long should I stay on p=quarantine before switching to p=reject?

Most organizations should remain on p=quarantine; pct=100; for 2 to 4 weeks. This timeframe ensures you collect sufficient XML report data across multiple sending cycles, verifying that all legitimate transactional, corporate, and marketing streams pass alignment.

Does DMARC p=reject guarantee 100% inbox deliverability?

No. DMARC p=reject prevents domain spoofing and satisfies mandatory mailbox provider security checks, but inbox placement still depends on sender reputation, engagement rates, list hygiene, and content quality.

What happens if SPF fails but DKIM passes under DMARC reject?

DMARC evaluates as a PASS if either SPF or DKIM passes and is aligned with the From: header. If SPF fails (for example, due to email forwarding) but DKIM passes and is aligned, the message satisfies DMARC and is delivered successfully.