How can I re-evaluate a domain's SCL and BCL with Microsoft?
Updated on 11 Oct 2026: We updated our Microsoft SCL and BCL guidance for current filtering behavior and recipient-admin review steps.
There is no sender-facing process that simply resets a domain's SCL or BCL. Microsoft assigns these values to individual messages, rather than publishing a single domain score. Start by tracing whether the filtering verdict came from Microsoft spam filtering or a recipient-tenant override. Then support a suspected false positive with fresh message headers, show that authentication, list quality, complaint handling, and sending patterns are clean, and ask Microsoft to review the affected messages. For Microsoft 365 escalation, involve an affected recipient's admin.
A recipient Microsoft 365 tenant can change how its anti-spam policy handles bulk or spam verdicts, and tenant rules or allow and block entries can change the filtering outcome for that organization. Those policy changes do not lower the sender's wider Microsoft reputation. If one client's tenant moves mail to Junk, its admin should trace the policy and submit a false positive. If many unrelated Microsoft tenants show the same filter verdict, the sender should document sender fixes and provide multi-tenant evidence for an admin-led escalation.
- Short answer: Ask Microsoft to review the evidence, not reset a score. Include headers, dates, IPs, domains, and remediation details.
- Main risk: At default settings, BCL 7 meets all published Microsoft bulk thresholds. Default, new, and Standard policies send bulk mail to Junk, while Strict quarantines it.
- Best fix: Find the component that set the verdict, correct that cause, and use new samples to show the change.
What Microsoft can review
Microsoft's own BCL guidance says Microsoft 365 assigns bulk complaint level (BCL) values to inbound bulk mail, and higher values mean the message is more likely to have spam-like behavior. The default BCL threshold is 7 for default and new anti-spam policies, 6 for Standard preset policies, and 5 for Strict preset policies. The default action at or above the threshold is Junk under default, new, and Standard policies, while Strict quarantines the message.
BCL is not a public blocklist (blacklist) entry that a sender can delist. It is a bulk-mail classification. Spam confidence level (SCL) is a separate message value, but its number alone does not determine the filtering verdict or action in Exchange Online. Read the SCL scores alongside SFV and CAT in the raw header to understand the verdict and its likely source.
Bulk mail below the configured BCL threshold can take another path. Messages identified as bulk receive a Promotions tag, including some messages with BCL 0. When a tenant turns on the "Bulk moves enabled" setting, below-threshold bulk mail moves to the Promotions folder in supported Outlook versions. That setting is off in Standard and Strict preset policies. Promotions placement does not by itself prove that BCL rose or that the sender's wider reputation changed.
Do not frame the request as a score reset
A request that only says the BCL is too high gives Microsoft little to verify. A stronger request says the message was accepted, identifies whether it reached Junk, quarantine, or Promotions, lists the SCL and BCL values, and asks Microsoft to review a suspected false positive after the documented fixes.
What the sender controls
- Authentication: For DMARC to pass, SPF or DKIM must authenticate a domain that matches the visible From domain under DMARC rules.
- Audience: Inactive Microsoft recipients should be suppressed before volume is sent again.
- Evidence: Original headers, timestamps, IPs, envelope sender, and campaign details should be included.
- Cadence: Volume should ramp through engaged Microsoft recipients before broad sends resume.
What the recipient controls
- Policy action: Admins can configure Junk or quarantine actions in default and custom anti-spam policies; preset policies have fixed settings.
- Threshold: Admins can tune the BCL threshold in default and custom anti-spam policies, but cannot edit Standard or Strict preset thresholds.
- Overrides: Mail flow rules, allow and block entries, and user lists can change filtering outcomes within that tenant.
- Scope: Tenant changes help that tenant only, not the sender's wider Microsoft reputation.
Collect evidence before the case
Collect fresh examples from affected Microsoft recipients, ideally across more than one tenant when the impact is widespread, each with the original message source. A forwarded email is not enough because forwarding often removes or changes the headers that matter. Preserve Authentication-Results, X-Forefront-Antispam-Report, X-Microsoft-Antispam, X-MS-Exchange-Organization-SCL, and the network message ID. In Outlook on the web, open the message, select More actions, then View > View message details.
Illustrative header fields to preservetext
Authentication-Results: receiver.example; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com; compauth=pass X-Forefront-Antispam-Report: SCL:6; SFV:SPM; IPV:NLI; CAT:BULK; SRV:BULK; X-Microsoft-Antispam: BCL:7; X-MS-Exchange-Organization-SCL: 6 X-MS-Exchange-Organization-Network-Message-Id: 11111111-2222-3333-4444-555555555555 Received: from mail.sender.example by ... From: Brand Name <news@example.com> Return-Path: <bounce@bounce.example.com> Message-ID: <campaign-id@example.com> Date: Tue, 26 May 2026 14:05:00 +0000
Ask the recipient admin to run a message trace in the Exchange admin center using the sender, recipient, and delivery time. Review the message events alongside the headers and actual folder location; a Delivered status confirms delivery to the destination, not necessarily the Inbox.
Send a controlled message and inspect the result. An email tester run helps check authentication and message structure before opening a case. It does not reproduce the affected tenant's filtering policy or prove Inbox placement.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
|
|
|
|---|---|---|
Raw headers | Shows verdict values and the component that set them. | SCL:6; BCL:7; CAT:BULK |
Network message ID and recipient | Lets the recipient admin submit the message and check the policy applied to that recipient. | GUID from the Microsoft header plus affected mailbox |
Sending IPs | Identifies the sending infrastructure Microsoft evaluated. | 203.0.113.9 |
From domain | Connects the visible brand to the DMARC domain match. | example.com |
List source | Explains consent, age, and suppression quality. | Opt-in |
Fix log | Shows Microsoft that the sender changed behavior. | Dated suppression changes and post-fix samples |
Evidence that makes a Microsoft review more useful.
Before requesting review, check the domain with a domain health check, compare live authentication trends in DMARC monitoring, and look for IP or domain reputation hits with blocklist monitoring. Suped is our DMARC and email authentication platform. Use its authentication reports and blocklist (blacklist) alerts alongside a separate log of message headers and remediation dates. DMARC aggregate reports do not include SCL, BCL, or mailbox folder placement.
Trace the filtering verdict and SCL overrides
Microsoft's anti-spam troubleshooting guidance says to identify the component that filtered the message before changing sender behavior or tenant policy. The outcome can come from spam filtering, a mail flow rule, connection filtering, an allow or block entry, a user's Safe or Blocked Senders list, or a DMARC and anti-spoofing result. A reputation review will not remove a tenant override, so use the header signals to choose the owner and the next action.
|
|
|
|---|---|---|
SFV:SPM and CAT:SPM | Microsoft spam filtering | Submit the fresh message as a false positive after sender fixes. |
SFV:SKS or SFV:SKN | Pre-filter spam or nonspam marking, often a mail flow rule | Inspect transport rules and other overrides; SKN indicates a bypass rather than a spam verdict. |
SFV:SKB or SFV:BLK | Tenant anti-spam blocked sender/domain list (SKB) or user's Blocked Senders list (BLK) | Remove the incorrect block entry in the affected tenant. |
compauth=fail reason=000 and CAT:SPOOF | DMARC failure | Confirm dmarc=fail, then fix the SPF or DKIM domain match that DMARC evaluates. |
SRV:BULK plus BCL | Bulk email detection | Compare the tenant threshold, then correct complaints and list quality. |
Use the header signal to identify the review path.
SCL alone does not explain Junk placement
Microsoft's SCL guidance says that the number alone no longer determines the verdict or action in cloud organizations. Read CAT, SFV, and the applied policy together. Transport rules request a specific SCL value; they do not subtract points from a message's score. Even a requested SCL -1 bypass can be stamped differently after filtering.
How to ask Microsoft for review
The wording and submission route matter. Avoid saying the domain needs a lower score. For a false positive, ask an affected recipient's Microsoft 365 admin to submit the original message through the Defender Submissions page and share the resulting verdict. If the same filter result affects unrelated tenants, provide multi-tenant samples and documented sender fixes for that admin to escalate to Microsoft Support. Microsoft's external sender guidance recommends asking the recipient to open the support ticket. State whether the message was accepted and then moved to Junk or quarantine so the case is routed correctly.
- Confirm impact: Separate Microsoft 365 Junk, quarantine, or Promotions placement from SMTP blocks and throttling.
- Gather samples: Use raw headers from recent messages, not forwarded copies or screenshots alone.
- Trace the source: Use SFV, CAT, compauth, SRV, SCL, and BCL to separate filtering from tenant overrides.
- Document fixes: List authentication, segmentation, suppression, content, and volume changes.
- Submit evidence: Use the recipient admin's false-positive submission, then ask that admin to escalate persistent issues with the multi-tenant evidence.
- Retest calmly: Send to engaged Microsoft recipients first and compare verdicts, header values, and actual placement over several days.
Evidence template for a recipient-admin escalationtext
Subject: Review request for accepted mail delivered to Junk We are requesting review of filtering verdicts for mail from example.com. Recent Microsoft 365 deliveries are accepted, then placed in Junk. Headers show SCL:6, BCL:7, and CAT:BULK on multiple current samples. Sender domain: example.com Sending IPs: 203.0.113.9, 203.0.113.10 Envelope sender domain: bounce.example.com Visible From domain: example.com Authentication: SPF pass, DKIM pass, DMARC pass, domain match Affected recipients and tenants: [list affected mailboxes and tenant domains] Network message IDs and UTC delivery times: [list for each sample] Submission IDs and results: [list previous false-positive submissions] Remediation completed: - suppressed inactive Microsoft recipients - reduced volume and restarted with engaged recipients - removed misleading content and shortened link chains - verified unsubscribe and complaint handling Attached are original message files and headers for three recent Microsoft 365 messages. Please review the filtering verdicts and check for tenant policy overrides.
For recipient-side checks, Microsoft's anti-spam policies explain how BCL thresholds and actions work inside a tenant. This helps when one corporate client is affected and its security admin can confirm whether the message is hitting a local threshold, a preset security policy, quarantine behavior, or an SCL-setting rule. Policy precedence matters because a Standard or Strict preset can apply instead of the custom policy an admin expected.
Microsoft Defender anti-spam policy showing the bulk email BCL threshold and spam actions.
Submit a false positive in Microsoft Defender
The affected tenant's admin needs submission permissions and the original message. Microsoft's submission instructions support Exchange Online messages up to 30 days old that remain available in the mailbox.
- Open Actions & submissions > Submissions in Microsoft Defender, select the Emails tab, and choose Submit to Microsoft for analysis.
- Set the submission type to Email. Upload the original .eml or .msg file, or enter the Microsoft network message ID, and identify an affected recipient.
- For a verified legitimate message, select "I've confirmed it's clean", continue, and submit it for review.
- Save the submission ID and review the result, authentication findings, and policy hits before escalating.
If a completed Spam or Bulk verdict is still incorrect, use Dispute submission result when eligible; each submission can be disputed once. Selecting Allow this message requests a tenant allow entry rather than a domain score reset.
Improve sender signals before re-evaluation
Microsoft re-evaluation is not a substitute for reputation repair when the header points to spam or bulk filtering. Filtering considers sender reputation and message content, alongside authentication, recipient acquisition, complaint rates, and sending patterns. Passing SPF, DKIM, and DMARC does not guarantee Inbox placement or a lower BCL. Check engagement segmentation, stale Microsoft recipients, complaint sources, authentication domain match, content patterns, and whether a broad send followed only a tiny test segment. A small test can perform well while the full list includes recipients who no longer expect the mail.
BCL complaint categories
These categories describe complaint patterns, not guaranteed folder placement. Compare each message's BCL with the recipient's policy threshold.
Low bulk risk
0-3
BCL 0 normally indicates non-bulk mail; values 1-3 identify bulk senders with few complaints. Promotions tagging can also include BCL 0.
Mixed complaint risk
4-7
Mail has bulk behavior and a mixed complaint history.
High complaint risk
8-9
Mail is from a bulk sender that generates many complaints.
Use a measured recovery plan. Pause broad Microsoft sends, keep transactional mail separate, rebuild newsletter volume through recently engaged contacts, and remove contacts that have not engaged in a reasonable period. Repeated junk reports indicate that recipients do not want those messages; use that feedback to correct targeting before increasing volume.
- Segment first: Start with recent clickers and other known-engaged Microsoft recipients, then expand only when placement improves.
- Suppress harder: Remove contacts without verified consent and suppress inactive contacts under your list policy before the next campaign.
- Separate streams: Do not mix invoices, alerts, newsletters, and cold outreach on the same subdomain.
- Reduce friction: Make unsubscribe clear, remove misleading subjects, and avoid heavy link chains.
- Watch authentication: DKIM passing on a nonmatching domain cannot provide a DMARC pass; a matching SPF pass can still satisfy DMARC.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's authentication issue steps turn report data into concrete fixes. Check which sending source is failing, which domain does not match, whether SPF is near the DNS lookup limit, and whether DKIM is missing. Compare those findings with raw Microsoft headers to determine whether the remaining issue is filtering or tenant policy.
Separate Junk placement from SMTP rejection
In Exchange Online, the filtering verdict and applied policy explain Junk or quarantine placement; SCL or BCL alone is not a bounce code. If a recipient says the mail bounced, ask for the non-delivery report first. If the mail reached the mailbox and then landed in Junk, the fix path is filtering, tenant policy, or reputation. If the SMTP transaction was rejected, use the exact response code to investigate IP reputation, tenant policy, or a Microsoft block event.
|
|
|
|---|---|---|
Junk | Spam or bulk verdict, or tenant/user override | Review headers |
Quarantine | Tenant policy | Ask admin |
Bounce | SMTP rejection | Read NDR |
Delay | Temporary delivery failure, including throttling | Read the temporary SMTP response and retry guidance |
Use the symptom to choose the right path.
Use the broader Microsoft deliverability path when the symptoms span B2B customer tenants, admin policy exceptions, or unclear routing through Exchange Online Protection.
Recipient allow rules are a short-term fix
A trusted B2B recipient can create a scoped allow entry or adjust policy for its users, but that only helps that tenant. A mail flow rule requesting SCL -1 does not disable all security checks or guarantee delivery. It can also hide the signal that still needs repair if unrelated Microsoft recipients continue sending the campaign to Junk.
Microsoft SCL and BCL review path: read headers, check scores, fix issues, and submit a review.
Views from the trenches
Best practices
Collect raw Microsoft headers before opening a case; forwarded mail loses needed verdict data.
Separate accepted Junk placement from rejected SMTP traffic before choosing the review path.
Restart sends with engaged Microsoft recipients before asking for wider reputation review.
Common pitfalls
Treating BCL as a blocklist entry leads to weak cases and repeated IP-only responses.
Testing a tiny engaged segment, then sending to the full list, hides reputation risk.
Changing recipient tenant policy can mask the issue without lowering sender reputation.
Expert tips
Attach fresh examples with SCL, BCL, sender IP, From domain, and exact remediation dates.
Ask for classification review after fixes, not a manual score reset without context.
Use complaint and engagement data to decide which Microsoft recipients to suppress first.
Marketer view
Marketer from Email Geeks says Microsoft Postmaster cases usually focus on IP and ASN reputation, so SCL and BCL reviews need accepted-message headers and filtering evidence.
2025-01-07 - Email Geeks
Marketer view
Marketer from Email Geeks distinguishes accepted mail placed in Junk from SMTP rejection, so the delivery symptom should determine the review path.
2025-01-07 - Email Geeks
