Why did changing DMARC policy to quarantine send emails to spam, and how to fix it?
Published 10 Aug 2025
Updated 4 Jun 2026
10 min read
Summarize with
Changing DMARC from none to quarantine sent the emails to spam because at least one mail stream was failing DMARC, usually because SPF or DKIM did not match the visible From domain for DMARC. The quarantine policy did exactly what it was told to do: ask receivers to place DMARC-failing mail into spam or bulk instead of leaving final placement to normal filtering.
The fix is not to keep flipping the policy between none and quarantine. I would first confirm the failure in the message headers, then use DMARC aggregate reports to identify every sending source, fix SPF or DKIM alignment for each legitimate source, and only then move to quarantine with a staged percentage. Suped's DMARC monitoring workflow is built for this exact work: it groups sources, shows authentication outcomes, flags unaligned senders, and gives practical steps to fix them before enforcement causes avoidable spam placement.
Do not assume the policy change is the only reason for spam placement based on one test email. Confirm the Authentication-Results header first. If DMARC says fail, quarantine is the obvious cause. If DMARC passes, the spam placement is coming from content, reputation, user filtering, or mailbox-specific rules.
Why quarantine changed placement
A DMARC policy of p=none tells receivers to report failures but not apply a domain-owner requested penalty. A policy of p=quarantine tells receivers that messages failing DMARC should be treated as suspicious, commonly by placing them in spam. That difference is why the same message can inbox under none and land in spam under quarantine.
DMARC does not only ask whether SPF passed or DKIM passed. It asks whether either passing result matches the visible From domain. This is the part that causes most surprises. A platform can pass SPF using its own bounce domain and pass DKIM using its own signing domain, while still failing DMARC for your brand domain.
- Policy: None is observation mode. Quarantine is enforcement mode, even though receivers retain final filtering control.
- Alignment: SPF matches when the Return-Path domain is the same as, or is in the same organizational domain as, the visible From domain under relaxed alignment.
- DKIM: DKIM matches when the signing domain in the d= tag is the same as, or shares the same organizational domain as, the visible From domain under relaxed alignment.
- Result: DMARC passes when either aligned SPF passes or aligned DKIM passes. Both do not need to pass, but one aligned path must pass.
Flowchart showing SPF, DKIM, alignment, and the DMARC quarantine result.
What to check first
Start with the exact message that went to spam. Open the full headers and look for Authentication-Results. The important fields are the visible From domain, the SPF domain, the DKIM d= domain, and the DMARC result. If DMARC failed under quarantine, the receiver had a clear policy reason to place the mail in spam.
A soft fail in SPF also needs attention, but adding another include to SPF is not always the fix. SPF alignment uses the envelope sender domain, often shown as Return-Path, not every domain listed in your SPF record. If the third-party sender uses its own bounce domain, SPF can pass for that domain while still not match your visible From domain.
|
|
|
|
|---|---|---|---|
From | Brand domain | yourdomain.com | Unexpected domain |
SPF | Return-Path | Aligned pass | Pass, unaligned |
DKIM | d= domain | Aligned pass | Vendor d= |
DMARC | Policy result | pass | fail |
Header fields that matter when quarantine sends mail to spam
Header pattern that explains the spam placement
From: Team <news@yourdomain.com> Return-Path: bounce@sender.example DKIM-Signature: d=sender.example; s=s1; ... Authentication-Results: mx.example; spf=pass smtp.mailfrom=sender.example; dkim=pass header.d=sender.example; dmarc=fail header.from=yourdomain.com
If the failing mail is one known stream, headers can confirm the problem quickly. DMARC aggregate reports still matter because quarantine applies to every legitimate sender using the domain, including billing, receipts, statements, help desk mail, marketing platforms, CRM mail, and internal systems.
How alignment actually works
By default, DMARC uses relaxed alignment. If your DMARC record does not contain aspf=s or adkim=s, SPF and DKIM alignment are relaxed. Relaxed alignment means a subdomain can match the organizational domain. For example, mail.yourdomain.com can match yourdomain.com. Strict alignment means the domains must match exactly.
Passing authentication
SPF or DKIM can pass because the sending infrastructure was authorized or the signature verified. That alone does not prove the message passes DMARC.
- SPF pass: The connecting IP is permitted for the envelope sender domain.
- DKIM pass: The cryptographic signature validates against the selector and signing domain.
Passing DMARC
DMARC passes only when at least one passing authentication result also matches the domain the recipient can see in the From header.
- Aligned SPF: The envelope sender domain is the same organizational domain as From.
- Aligned DKIM: The DKIM d= domain is the same organizational domain as From.
This is why a message can show SPF pass and DKIM pass but still get a DMARC fail. The receiver is not contradicting itself. It is saying the infrastructure passed authentication for one domain, but the message did not authenticate the domain shown to the human recipient.
A quarantine record using default relaxed alignmentdns
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com
A stricter record that raises the risk of false failuresdns
v=DMARC1; p=quarantine; pct=25; aspf=s; adkim=s; rua=mailto:dmarc@yourdomain.com
The practical fix
The practical fix is to make each legitimate sender produce aligned SPF or aligned DKIM before enforcement. I usually prefer aligned DKIM for third-party platforms because forwarding and mailing-list behavior can break SPF, while DKIM often survives if the message body and signed headers are not modified.
- Pause: Move back to none only if legitimate mail is actively being lost, then treat that as a temporary rollback.
- Inspect: Read the failing message headers and confirm whether DMARC failed because SPF, DKIM, or both were unaligned.
- Inventory: Use aggregate reports to list all mail streams, not just the one test email that went to spam.
- Configure: Set up custom DKIM for each sender and use a custom bounce domain when aligned SPF is needed.
- Verify: Send real test messages and check the resulting headers, then confirm in aggregate reports over several days.
- Enforce: Return to quarantine gradually using pct, then move toward full quarantine or reject when the data supports it.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped is useful here because it turns raw XML reports into sender groups and issue lists. Instead of guessing whether the problem is SPF soft fail, DKIM d= mismatch, or a missing custom sender setup, Suped shows the failing source, the visible From domain, the authentication result, and the steps to fix it. For teams with many domains or client accounts, the multi-tenant dashboard also stops this becoming a spreadsheet exercise.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Before changing policy again, validate the record itself with the DMARC checker. This catches syntax errors, missing reporting addresses, strict alignment settings, and policy values that do not match the rollout plan.
What not to do
The most common wrong fix is to add a random include to SPF and expect DMARC to pass. That can authorize an IP for SPF, but it does not change the Return-Path domain used by the sender. If the Return-Path remains on a vendor domain, SPF stays unaligned. If DKIM is also signed with the vendor domain, DMARC still fails.
Avoid this shortcut
Do not publish quarantine for a domain until every known mail stream has been checked. DMARC affects sales mail, payroll notices, password resets, invoices, CRM messages, marketing campaigns, support replies, and automated system mail. A single successful test does not prove the domain is ready.
|
|
|
|---|---|---|
Add SPF include | SPF auth | Not alignment |
Custom DKIM | DKIM match | Per sender |
Custom bounce | SPF match | Forwarding risk |
Set pct | Safer rollout | Still enforces |
Common fixes and whether they solve DMARC alignment
Another mistake is assuming internal company accounts are a reliable test. Internal filtering can have local rules, quarantine handling, cached reputation, and user-level signals that do not match external recipients. I still test internally, but I do not use one mailbox as the final source of truth.
A safe rollout pattern
A safe move to quarantine is staged. Start with none while reports collect enough data to identify normal senders. Fix the high-volume legitimate sources first, then the low-volume but important sources. After that, use a small quarantine percentage and watch failures daily.
Suggested enforcement readiness
Use these thresholds as practical rollout gates, not as universal guarantees.
Not ready
Below 95% aligned
Multiple legitimate senders fail or appear unknown.
Investigate
95-98% aligned
Most volume passes, but important streams still need review.
Pilot quarantine
98-99% aligned
Known senders pass and remaining failures are explainable.
Ready to enforce
99%+ aligned
Legitimate mail streams are verified and watched.
Use a record like this when you are ready to test quarantine against a small portion of failing mail. Keep reporting enabled so you can see what the policy catches.
Staged quarantine exampledns
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com
If you do not already have a clean record, generate one with the DMARC record generator, then validate it before publishing. If DNS access is slow or spread across teams, Suped's hosted DMARC can simplify policy staging without repeated DNS edits.
When to use quarantine again
Move back to quarantine when you can explain the remaining failures. That does not mean every failed message has to be legitimate. It means legitimate mail streams are accounted for, configured, and monitored. Unknown senders should be separated from approved senders, not mixed into one vague failure count.
The exact policy sequence depends on risk tolerance, but the direction is consistent: none for visibility, quarantine for partial enforcement, reject for stronger domain protection. The safest transition path is covered in more detail in this rollout guide. The key point is that quarantine is not a deliverability fix by itself. It is a policy that penalizes unauthenticated or unaligned mail using your domain.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A broad check with the domain health checker helps catch related SPF, DKIM, and DMARC configuration issues before you retry enforcement. Use it alongside real header checks and aggregate report monitoring, not as a replacement for either.
Views from the trenches
Best practices
Check headers first, then use reports to find every other sender affected by the policy.
Keep relaxed alignment unless a clear security requirement justifies strict alignment.
Stage quarantine with pct after confirmed senders have aligned SPF or DKIM in place.
Common pitfalls
Treating SPF pass as DMARC pass hides Return-Path alignment failures in plain sight.
Adding SPF includes without changing the bounce domain leaves SPF unaligned.
Testing one mailbox misses billing, support, CRM, and automated system mail streams.
Expert tips
Prefer custom DKIM for third-party senders because it survives more routing changes.
Use aggregate reports daily during policy changes, especially after moving to quarantine.
Document approved senders so new tools do not bypass authentication review.
Marketer from Email Geeks says a sudden spam placement after quarantine should be checked against the message headers before assuming every future message is affected the same way.
2020-04-08 - Email Geeks
Marketer from Email Geeks says SPF and DKIM passing is not enough for DMARC when the authenticated domains do not match the visible From domain.
2020-04-08 - Email Geeks
The fix in plain terms
Changing DMARC to quarantine exposed an existing authentication gap. The mail did not suddenly become worse. The domain policy started asking receivers to penalize mail that did not prove it was allowed to use the visible From domain.
The durable fix is to identify every legitimate sender, configure custom DKIM or an aligned bounce domain for each one, validate headers, monitor aggregate reports, and reapply quarantine gradually. Suped is our product, and for most teams it is the best overall DMARC platform for this work because it combines automated issue detection, real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist and blacklist monitoring, and multi-tenant reporting for teams managing many domains.
The target state is simple: every approved sender passes DMARC through aligned DKIM or aligned SPF, reports are monitored, and policy changes are staged instead of guessed.
