How to troubleshoot Office 365 SCL varying issues when deliverability is fine elsewhere?
Published 7 Jul 2025
Updated 4 Oct 2026
13 min read
Summarize with
Updated on 4 Oct 2026: We updated this guide for Microsoft's current SCL guidance, recipient policy precedence, and false-positive submissions.
If Office 365 SCL varies between SCL=5 and SCL=9 while Gmail, Yahoo, and other destinations look clean, start with Microsoft's filtering and recipient tenant policy. Successful delivery elsewhere does not rule out sender authentication or reputation problems. Build evidence around Microsoft headers, verify SPF, DKIM, and DMARC for the affected stream, then isolate whether recipient policy, message content, URL reputation, or Microsoft's view of the sender caused the variance.
Microsoft can score the same stream differently across tenants, recipients, and time. A clean complaint rate elsewhere helps, but it does not override Microsoft's view of the sender. Collect original Microsoft headers from both good and bad placements, run controlled message tests, and keep the sender stable while changing one variable at a time.
The short answer
An SCL swing from 5 to 9 is a reason to investigate, but the score alone does not establish a spam or high confidence spam verdict in Microsoft 365 cloud mailboxes. Check CAT, SFV, and the actual delivery action. Preserve evidence first, then test content, recipient tenant policy, and Microsoft-specific sender reputation.
Read SCL alongside the filtering verdict
SCL means Spam Confidence Level. Microsoft's current guidance says cloud filtering uses message categories and other signals to determine the verdict and delivery action. A mail flow rule can request spam handling with SCL=5 or SCL=6, or high confidence spam handling with SCL=9. Read the stamped score alongside CAT, SFV, directionality, and the policy applied to the recipient.
SCL values in context
These values help investigate rule requests and historical scoring. Confirm the cloud filtering category and delivery action separately.
SCL -1
Bypass request
A request to bypass most spam filtering; confirm the rule or override.
SCL 0-1
Check verdict
Often seen on nonspam or bypassed messages; check CAT and SFV.
SCL 5-6
Spam request
A mail flow rule can use these values to request spam handling.
SCL 9
Check category
A rule can request high confidence spam handling; the score alone does not identify the detected category.
This is why a single seed inbox is weak evidence. The same sender can hit one tenant's Junk folder and another tenant's inbox because Microsoft combines message signals with tenant policy, overrides, and user history.
|
|
|
|---|---|---|
CAT:SPM | Spam category | Spam policy action |
CAT:HSPM | High confidence spam category | High confidence spam policy action |
CAT:HPHSH or CAT:HPHISH | High confidence phishing category | Detection reason and false-positive submission |
BCL at or above threshold | Bulk filtering when enabled | BCL policy threshold and SRV:BULK |
SFV value | Filtering or override source | Rule, list, or filter |
A compact map of Microsoft filtering signals.
BCL means Bulk Complaint Level and is separate from SCL. A higher BCL indicates bulk mail that is more likely to generate complaints. With bulk filtering enabled, a value at or above the recipient policy's threshold triggers bulk handling. The original default threshold is 7, Standard uses 6, and Strict uses 5; custom and default policy settings are editable. Compare the stamped BCL with the policy applied to the affected recipient before changing content or infrastructure.
Build the evidence set first
Changing DNS, rotating IPs, rewriting templates, and opening a ticket at the same time destroys the comparison. Start with two matched samples: one Microsoft message with bad placement and one with normal placement, as close together as possible. Keep the sender IP, envelope sender, visible From domain, DKIM domain, template, and recipient type the same.
- Collect original message headers and preserve the full .eml or .msg file from the recipient mailbox or quarantine, including the body and links.
- Compare a bad Microsoft sample with a good Microsoft sample before comparing other mailbox providers.
- Keep the IP, domain, DKIM selector, subject pattern, and template stable during testing.
- Record the timestamp with its time zone, recipient tenant, original and latest delivery location, quarantine reason, network message ID, and any admin override.
Illustrative Microsoft headers for an ASF-triggered verdicttext
Authentication-Results: spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com; compauth=pass reason=100 X-Microsoft-Antispam: BCL:0; X-Forefront-Antispam-Report: CIP:203.0.113.10; SCL:9; SFV:SPM; CAT:HSPM; DIR:INB; X-CustomSpam: Web bug X-MS-Exchange-Organization-SCL: 9 X-MS-Exchange-Organization-MessageDirectionality: Incoming
Read CAT and SFV alongside SCL, then compare BCL with the applicable policy. Preserve CIP (connecting IP), IPV (IP verdict), DIR (directionality), SRV:BULK when present, and Authentication-Results. X-CustomSpam identifies a triggered Advanced Spam Filter (ASF) setting. Composite authentication (compauth) is Microsoft's authentication assessment and does not guarantee inbox placement. For a closer read of those fields, use the Microsoft header guide.
For a sender-side baseline, send a real message to Suped's email tester and compare its authentication, headers, and content findings with the Microsoft sample. The tester will not reproduce every Microsoft tenant decision, but it catches sender and message problems before a Microsoft ticket.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Separate sender problems from Microsoft problems
When other destinations are fine, re-check the sender fundamentals. SPF can pass for the envelope sender (Return-Path) without that domain matching the visible From domain. DKIM failures can follow message changes or an unavailable selector's public key; changing selectors alone does not cause failure. DMARC passes when at least one passing SPF or DKIM result has a domain that matches the visible From domain under the published matching mode. Forwarding often breaks SPF, so check whether DKIM survives the route.
Sender-side evidence
- Check SPF, DKIM, DMARC, and composite authentication for the actual Microsoft sample, including the domains used in each result.
- Sending IPs and domains are not on a relevant blocklist or blacklist.
- The same domain, selector, envelope sender, and link hosts appear in each test.
- The sending IP has a valid reverse DNS (PTR) record, and the SMTP HELO/EHLO uses a consistent, valid hostname.
Microsoft-side evidence
- SCL, BCL, SFV, CAT, CIP, or X-CustomSpam differs between matched samples.
- One recipient tenant quarantines while another sends the same mail to Junk or the inbox.
- A mail flow rule, policy, sender list, or user list changes the verdict for the affected recipient.
Suped, our DMARC reporting and email authentication platform, helps identify sending sources and investigate SPF, DKIM, and DMARC failures before a Microsoft escalation. Aggregate reports summarize authentication results; they do not show an individual Microsoft mailbox's SCL or final delivery folder.
Start with a broad domain health check if you need a fast DNS sanity check. Then use Suped's DMARC monitoring to identify sending sources for the domain, and blocklist monitoring (blacklist monitoring) to watch public IP and domain listings. A clean public blocklist check does not establish a good Microsoft sender reputation.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Test message content and mail routing
When the basics are clean, test content and routing as separate variables. Start with the smallest safe changes: remove a tracking link, swap a link host, send text-only, reduce footer density, remove user-generated text, or test a plain transactional template. If the filtering verdict or delivery action changes, restore the last version and change only one part again.
Office 365 SCL troubleshooting flowchart covering headers, authentication, reputation, content, tenant policies, and support.
- Test link domains, tracking redirects, unsubscribe hosts, and image hosts independently.
- Compare full HTML, simplified HTML, and plain text for the same transactional event.
- Ask affected customers to check quarantine, sender lists, transport rules, and Defender policy.
- Check whether mail is relayed, forwarded, rewritten, or scanned before Microsoft receives it.
If inbound mail passes through a gateway, compare the Received headers with CIP. Ask the recipient admin to check Enhanced Filtering for Connectors (skip listing), which preserves the original source IP for filtering. For forwarding that changes authentication results, inspect Authenticated Received Chain (ARC) evidence and whether the intermediary is a trusted ARC sealer.
For transactional mail, do not put the main delivery warning inside the email. If Microsoft is already sending that email to Junk or quarantine, the warning arrives too late. Put the instruction on the website or app screen immediately after the user triggers the email: check Junk if it does not arrive, mark it as not junk, and contact the recipient's IT team if it is quarantined or missing.
Useful recipient instruction
If your organization uses Office 365 and the expected email is not in your inbox, check Junk Email and mark the message as not junk. If the message is not visible, ask your IT team to check quarantine for the sender address and sending domain.
Trace the filtering source before escalating
Spam filtering, ASF settings, mail flow rules, connection filtering, and sender lists can change how a message is handled. Read SFV and CAT, then check IPV, X-CustomSpam, and composite authentication. Use detailed message trace to confirm which transport rule ran. That sequence separates a Microsoft filtering false positive from a recipient configuration issue.
|
|
|
|---|---|---|
SFV:SPM, no X-CustomSpam | Spam content filter | Policy action and false-positive submission |
SFV:SPM with X-CustomSpam | ASF setting | Named ASF condition |
SFV:SKN | Mail flow rule bypass | Rule conditions and priority |
SFV:SKS | Mail flow rule or hybrid spam decision | SCL-setting rules and on-premises verdict |
SFV:SKI or IPV:CAL | Connection filter IP Allow List | IP Allow List entry |
SFV:SKA, SKB, SFE, or BLK | Tenant or user list | Sender lists and Junk Email settings |
compauth=fail or CAT:SPOOF | Authentication or spoofing | Domain matching, forwarding path, and spoof intelligence |
Use header evidence to locate the filtering decision or override.
If X-CustomSpam says 'Web bug', check the applied policy's ASF setting for tracking pixels before rewriting the entire template. ASF headers are added after mail flow rules run, so a transport rule cannot act on a newly added X-CustomSpam value during that processing pass.
Ask the recipient admin to use message trace in the Exchange admin center, and the Defender email entity view when available, to check the override source, applied policy, and delivery action. Check sender, domain, URL, and file entries in the Tenant Allow/Block List; check IP entries separately in the connection filter policy. If no organization setting caused the verdict, submit the confirmed false positive and retain the submission ID.
Avoid permanent bypass rules
A broad SCL -1 rule or permanent IP allow entry hides the root cause and weakens filtering. Use the admin submission workflow for a confirmed false positive. If business impact requires an allow entry, keep it temporary, narrowly scoped, documented, and scheduled for review.
Check anti-spam policy precedence for each recipient
Two recipients in the same Microsoft 365 tenant can have different anti-spam policies. Only the first matching policy of that type applies; its settings are not combined with lower priority policies. Check recipient scope before changing the default policy.
|
|
|---|---|
1 | Strict preset security policy, when enabled and applicable |
2 | Standard preset security policy, when enabled and applicable |
3 | Custom anti-spam policies, lowest priority number first (0 is highest) |
4 | Default anti-spam policy for remaining recipients |
Anti-spam policy order, highest priority first.
- Compare each recipient's user, group, and domain assignments and exclusions in preset and custom policies.
- Record the effective BCL threshold, spam action, high confidence spam action, ASF settings, and quarantine policy.
For example, Standard sends spam to Junk, while Strict quarantines it. Changing a custom policy does not affect a recipient covered by Strict or Standard. Allow up to one hour for anti-spam policy changes to take effect, then repeat the matched test.
Escalate with Microsoft the right way
After the headers show no recipient override or correctable sender issue, ask the recipient admin to submit the message through the Microsoft Defender portal's Actions & submissions > Submissions > Emails workflow. Supply the network message ID or upload the original .eml or .msg file, select an affected recipient for the policy check, and choose 'I've confirmed it's clean' for a verified false positive. Preserve the submission ID and verdict. If the problem continues, ask the recipient tenant to open a Microsoft 365 support case on the sender's behalf.
Microsoft Defender message details showing SCL, authentication results, and delivery action.
Confirm that the destination is a Microsoft 365 business tenant. Personal Outlook.com and Hotmail accounts use a different sender support process. If Microsoft rejects the message during SMTP delivery, preserve the non-delivery report (NDR) and follow its error-specific instructions; IP delisting for a blocked sending IP does not resolve a message already accepted into Junk.
A ticket that only says deliverability is fine elsewhere is weak. Include original headers, affected recipients, sender IPs, timestamps, network message IDs, SCL and BCL values, quarantine examples, the applied recipient policy, and controlled test results. This Microsoft Q&A discussion reports identical messages receiving SCL 1 and SCL 5 for different recipients, but does not establish the cause.
What to include in the ticket
- Attach the original .eml or .msg files, including headers, for at least two affected messages and one normal Microsoft delivery.
- List recipient tenants, timestamps, network message IDs, sending IPs, and delivery actions.
- Include authentication domain matching, complaint data, and blocklist or blacklist status.
- Add controlled test results, applied policy details, and the Microsoft submission ID when available.
Changes to make before a long escalation
If the issue is hurting transactional mail, make pragmatic changes while the ticket runs. Keep the core sender identity stable, but reduce avoidable risk. Keep an established transactional subdomain stable, sign every message with DKIM that matches the visible From domain, avoid shared tracking domains when practical, and make sure the envelope sender domain has a clean SPF path. Treat a move to a new subdomain as a planned migration, not an immediate fix for a high SCL.
|
|
|
|---|---|---|
Identity | Stable domain | Mixed signals |
DKIM | Matching signing | Authentication drift |
Links | Stable hosts | URL risk |
UX | App notice | Lost mail |
Practical changes that preserve test clarity.
Use Suped's authentication reports to confirm which sending source needs a DNS or signing correction, then compare new Microsoft samples after that correction. Authentication fixes support the investigation; they do not guarantee a lower SCL or inbox placement.
Views from the trenches
Best practices
Collect original Microsoft headers and compare matched good and bad deliveries side by side.
Test one variable at a time, especially links, wording, DKIM match, and sending IP.
Use the app or website confirmation page to tell waiting users where to check mail first.
Common pitfalls
Treating Gmail complaint data as proof Microsoft will assign the same message score too.
Adding warning banners inside the email, then assuming Microsoft will read that as trust context.
Chasing private contacts before building a ticket with headers, IPs, samples, and dates.
Expert tips
If SCL changes on identical mail, check recipient tenant policy and message headers first.
For transactional mail, move the user instruction outside the email into the product flow.
Keep a stable sender identity so Microsoft sees consistent domain and IP behavior over time.
Expert view
Expert from Email Geeks says Microsoft delivery help usually has to go through a logged ticketing process, so private contacts rarely change the outcome.
2024-01-19 - Email Geeks
Marketer view
Marketer from Email Geeks says SCL can change even when IP address and content stay the same, which makes matched header samples more useful than assumptions.
2024-01-19 - Email Geeks
Keep authentication monitoring in place
For transactional mail, protect the user journey while the investigation runs. Add clear post-action guidance in the app, keep sender identity stable, and monitor authentication continuously. Use Suped's DMARC reports to compare sending sources before and after a correction, then use recipient-side Microsoft evidence to verify delivery.
