Why did changing DMARC policy to quarantine send emails to spam, and how to fix it?
Matthew Whittaker
Co-founder & CTO, Suped
Published 10 Aug 2025
Updated 15 Aug 2025
9 min read
Shifting your DMARC policy from p=none to p=quarantine can sometimes lead to an unexpected outcome: legitimate emails suddenly landing in spam folders. This can be alarming, especially if you expect your emails to continue reaching the inbox without issue. The core reason for this behavior often lies in a misunderstanding of how DMARC works in conjunction with SPF and DKIM authentication. When a policy is set to quarantine, mailbox providers (like Google or Yahoo) are instructed to treat emails that fail DMARC authentication as suspicious, moving them to the recipient's junk or spam folder. This is a crucial step in email security, but it requires careful implementation to avoid legitimate mail being blocklisted.
The primary issue isn't necessarily that SPF or DKIM are failing, but rather that they are not aligning correctly with your DMARC record. Even if SPF passes authentication, if the domain in the Return-Path address doesn't match the From domain (or its subdomain), DMARC will fail SPF alignment. Similarly, for DKIM, if the d= tag in the DKIM signature doesn't match the From domain (or its subdomain), DKIM alignment will fail. When either of these alignments fails, DMARC considers the email unauthenticated, triggering the quarantine action.
To effectively address this problem, it's essential to understand the intricacies of DMARC alignment and how to monitor and adjust your email authentication settings systematically. This article will guide you through the common causes of DMARC quarantine issues and provide actionable steps to ensure your legitimate emails reach their intended destination.
DMARC, SPF, and DKIM are the pillars of email authentication, working together to verify sender identity and prevent spoofing. SPF (Sender Policy Framework) allows domain owners to publish a list of authorized sending IP addresses. DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify that an email hasn't been tampered with in transit and was sent by an authorized server. DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on these, providing a policy framework that tells receiving mail servers what to do with emails that fail SPF or DKIM authentication.
The critical concept is alignment. For DMARC to pass, either SPF or DKIM must align with the domain in the email's From header (the address visible to the recipient). If your DMARC policy is set to p=quarantine, and emails fail this alignment check, they are marked as spam. This differs from p=none, where failing emails are merely monitored and delivered as usual.
The alignment can be either relaxed (matching the organizational domain) or strict (matching the exact domain). By default, DMARC alignment is relaxed, meaning a subdomain can align with the root domain. You can explicitly set strict alignment (ad=s for SPF, as=s for DKIM) in your DMARC record if needed. The crucial aspect is ensuring that the domains used in your SPF and DKIM records are directly related to your email's From header domain.
Understanding this alignment principle is the first step in troubleshooting why changing to a quarantine policy might have unexpectedly impacted your email deliverability. For more detail, you can read about DMARC primer and alignment.
Common reasons for DMARC quarantine failures
Several factors can cause DMARC alignment failures, even if SPF and DKIM pass their initial authentication checks. The most common culprit is often the use of third-party email service providers (ESPs) or marketing automation platforms. When sending emails through these services, the Return-Path (also known as the Mail From or Envelope From) domain or the DKIM d= domain might belong to the ESP, not your own sending domain. This mismatch causes DMARC SPF or DKIM alignment to fail.
Another common reason is simply incomplete or incorrect SPF or DKIM setup for all sending sources. Many organizations use various systems to send email, from their primary mail server (Microsoft 365, Google Workspace) to CRM systems, marketing automation platforms, and transactional email providers. Each of these needs to be properly configured with SPF and DKIM records that align with your domain.
Here is a comparison of common DMARC failure scenarios:
Scenario: SPF alignment failure
The issue: Your email's Return-Path (envelope from) domain does not match or is not a subdomain of your email's visible From: header domain.
Example: You send an email via a third-party ESP. The From: address is you@yourdomain.com, but the Return-Path is bounces.esp.com.
Scenario: DKIM alignment failure
The issue: The domain in the DKIM signature's d= tag does not match or is not a subdomain of your email's visible From: header domain.
Example: Your email is signed with d=espsending.com, but your From: address is you@yourdomain.com.
In both cases, even if SPF or DKIM technically pass authentication, they fail DMARC alignment, leading to the quarantine policy being enforced. Understanding why emails go to spam due to DMARC is key to resolving these issues.
How to diagnose and fix DMARC issues
The most effective way to diagnose DMARC issues is by analyzing your DMARC reports. These reports, specifically RUA (aggregate) reports, provide detailed insights into which of your emails are passing or failing DMARC and why. While the raw XML reports can be difficult to read, there are services that parse them into an understandable format. You can learn more about troubleshooting DMARC issues from Google's admin help.
Once you have access to interpretable DMARC reports, you can pinpoint the exact sources of email failing alignment. For each identified source, you'll need to configure SPF and DKIM correctly to ensure they align with your From domain. This often involves adding appropriate include mechanisms to your SPF record for all legitimate sending services and setting up custom DKIM keys if your ESP provides that option. Remember, SPF and DKIM passing isn't enough, they must align with your visible From domain.
It's important to differentiate between DMARC failures and other reasons emails might go to spam, such as content issues, poor sender reputation, or blocklist (blacklist) listings. DMARC specifically addresses authentication and alignment. If your DMARC reports show passing authentication but emails still land in spam, other factors might be at play. You can utilize an email deliverability test to check comprehensive deliverability issues.
Tips for diagnosing DMARC issues
Utilize DMARC reports: Set up RUA and RUF tags in your DMARC record to receive aggregate and forensic reports. These reports are invaluable for identifying unauthenticated sending sources and troubleshooting.
Check email headers: Examine the full email headers of a message that went to spam. Look for DMARC authentication results, SPF, and DKIM authentication domains, and compare them to your From: header.
Verify third-party senders: Ensure all third-party services sending email on your behalf have proper SPF and DKIM configurations that align with your domain.
Safely transitioning to an enforcement policy
The transition to a p=quarantine or p=reject DMARC policy should always be a gradual process. Starting directly with an enforcement policy without adequate preparation can indeed lead to legitimate emails being sent to spam or even blocked entirely. This is why the industry strongly recommends a phased approach, starting with p=none.
First, establish your DMARC record with p=none and collect DMARC reports for several weeks (or months, depending on your email volume and complexity). These reports will reveal all legitimate email streams originating from your domain, including those you might not have been aware of. Use this data to ensure all your legitimate sending sources are properly configured for SPF and DKIM, and critically, that they achieve DMARC alignment. This might involve updating DNS records for your domain or configuring settings within your ESPs.
Once you are confident that all legitimate emails are consistently passing DMARC authentication and alignment, you can gradually move to p=quarantine. Monitor your DMARC reports closely after this change to catch any unforeseen issues. If deliverability problems arise, revert to p=none, fix the new issues, and then attempt the transition again. This iterative process is crucial for a smooth and successful DMARC implementation. You can learn more about safely transitioning your DMARC policy.
Policy
Description
Impact on unauthenticated mail
p=none
Monitoring mode. No action taken on emails that fail DMARC. Useful for initial setup and data collection.
Delivered to inbox, but reports are sent to the domain owner.
p=quarantine
Suggests that receiving mail servers should treat emails failing DMARC as suspicious.
Typically moved to spam or junk folders.
p=reject
Instructs receiving mail servers to block emails that fail DMARC authentication outright.
Emails are rejected and not delivered at all.
The common thread in these scenarios is the vital importance of DMARC reports. They are your primary tool for gaining visibility into your email ecosystem and ensuring that all legitimate email streams are properly authenticated before an enforcement policy (quarantine or reject) is enabled. Without monitoring these reports, you're essentially flying blind, risking the deliverability of important emails. Remember, a DMARC policy affects every email sent from your domain, including transactional emails, billing notices, and statements.
Views from the trenches
Best practices
Always start with a p=none DMARC policy to monitor email streams without impact.
Analyze DMARC aggregate reports regularly to identify all legitimate sending sources.
Ensure that SPF and DKIM records for all sending services align with your From: domain.
Use custom Return-Path and DKIM d= domains provided by your ESPs to achieve alignment.
Common pitfalls
Jumping straight to p=quarantine or p=reject without full alignment, causing legitimate emails to be quarantined.
Not monitoring DMARC reports, leading to unknown authentication failures.
Overlooking third-party senders that don't align with your domain's authentication.
Misunderstanding that passing SPF/DKIM authentication is different from DMARC alignment.
Expert tips
Implement a DMARC reporting tool to simplify the analysis of aggregate reports.
Regularly audit your SPF and DKIM records for all sending domains and subdomains.
Consult with an email deliverability expert if you encounter complex DMARC alignment issues.
Communicate DMARC policy changes internally to relevant teams to avoid confusion.
Expert view
Expert steve589 from Email Geeks says DMARC reports are crucial for daily monitoring to understand why alignment is failing, and that even when an organization reverts to p=none, the reports can still explain previous failures.
2020-04-08 - Email Geeks
Expert view
Expert wise_laura from Email Geeks says the primary reason emails go to spam when changing to quarantine is often due to DMARC alignment failures, even if SPF and DKIM authentication technically pass.
2020-04-08 - Email Geeks
Ensuring smooth DMARC enforcement
Changing your DMARC policy to p=quarantine is a significant step toward robust email security, but it requires thorough preparation and continuous monitoring. The key to avoiding legitimate emails landing in spam is ensuring proper SPF and DKIM alignment with your From domain for all your sending sources.
By following a structured approach involving initial monitoring with p=none, diligently analyzing DMARC reports, and meticulously correcting any alignment failures, you can transition to an enforcement policy with confidence. This not only protects your domain from phishing and spoofing but also ensures your legitimate communications consistently reach their intended recipients, maintaining strong sender reputation and avoiding unexpected blocklist occurrences.
Google or 
Yahoo) are instructed to treat emails that fail DMARC authentication as suspicious, moving them to the recipient's junk or spam folder. This is a crucial step in email security, but it requires careful implementation to avoid legitimate mail being blocklisted.
Microsoft 365, 
