Debug DMARC Policy Issues

Why Do DMARC Policies Sometimes Fail Even When Set to p=quarantine and p=reject?

You’ve set your DMARC policy to p=quarantine and p=reject—so why are unauthorized messages still landing in inboxes? You’d expect strict enforcement, but some emails slip through anyway.

The issue isn’t the policy itself. It’s how email servers interpret and act on it. DMARC is only as strong as the underlying authentication chain. Even with both quarantine and reject rules active, misaligned DKIM, inconsistent SPF, or overlapping policies can prevent enforcement.

Think of DMARC as a gatekeeper who only checks IDs at the door—but if the ID is fake, or the gate is open from a side entrance, the guard doesn’t stop the intruder. The same happens in email: unless every part of the authentication path is correct, DMARC policies can be bypassed.

Key takeaways

DMARC policies are enforced by receiving mail servers, not senders—your config alone doesn’t guarantee delivery control.
Setting both p=quarantine and p=reject does not guarantee enforcement if SPF or DKIM alignment fails at the receiving end.
Overlapping policies across domains or incorrect DKIM signatures can cause DMARC to be ignored, even when correctly configured.

What Happens When Both p=quarantine and p=reject Are Set in a DMARC Record?

If you set both p=quarantine and p=reject in a single DMARC record, the policy is treated as invalid by compliant email systems. Most receiving servers will ignore the entire DMARC policy or fall back to p=none, resulting in no enforcement. This leads to unpredictable outcomes—some messages may be quarantined, some rejected, and others delivered normally, depending on the receiver’s implementation. The result is inconsistent protection and poor visibility into authentication failures.

Why DMARC Enforces a Single Enforcement Action

DMARC is designed to specify one policy action at a time. The p tag defines the overall enforcement level: none, quarantine, or reject. You can’t combine them. If a receiving server encounters multiple values, it treats the record as malformed or incomplete, and usually defaults to p=none. This is consistent with the DMARC specification in RFC 7483, which defines the policy field as a single value.

Let’s say you’re trying to improve inbox placement while still testing the impact of stricter rules. You might think setting both quarantine and reject gives you a safety net—but it doesn’t. Instead, you’ll get inconsistent behavior across different providers. Some will apply neither; others may apply only quarantine if that comes first in the record. There’s no guaranteed order, and no server will treat one as override.

How to Debug This Mistake Correctly

If you find that your DMARC reports show high failure rates or inconsistent outcomes, start by checking your DNS record using a real DNS lookup tool like MXToolbox or Google Public DNS. Look for multiple p values in a single TXT record. If present, remove the duplicate or conflicting value.

Use a tool like the MailTester email checker to verify that your domain’s authentication records (SPF, DKIM, DMARC) are properly configured and consistent across messages. Testing individual addresses helps identify whether failures are due to policy, configuration, or mail server behavior.

When in doubt, use p=quarantine during rollout to monitor impact. Once confident, switch to p=reject and monitor reports closely. Never set multiple enforcement policies—your receiver will ignore them, and your protection will break silently.

How to Validate Your DMARC Record Syntax and Enforcement Behavior

If both p=quarantine and p=reject are in your DMARC record, your policy is invalid. You can only have one enforcement tag per record. Use a real DNS lookup tool to check your DMARC record, verify it contains only one policy, and ensure it has proper syntax—quotes around values, correct tag order, and no duplicates. This prevents enforcement confusion and ensures your domain protection works.

Check Your DMARC Record with Trusted Tools

Use a public DNS lookup tool like MxToolbox or Spamhaus to validate your DMARC record in real time.
Paste your domain name into the tool and look specifically for the DMARC DNS record under the TXT records section.
Confirm the record starts with v=DMARC1; and that all tags use correct syntax, including surrounding quotes for values like p="reject" or p="quarantine".
Check for duplicate policy tags—having both p=quarantine and p=reject in the same record is syntactically invalid and will break enforcement.

Fix Common Syntax and Configuration Errors

Ensure all tags are separated by semicolons ; and that no tag is missing its required value.
Do not place tags in the wrong order. The v=DMARC1 tag must come first; policies like p, sp, and rua follow in any order, but each must be correctly formatted.
Verify that values like reject or quarantine are enclosed in quotes. Omitting quotes—e.g., p=reject instead of p="reject"—can cause parsing failure.
Double-check for extra spaces, missing semicolons, or typoed tags (like p=reject; vs p="reject").
Any syntax issue can cause the record to be ignored entirely—your domain will not benefit from DMARC enforcement until corrected.

Once your record is clean, monitor your DMARC reports (via the rua tag) to see if senders are still being filtered. A valid record ensures your domain’s reputation is protected, and emails from your domain are less likely to land in spam. For bulk validation of sender addresses and alignment checks, you can test domain-level policies using bulk list verification to catch related issues in your sending list.

How to Simulate DMARC Enforcement for Testing Before Sending

You can simulate DMARC policy enforcement by sending test emails from a sandbox domain with temporary SPF and DKIM records, then use inbox-placement testing to see how recipients like Gmail, Outlook, or Yahoo treat them. Review DMARC aggregate reports to confirm if messages were quarantined or rejected as expected—this reveals policy behavior without risking real sender reputation.

Set up a test environment with controlled DNS records

Use a dedicated test domain (e.g., test.yourcompany.com) to avoid interfering with live mail streams.
Set up a temporary SPF record with a strict mechanism, like v=spf1 include:_spf.google.com ~all, to simulate authorized sending sources.
Generate a temporary DKIM key and publish the selector record in DNS so signing is consistent during testing.
Configure your DMARC policy to p=quarantine or p=reject for this domain only, using a rua=mailto:[email protected] address to collect reports.

Test delivery behavior using inbox-placement tools

Use MailTester’s inbox-placement test to send sample messages from your test domain to inboxes at Gmail, Outlook, and Yahoo. This shows how real mail clients interpret DMARC alignment and policy.
Observe the message handling: does it land in the inbox, spam, or get rejected outright? This reveals if the policy is being enforced as intended.
Wait for DMARC aggregate reports (typically within 24–48 hours) at the designated rua address. These logs detail how receiving servers applied your policy.
Use tools like DMARC.org or RFC 7483 to interpret report data, verifying whether messages passed alignment and were processed correctly under your policy.

What to Do When DMARC Reports Show Inconsistent Results Across Email Providers

DMARC policy enforcement varies by provider: Gmail often quarantines messages when policy is set to p=quarantine, while Yahoo may reject, and Outlook might allow delivery despite policy. This inconsistency isn't a flaw in your setup — it’s how each provider interprets and applies DMARC. Use real-world inbox testing to see how your email behaves across actual inboxes, not just reports.

The 4 steps described in “Set up a test environment with controlled DNS records”, in order.

Why Providers Handle DMARC Differently

Even with identical DMARC records, email providers make independent decisions based on their own spam filtering models and user behavior data. For example, Gmail typically treats p=quarantine as a warning to the recipient, often routing to spam, while Yahoo tends to enforce rejection more strictly. Microsoft Outlook, especially in enterprise settings, may apply DMARC policies inconsistently — sometimes applying them, sometimes ignoring them.

This behavior reflects provider policy, not misconfiguration. The DMARC specification (RFC 7483) allows discretion in enforcement. As such, relying solely on aggregate reports from tools like DMARCian or Valimail can mislead; they only show policy application, not actual delivery outcomes.

Testing for Real-World Behavior

Let’s move beyond reports. The only way to know how your message lands is to test it in the actual inboxes where your audience reads email. Use MailTester’s inbox placement test to send a message from your domain to 12+ real inboxes, and see where it lands: inbox, spam, or blocked. This reveals whether Gmail quarantines, Yahoo rejects, and Outlook allows — exactly as expected.

With this data, you can adjust your strategy. If the goal is delivery, consider using p=none for testing and monitoring, then gradually move to p=quarantine for alignment with provider behavior, reserving p=reject only after confirming consistent enforcement across major providers. This avoids unintended delivery failures. You can run a test at MailTester’s Inbox Placement Test to see exactly how your emails perform in live environments. This is the only way to validate your DMARC setup across real user inboxes and not just compliance reports.

Why You Should Check Sender Reputation and Domain Age When DMARC Fails

Even with correct SPF, DKIM, and a DMARC policy set to p=quarantine or p=reject, your emails may still fail to deliver if the sender’s domain has poor reputation or is too new to have established trust. A brand-new domain with no sending history is often treated skeptically by receivers—even if authentication is perfect. This can trigger DMARC enforcement unexpectedly. You aren’t just validating syntax; you’re validating trust.

Domain Age and Sending History Matter

DMARC isn’t just about technical checks—it’s about sender legitimacy. New domains, especially those without a history of sending consistent, engageable mail, are more likely to be flagged. ISPs and email providers assess sender reputation through patterns: inbox placement, open rates, complaints. A cold domain, even with correct setup, is at high risk of being quarantined or rejected.

Spam traps and blacklisted IPs from past owners can carry over, especially if you’re using a domain previously associated with bulk or spammy sending. Even if you’ve done nothing wrong, the domain's reputation isn’t reset by setup changes. According to ICANN’s guidance on domain reputation, new domains face higher scrutiny until trust is built through consistent, deliverable communication.

Check Your List Health Before Sending

High bounce rates or invalid addresses in your list can signal poor list hygiene and damage reputation—even before the first email lands. Role accounts (like admin@ or sales@), disposable email domains, or fake addresses can appear in high volumes on a list and lead to complaints or delivery failures. These patterns look like spam to filters.

Let’s be honest: you can’t rely on SPF/DKIM/DMARC alone. If your list contains invalid or risky addresses, even correct authentication won’t help. Use MailTester’s bulk verification to catch these issues early. It checks for role accounts, disposable domains, and invalid formats—giving you a clearer picture of your list’s health before you send.

For real-time validation, integrate MailTester’s verification API into your workflow. It helps prevent bad emails from ever entering your queue. And if you're testing inbox placement, use the inbox tester to see how your email lands across providers—from Gmail to Outlook—before you send to thousands.

Common Causes of DMARC Enforcement Failures Beyond Policy Syntax

You're seeing DMARC enforcement failures even with p=quarantine and p=reject set because alignment is broken — either SPF or DKIM doesn’t match the From domain, or third-party services send from domains not covered by your policy. These misalignments bypass policy enforcement even when syntax is correct.

SPF or DKIM Alignment Issues

Verify that your SPF record declares only authorized sending sources, and that all emails use the exact From domain in the SPF mechanism (e.g., include:example.com must align with the From domain).
Check that your DKIM signatures are not signed with a different domain than the one in the From header. A mismatch here triggers DMARC failure, even if the signature is valid.
Use a tool like MXToolbox’s DKIM Inspector to validate signature alignment and signing domain consistency.

Misconfigurations in Subdomains and Third-Party Services

If you use subdomains (e.g., newsletter.yourcompany.com) for emails, ensure each has a proper DNS record with a unique or consistent DMARC policy — a missing or incorrect SPF/DKIM record there breaks alignment.
When using external senders (like email marketing platforms), confirm they’re not sending from a service domain (e.g., mail.mandrill.com) when your From domain is different.
Use MailTester’s bulk verification to spot-check sender consistency and detect mismatches in From domains across your list.
Check that any third-party service’s DKIM signing domain matches the From domain or is properly included in your SPF/DKIM configuration.

DMARC is not just about syntax — it’s about alignment across SPF, DKIM, and the From domain. Even with p=reject set, alignment failures let messages pass through, causing deliverability loss.

“Misaligned authentication is the most common reason DMARC fails in practice, even when policies are correctly published.” — DMARC.org

Test your sending setup with a real inbox placement tool like MailTester’s inbox placement checker to simulate how your emails are evaluated by real providers, including DMARC alignment enforcement.

How to Use DKIM and SPF Alignment to Support DMARC Enforcement

If both p=quarantine and p=reject are set in your DMARC record, alignment failures in either SPF or DKIM will trigger enforcement regardless of the policy value. For DMARC to pass, the domain in the From header must match the domain used in either the SPF (envelope sender) or DKIM (signature), and the alignment must be strict. If neither aligns, your emails will be treated as failed — even if the signing domain is correct, and regardless of whether the policy is set to quarantine or reject.

SPF Alignment: Envelope Sender Must Match From

SPF alignment validates that the domain in the MAIL FROM (envelope sender) matches the From domain. This is often overlooked because SPF is applied at the SMTP level and doesn't always reflect the end-user email. If your outbound mail uses a different sending domain — like [email protected] but [email protected] — SPF alignment fails, even if the sender is valid.

DKIM Alignment: Signing Domain Must Match From

DKIM alignment requires that the domain in the DKIM-Signature: d= tag matches either the From domain or its subdomain. A common mistake is signing with a domain different from the sender, such as using d=mail.company.com while sending from [email protected]. Unless both domains are in the same hierarchy (e.g., mail.company.com is a subdomain), alignment fails.

DMARC evaluates alignment at the recipient mailbox. Many email providers use RFC 7483 as the standard for alignment validation. If either SPF or DKIM fails alignment, the message fails DMARC, and even with p=quarantine, the email may end up in the spam folder — or worse, be rejected entirely by p=reject policies.

Use tools like MXToolbox’s DMARC report parser to analyze real-world DMARC reports. These reports show exactly which records failed alignment and why. Look for sp= (SPF alignment) and dk= (DKIM alignment) in the report results — both must be pass for a successful DMARC check.

When reviewing your DMARC report, ask: Does the signing domain match the From domain or a subdomain? Is the envelope sender the same as the From? If not, fix the misalignment. Many senders assume DKIM or SPF alone is enough; but DMARC enforcement is only as strong as the weakest alignment check.

Use MailTester’s email checker to test individual addresses for valid alignment before sending. It validates SPF, DKIM, and DMARC status in real time. For larger sends, use the bulk verification tool to clean lists and avoid sending to domains where alignment is likely to fail.

Real-World Example: Fixing a DMARC Record That Set Both p=quarantine and p=reject

Setting both p=quarantine and p=reject in a DMARC record creates a conflict that compliant mail servers ignore. The correct fix is to use only one policy tag. In this case, removing the duplicate p=quarantine and keeping just p=reject restored proper enforcement across all major email providers. The outcome was consistent detection and handling of spoofed messages.

The Root Problem: Duplicate Policy Tags

You might think setting both policies increases protection, but it doesn’t. The DMARC specification (RFC 7483) defines p as a single, required policy. When multiple p tags appear, servers that follow standards ignore the entire record to avoid unpredictable behavior. This is not a bug — it’s intentional.

For example, a record like v=DMARC1; p=quarantine; p=reject is syntactically invalid. Most validation tools catch this — but not all. That’s why testing your record with a service like MailTester’s real-time verification API is crucial before deploying.

Review the DMARC record for duplicate tags — Look for multiple p= entries. This is common when adding policies incrementally without checking the full record.
Use only one policy — Choose either p=quarantine for testing or p=reject for full enforcement. Do not mix them.
Validate the syntax — Use a publicly available tool like MxToolbox’s DMARC record checker to verify structure. While tools vary, RFC-compliant servers expect a single p tag.
Test the updated record with MailTester’s verification API — Send the record through a real-time check to confirm it's accepted and enforced across providers. This step is essential because some tools report “valid” even when the record is ignored by servers. Test your DMARC policy live.
Monitor reports — After deployment, check the rua email address for aggregate reports. This shows whether receivers are applying your policy correctly. The reports will reveal if your policy is now being followed.

Why Testing Matters

Even with a single valid policy, enforcement depends on receiving domain alignment, SPF/DKIM compliance, and proper DMARC setup. You can’t assume a record works just because it passes validation.

Testing your final configuration with a trusted tool ensures you’re not relying on assumptions. For instance, many domains pass internal checks but still fail real-world delivery because of misaligned policies. Let’s not assume — test.

Use MailTester’s inbox placement test to verify how your policy affects delivery in real inboxes across Gmail, Outlook, and others.

How to Monitor and Maintain DMARC Enforcement Long-Term

You should set up automated monitoring of DMARC aggregate reports (RUA), validate sender health with tools like MailTester before sending, and run inbox placement tests every quarter to ensure your p=quarantine and p=reject policies remain effective. Without this, misconfigurations or shifts in sender behavior can go unnoticed, leading to deliverability issues or accidental delivery to spam.

Track DMARC Reports Automatically

Configure your DMARC DNS record to send aggregate reports to a dedicated email address or third-party service.
Use a tool that parses and analyzes DMARC reports (like DMARC.org) to spot spikes in failed policies or unauthorized sources.
Set up alerts for unexpected increases in failure rates or new domains in reports — these often signal spoofing attempts or misconfigured email systems.
Review reports weekly or monthly to understand which senders are passing or failing, and adjust your policies or email processes accordingly.

Verify Sender Health and List Quality Regularly

Before sending, use MailTester’s bulk verification to catch invalid, disposable, or catch-all addresses that can hurt your sender reputation.
Integrate MailTester’s real-time verification API into your sending workflow to verify addresses on signup or purchase, reducing bounce rates and improving deliverability.
Check individual addresses using the email checker when you receive suspicious bounces or reports from recipients.
Ensure your ESPs (SendGrid, Mailchimp, HubSpot) are correctly configured to align with your DMARC policy — a mismatch here can trigger rejections or quarantines even with correct SPF/DKIM.
Run inbox placement tests every quarter using MailTester’s inbox tester to confirm that your p=quarantine and p=reject policies are still producing expected results across major inboxes.

DMARC is not a one-time setup — it requires ongoing oversight to stay effective. A misconfigured policy or a forgotten sender can quietly undermine your entire email program.

Even if your current DMARC policy is set to both p=quarantine and p=reject, that doesn’t guarantee long-term success. Changes in third-party email tools, internal marketing automation, or list growth can shift sender behavior. Regular checks and automated monitoring turn reactive fixes into proactive maintenance. The real win isn’t just alignment with policy — it’s sustained inbox placement and reputation health.

Conclusion: DMARC Isn't Just a Policy — It's a System

DMARC policies like p=quarantine and p=reject cannot both be active at once. Setting both creates ambiguity, leading to inconsistent enforcement and potential delivery failures. Only one policy should be deployed, chosen based on your domain’s current sending posture and risk tolerance.

Effective DMARC enforcement relies on correct SPF and DKIM alignment, up-to-date DNS records, and a sender reputation that reflects real-world behavior. Misconfigurations, outdated records, or poor reputation can cause legitimate emails to be marked as spam, even when policies are technically correct.

Use MailTester to verify your sending domains, test inbox placement across real inboxes, and catch misconfigurations before they impact delivery. This prevents false assumptions about DMARC failures and ensures your policy is enforced as intended.

Sources

Only 22.9% of top domains enforce DMARC with p=quarantine or p=reject, while 29.2% remain in monitoring-only p=none mode that blocks nothing. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can you set both p=quarantine and p=reject in a DMARC record?

No. Receiving servers ignore DMARC records with multiple policy tags. Use only one: p=none, p=quarantine, or p=reject.

Why does my email still get delivered when my DMARC policy is set to p=reject?

The DMARC record may have a syntax error, or the sending domain may not be aligned with SPF or DKIM. Check alignment and record validity.

What is the difference between p=quarantine and p=reject in DMARC?

p=quarantine means unauthenticated messages may be marked as spam. p=reject means they are blocked. Use only one policy.

How do I test if my DMARC policy is working?

Use MailTester’s inbox-placement testing to send test emails through real mail servers and see how they are processed.

Does DMARC enforcement vary by email provider?

Yes. Gmail, Yahoo, and Outlook enforce DMARC differently. Some may quarantine; others may reject. Test across providers.

Can a new domain pass DMARC immediately?

No. New domains often fail due to lack of sender reputation, even with correct authentication.

How often should I check my DMARC record?

Check after any change to SPF, DKIM, or DMARC policy. Run inbox tests quarterly to verify enforcement.

What tools can I use to debug DMARC issues?

Use MxToolbox, Spamhaus, or MailTester’s real-time verification and deliverability testing to debug and validate records.

Why do some emails pass DMARC even when SPF and DKIM fail?

DMARC requires alignment, not just presence. If SPF or DKIM fails alignment with the From domain, DMARC fails even if authentication passes.

Does MailTester support DMARC record analysis?

Not directly. But it supports inbox testing and deliverability analysis to evaluate how DMARC enforcement affects real delivery.

How does sender reputation affect DMARC enforcement?

Poor reputation can cause mail systems to bypass DMARC enforcement or flag legitimate messages as spam regardless of authentication.

Can role accounts or disposable domains cause DMARC issues?

Yes. These reduce sender reputation and increase bounce rates. Use MailTester to cleanse lists and avoid high-risk addresses.