Why did changing DMARC policy to quarantine send emails to spam, and how to fix it?
Published 10 Aug 2025
Updated 19 Oct 2026
12 min read
Summarize with
Updated on 19 Oct 2026: We clarified why quarantine affects third-party mail sent to your own staff and how to verify authentication before testing enforcement.
Changing DMARC from none to quarantine can send legitimate emails to spam when they already fail DMARC because neither SPF nor DKIM passes with domain alignment. The quarantine policy gave receivers a clear request to treat DMARC-failing mail as suspicious, often by placing it in a spam or junk folder or adding negative filtering weight.
First confirm the failure in the message headers, then use DMARC aggregate reports to identify sending sources, fix SPF or DKIM alignment for each legitimate source, and test quarantine before applying it fully. Suped is our DMARC reporting and email authentication platform. Its 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. Check the receiving system's Authentication-Results header first. A DMARC failure makes quarantine a likely contributor; receiver logs or filtering details are needed to confirm the cause. If DMARC passes, investigate content, reputation, user filtering, or mailbox-specific rules. A DMARC pass does not guarantee inbox placement.
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 checks whether either passing SPF or DKIM result has domain alignment with the visible From domain. 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 of SPF and DKIM checks, domain alignment, and DMARC results before inbox or spam placement.
Why your own inbound mail is affected
DMARC follows the visible From domain, even when the recipient is at the same company. The DMARC policy discovery rules use that author domain, rather than the recipient's domain, to find the applicable policy.
For example, an HR system can send as hr@yourdomain.com to employee@yourdomain.com while using sender.example for both its Return-Path and DKIM signing domain. Your receiving server sees an external message claiming your domain, so your quarantine policy applies if DMARC fails. Configure the HR sender to sign with your domain or use an authenticated custom bounce domain. Adding the sender to your main domain's SPF record alone does not change those identities.
Check the message headers first
Start with the exact message that went to spam. Open the full headers and use the Authentication-Results added by your receiving system or trusted gateway, as described in RFC 8601. Compare header.from with SPF's smtp.mailfrom and each passing DKIM header.d value, then check dmarc=pass or dmarc=fail. If DMARC failed under quarantine, check receiver logs for the action taken.
An SPF softfail does not count as an SPF pass for DMARC, but a passing DKIM signature with domain alignment can still make DMARC pass. 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 without matching your visible From domain.
|
|
|
|
|---|---|---|---|
From | header.from | Intended sending domain | Unexpected author domain |
SPF | smtp.mailfrom versus header.from | Pass with domain alignment | Unaligned pass or no SPF pass |
DKIM | Each passing header.d versus header.from | At least one aligned pass | No passing signature with alignment |
DMARC | Authentication result | pass | fail |
Header fields that matter when quarantine sends mail to spam
Example headers with passing SPF and DKIM but failing DMARC
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. Compare the authentication results and policy disposition in aggregate reports. Reports summarize participating receivers' observations and do not prove inbox placement. Cross-check them against your sender inventory, including infrequent 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.
- Under relaxed alignment, SPF matches when the envelope sender and From domains share an organizational domain.
- Under relaxed alignment, DKIM matches when a passing signature's d= domain and From domain share an organizational domain.
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
How to fix legitimate email failing DMARC
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 p=none temporarily if legitimate mail is being disrupted. Allow cached DNS records to expire before assessing the rollback.
- Read the failing message headers and check for SPF or DKIM authentication failures as well as domain mismatches. DMARC fails when neither method passes with domain alignment.
- Use aggregate reports alongside your sender inventory to list legitimate mail streams, including infrequent senders.
- Enable custom DKIM for each sender and verify its DNS key and d= domain. Configure a custom bounce domain and its required SPF record when using the SPF path to DMARC.
- Send real test messages to representative external recipients and check their headers. Review reports over several days and include infrequent sending cycles before enforcement.
- Use p=quarantine; t=y only after accounting for receivers that ignore t=y and enforce quarantine. Remove t=y when legitimate mail streams are verified; keep p=none during diagnosis if enforcement is still disrupting mail.
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, with alerts for authentication changes. 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. Check the TXT record at _dmarc.yourdomain.com for syntax errors, duplicate DMARC records, strict alignment settings, and policy values that do not match the rollout plan. Confirm that rua points to your reporting destination. If the visible From uses a subdomain, inspect its own DMARC record and any inherited sp or p policy.
How RFC 9989 affects quarantine testing
RFC 9989 replaced the original DMARC specification in May 2026. The practical rollout change is that pct is now historic after inconsistent receiver handling. The 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 requests the published policy, because t=n is the default; receivers retain final filtering control.
- 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
Receivers using older DMARC implementations can ignore t=y and apply p=quarantine. Keep p=none while diagnosing active delivery problems; use test mode only with monitoring of representative mailbox providers and 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.
Check every legitimate mail stream
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 authentication | Does not change the envelope sender domain |
Custom DKIM | Passing DKIM with domain alignment | Must be enabled and verified for each sender |
Custom bounce | Passing SPF with domain alignment | Needs SPF configuration; forwarding can break it |
Set t=y | Lower-policy testing on supporting receivers | Older receivers can ignore it and enforce quarantine |
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.
How to roll out quarantine safely
Stage quarantine by verified mail stream and policy state. Start with none while reports identify normal senders. Fix high-volume legitimate sources first, then check low-volume but important sources. When the sender checks are complete, test quarantine with t=y while accounting for receivers that ignore it. 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; account for receivers that ignore t=y.
Apply quarantine
p=quarantine
Legitimate mail streams are verified and monitored.
The test-mode record above asks RFC 9989-aware receivers to apply the lower none policy. Keep reporting enabled and compare fresh external tests with reports from before and after the change. Allow DNS caches to expire before judging a policy change or rollback.
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. Confirm that legitimate mail streams are accounted for and configured, with monitoring in place; explain remaining failures separately, including unauthorized sending and forwarding. Unknown senders should be separated from approved senders, not mixed into one vague failure count.
Use none for visibility, test quarantine with t=y after accounting for legacy receivers, then request 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 with t=y only after checking legacy receiver behavior; remove it when senders pass.
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 view
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 view
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
Frequently asked questions
No. It tells receivers that failed DMARC mail should be treated as suspicious, often by placing it in spam or bulk. Receivers still apply their own filtering rules and can override the requested policy.
Yes. DMARC needs at least one passing authentication result with domain alignment to the visible From domain. If SPF and every passing DKIM signature authenticate only unrelated vendor domains, DMARC fails even though SPF and DKIM pass.
Only sometimes. It can help SPF authentication, but it does not fix SPF alignment unless the envelope sender domain also matches the visible From domain.
Roll back temporarily if legitimate mail is being disrupted, allowing cached DNS records to expire. Use that period to fix sender authentication and domain alignment. Before testing quarantine with t=y, account for receivers that ignore it and enforce quarantine.
Aligned DKIM is usually stronger for third-party platforms because SPF can break through forwarding. Aligned SPF still matters, especially for direct sending systems.
RFC 9989 marks pct as historic, so percentage sampling is no longer part of the current standard. Older receivers can still interpret pct under RFC 7489, while current implementations ignore it. Use p=none during diagnosis and account for legacy receiver behavior before using t=y.
