Why did changing DMARC policy to quarantine send emails to spam, and how to fix it?
Published 10 Aug 2025
Updated 11 Aug 2026
11 min read
Summarize with
Updated on 11 Aug 2026: We updated this guide for RFC 9989, including t=y testing, the removal of pct, and safer quarantine rollout guidance.
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 gave receivers a clear request to treat DMARC-failing mail as suspicious, often by placing it in spam or bulk or adding negative filtering weight.
The fix is not to keep flipping the policy between none and quarantine. 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 test quarantine before applying it fully. Suped's DMARC monitoring workflow groups sources, shows authentication outcomes, flags unaligned senders, and provides 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 offers no domain-owner disposition preference and allows report collection when a reporting address is present. 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. The receiver still makes the final disposition decision and can override the requested policy.
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.
- None is observation mode. Quarantine requests enforcement, although receivers retain final filtering control.
- 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 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.
- 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 passes when the connecting IP is permitted for the envelope sender domain.
- DKIM passes when 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.
- SPF is aligned when the envelope sender domain has the same organizational domain as From.
- DKIM is aligned when the DKIM d= domain has 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; rua=mailto:dmarc@yourdomain.com
A stricter record that raises the risk of false failuresdns
v=DMARC1; p=quarantine; 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. Aligned DKIM is usually the stronger route 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.
- Move back to none only if legitimate mail is actively being lost, then treat that as a temporary rollback.
- Read the failing message headers and confirm whether DMARC failed because SPF, DKIM, or both were unaligned.
- Use aggregate reports to list all mail streams, not just the one test email that went to spam.
- Set up custom DKIM for each sender and use a custom bounce domain when aligned SPF is needed.
- Send real test messages and check the resulting headers, then confirm in aggregate reports over several days.
- Publish p=quarantine with t=y to test the policy, then remove t=y to apply quarantine after the reports show legitimate mail is ready.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped 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 keeps the review in one place.
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 RFC 9989 changed
RFC 9989 replaced the original DMARC specification in 2026. The practical rollout change is the removal of pct, which receivers applied inconsistently. The new t=y test mode asks receivers to apply a policy one level below the published policy while reporting continues. RFC 9989 also adds clearer guidance for policy testing and indirect mail flows.
- With p=quarantine; t=y, the expected policy applied to DMARC failures is none.
- With p=reject; t=y, the expected policy applied to DMARC failures is quarantine.
- Removing t=y applies the published p policy, because t=n is the default.
- Older receivers can ignore unknown tags, so reports and real-message header checks remain necessary during the transition.
Quarantine policy in test modedns
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@yourdomain.com
Treat t=y as a controlled enforcement test, not a guarantee of zero filtering impact. Receivers using older DMARC implementations can ignore the unfamiliar t tag and apply p=quarantine, so monitor representative mailbox providers and keep a rollback 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 t=y | Policy test | No percentage sampling |
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. Internal tests still help, but one mailbox should not be the final source of truth.
A safe rollout pattern
A safe move to quarantine is staged by policy state, not by message percentage. Start with none while reports identify normal senders. Fix high-volume legitimate sources first, then check low-volume but important sources. Publish quarantine with t=y for testing, watch reports daily, and remove t=y only after legitimate mail is passing DMARC.
Suggested enforcement readiness
Use these operational gates for rollout decisions, not as universal guarantees.
Not ready
p=none
Multiple legitimate senders fail or appear unknown.
Investigate
Fix senders
Known mail streams still have authentication or alignment gaps.
Test quarantine
p=quarantine; t=y
Known senders pass and remaining failures are explainable.
Apply quarantine
p=quarantine
Legitimate mail streams are verified and monitored.
Use a record like this when you are ready to ask RFC 9989-aware receivers to test quarantine at the lower none policy. Keep reporting enabled so you can see what the policy would catch, and account for older receivers that can ignore t=y.
Quarantine test-mode exampledns
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@yourdomain.com
When the reports show that legitimate mail is ready, remove t=y to request quarantine for DMARC failures. 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 manage policy changes 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 rollout sequence is none for visibility, quarantine with t=y for testing, then full quarantine by removing t=y. Reject is a separate risk decision. RFC 9989 advises general-purpose domains against p=reject when users participate in Internet mailing lists, because forwarding and message modification can break DMARC. The transition process is covered in more detail in this rollout guide. Quarantine is not a deliverability fix by itself. It is a policy request for mail that fails to authenticate your visible From 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.
Test quarantine with t=y, then remove the flag after legitimate senders pass DMARC.
Common pitfalls
Treating SPF pass as DMARC pass hides Return-Path alignment failures in plain sight.
Adding SPF includes without changing the custom bounce domain leaves SPF alignment broken.
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 applying quarantine.
Document approved senders and require authentication review before any new system sends mail.
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 test quarantine before applying it. Suped is our product. Its DMARC workflow groups reports by sender, flags alignment failures, sends change alerts, and keeps multiple domains in one account for ongoing review.
The target state is simple: every approved sender passes DMARC through aligned DKIM or aligned SPF, reports are monitored, and policy changes are tested before enforcement.
