Why are emails to O365 recipients getting quarantined and how to fix?
Matthew Whittaker
Co-founder & CTO, Suped
Published 31 May 2025
Updated 24 May 2026
8 min read
Summarize with
Emails to O365 recipients get quarantined when Microsoft 365 classifies the message as spam, bulk, spoofed internal mail, impersonation, or risky under the recipient tenant's own security policies. The fix is to separate a sender-side problem from a recipient-side rule, then correct authentication, reputation, and source patterns before asking the recipient admin for a policy change.
For an ESP, the most common pattern is selective quarantine. Some clients hit the problem, others do not. Often the affected clients send test messages to their own O365 domains through a third-party platform, so Microsoft sees mail claiming an internal domain but arriving from an outside IP. That can trip anti-spoof, anti-phishing, or tenant-specific rules even when the same message does not fail everywhere.
- First check: Group affected sends by recipient tenant, sending IP, visible From domain, DKIM domain, and template.
- Then inspect: Read the released message headers for SCL, BCL, authentication results, and quarantine reason.
- Do not assume: A domain safelist is a workaround, not proof that O365 has a global block on your platform.
Start with the direct diagnosis
I start by asking one question: does the same sender, IP, and message get quarantined across unrelated O365 tenants, or only inside specific customer tenants? That answer changes the fix. Broad quarantine across many unrelated tenants points to sender reputation, authentication, content, or IP neighborhood. Quarantine inside a customer's own tenant points to anti-spoofing, impersonation protection, transport rules, or strict inbound policy.
Fast answer
If SCL and BCL are high, fix sender reputation, list quality, content, authentication, and IP separation. If SCL and BCL are low but the message still lands in quarantine, the recipient tenant's own policy is usually doing the final action.
- SCL signal: Higher spam confidence means Microsoft filtering sees risk in the message or sender.
- BCL signal: Higher bulk confidence means the message looks like bulk mail to Microsoft.
- Tenant signal: Low scores with quarantine usually means the customer's policy made the decision.
That split matters because you control only some causes. You control SPF, DKIM, DMARC domain match, sending IP choice, suppression, and content. The recipient controls its quarantine policies, anti-spoof settings, tenant allow/block list, and transport rules.
Separate global problems from tenant policy
A clean test setup saves hours. Send the same message through the same production path to your own Microsoft 365 tenant, a non-Microsoft mailbox, and the affected customer tenant. Use the same envelope sender, DKIM selector, visible From domain, links, and body. If only the customer tenant quarantines it, treat the issue as policy-specific until the headers prove otherwise.
Flowchart showing matched tests, header review, authentication checks, and ownership.
Global sender problem
- Pattern: Multiple unrelated O365 tenants quarantine the same source.
- Owner: The sender or ESP can fix authentication, content, list quality, and IP use.
- Evidence: Higher SCL or BCL, repeated complaints, blocks, or poor IP grouping.
Recipient tenant problem
- Pattern: Only a specific organization quarantines its own test messages.
- Owner: The recipient admin must change quarantine, anti-spoof, or allow policies.
- Evidence: Low SCL and BCL with a tenant action that still sends mail to quarantine.
Read the message headers
Do not troubleshoot O365 quarantine from screenshots alone. Ask the recipient to release one sample and export the full original headers. Microsoft documents how users can find and release messages in Microsoft quarantine, but admins often need to provide the full trace when the message was quarantined by policy.
The values I care about first are SCL, BCL, SFV, CAT, authentication results, and the final action. One header sample does not prove the full issue, but a few matched samples show whether Microsoft is scoring the mail as bulk or the recipient tenant is applying a local rule.
Useful Microsoft header fieldstext
X-Forefront-Antispam-Report: SCL:5; BCL:6; SFV:SPM; Authentication-Results: spf=pass smtp.mailfrom=bounce.client.com; dkim=pass header.d=client.com; dmarc=pass action=none X-MS-Exchange-Organization-MessageDirectionality: Incoming
|
|
|
|---|---|---|
SCL | Spam confidence | Fix content or reputation |
BCL | Bulk confidence | Review consent and cadence |
SFV | Filtering verdict | Compare with action |
Auth | SPF, DKIM, DMARC result | Fix domain match |
Header fields worth collecting before changing DNS or IPs.
Fix SPF, DKIM and DMARC domain match
Authentication passing is not enough. O365 cares whether the visible From domain has a trusted connection to the domain that passed SPF or DKIM. For third-party sending, that means each client needs custom DKIM signing for its domain, a return-path setup that passes SPF for the right domain, and a DMARC record that lets you monitor failures.
Use a domain health check to confirm the public records first, then use DMARC monitoring to see which sources pass, fail, and send volume for each client domain over time.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Starter DMARC record for monitoringdns
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100
Do not rely on safelisting
A safe sender entry can help one recipient tenant, but it does not fix failed authentication, weak sender reputation, or risky customer behavior. If several customers need safelisting, treat that as a symptom and keep investigating.
Suped's product fits this part of the workflow by bringing DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, blocklist monitoring, and actionable issue detection into one place. For most teams that manage many client domains, Suped is the best overall DMARC platform because it turns authentication results into specific repair steps instead of leaving you with raw reports.
Check IP reputation, blocklists and content
If only some clients are affected, compare their source IPs. A shared pool can hide the real cause because one weak sender damages the neighborhood for others. If affected clients sit on adjacent IPs or the same shared pool, isolate the senders, check complaint rates, slow down volume, and move clean mail only after the cause is understood.
Also check whether the IP or domain appears on a blocklist or blacklist. Suped's blocklist monitoring keeps this tied to DMARC and source data, so the blocklist signal is evaluated beside authentication and sending volume.
SCL triage bands
Use SCL as a directional signal, then confirm with headers and tenant policy.
Low
0-4
Usually not a broad spam verdict.
Spam
5-6
Review content, reputation, and permission.
High
7-9
Treat as a serious sender-side issue.
Content still matters. O365 can quarantine messages with suspicious URLs, file attachments, urgent wording, mismatched branding, or subjects that look like internal security tests. When the same domain sends clean transactional mail and risky test mail through the same pool, separate those streams.
|
|
|
|---|---|---|
IP | Shared weak pool | Separate sources |
Domain | No domain match | Fix DKIM |
Audience | Weak consent | Suppress risk |
Message | Risky links | Test variants |
Compare these dimensions across affected and unaffected sends.
When only the recipient admin can fix it
A recipient admin fix is required when the customer's tenant applies an anti-spoof, impersonation, transport, or quarantine policy after the message passes normal authentication. This often happens when a company sends mail to itself through an ESP. The message is external, but it uses the company's own domain, branding, and user names.
If the symptom is junk placement rather than quarantine, compare the patterns in Office 365 spam folders. If O365 rejects or blocks during SMTP, use a different path than quarantine triage and review Microsoft domain blocks.
What you can fix
- Authentication: Make SPF, DKIM, and DMARC pass for the client domain.
- Reputation: Separate risky customers and clean up shared IP pools.
- Evidence: Provide headers, source IPs, domains, and a repeatable test.
What they control
- Policy: Tenant quarantine, anti-spoof, anti-phishing, and transport rules.
- Allowing: Tenant allow/block list entries and safe sender settings.
- Release: Message release, submission review, and final mailbox action.
Recipient admin request templatetext
Please review the quarantined sample with these details: Sender domain: client.example Source IP: 203.0.113.10 Authentication: SPF pass, DKIM pass, DMARC pass Observed scores: SCL 1, BCL 2 Request: confirm whether tenant policy caused quarantine.
This wording keeps the request specific. It asks the admin to confirm the rule that acted, instead of asking for a broad safelist with no diagnosis.
Operational fix plan for ESPs
For ESPs, the work is partly technical and partly operational. I would not change every DNS record or rotate every IP at once. I would build a small evidence set, fix the causes that are clearly under sender control, and give recipient admins a precise reason when their tenant policy is the blocker.
- Collect samples: Get five quarantined headers and five successful headers using the same send path.
- Map sources: Group by IP pool, client domain, DKIM selector, envelope sender, and tenant.
- Repair auth: Fix client DKIM, SPF return-path, and DMARC reporting before policy escalation.
- Isolate risk: Move risky customers out of shared pools and suppress poor-quality recipients.
- Retest cleanly: Send matched test messages and compare headers before asking admins to adjust policy.
A live send tells you more than DNS alone. Send a production-path message to the email tester and compare the results with the O365 quarantine headers. DNS can look correct while the real message still signs with the wrong DKIM domain or uses a different return-path.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's product is useful after the first incident because the same root causes repeat: missing client DKIM, SPF lookup limits, shared IP spillover, blocklist hits, and DMARC failures hidden across many domains. Real-time alerts and the MSP dashboard make it easier to catch those patterns before a support queue fills with O365 quarantine reports.
Views from the trenches
Best practices
Compare affected clients by source IP, sender domain, template, and O365 tenant before editing DNS.
Use a Microsoft 365 test tenant to separate shared sender issues from client-specific rules.
Log SCL, BCL, authentication results, and quarantine reason for every failed sample.
Common pitfalls
Treating every quarantine as a Microsoft-wide block hides tenant filters and bad sources.
Safelisting sender domains first leaves SPF, DKIM, and DMARC failures active for future mail.
Mixing weak clients on shared IPs causes one sender's complaints to affect another.
Expert tips
Ask for the original headers after release, not a screenshot of the quarantine list.
If BCL and SCL are low, push the investigation toward tenant policy settings and rules.
Use separate pools for risky senders so one client's reputation does not spill over.
Marketer from Email Geeks says selective O365 quarantine should be checked by affected client and recipient tenant before assuming a global platform issue.
2023-06-28 - Email Geeks
Expert from Email Geeks says source IP proximity matters because a poor sending neighborhood can explain why only some clients see O365 quarantine.
2023-06-28 - Email Geeks
What to fix first
The practical answer is to fix the sender-controlled causes first: domain authentication, source IP grouping, weak customer behavior, risky content, and blocklist or blacklist signals. Then use the headers to prove when the remaining action belongs to the recipient tenant.
If SCL or BCL is high, treat O365 quarantine as a sender reputation or content problem. If those scores are low and authentication passes, take the evidence to the recipient admin and ask them to review their tenant policy. For ESPs, the cleanest long-term fix is consistent per-client DKIM, monitored DMARC, separated IP risk, and repeatable Microsoft 365 test coverage.
Practical order
Fix authentication, segment reputation risk, validate with real test mail, then escalate tenant policy with headers. That order avoids random safelisting and gives each customer a clear next step.
