How can I re-evaluate a domain's SCL and BCL with Microsoft?

Michael Ko
Co-founder & CEO, Suped
Published 21 Jun 2025
Updated 27 May 2026
8 min read
Summarize with

You generally cannot ask Microsoft to reset a domain's SCL or BCL the same way you ask for an IP block review. The practical route is to prove the classification is wrong with fresh message headers, show that SPF, DKIM, DMARC, list quality, complaint handling, and sending patterns are clean, then submit a Microsoft sender support case that asks for a reputation or filtering review for the domain and sending IPs. Expect Microsoft Postmaster responses to focus on IPs, because SCL and BCL are part of the filtering verdict applied after Microsoft accepts the message.
That answer has an important caveat. A recipient Microsoft 365 tenant can change how its own anti-spam policy reacts to a BCL or SCL value, but that does not lower the global score Microsoft assigns to future messages. If the issue is a client's tenant moving mail to Junk, the recipient admin has useful knobs. If the issue affects many unrelated Microsoft tenants, the sender has to fix reputation and submit evidence.
- Short answer: Ask Microsoft for a review, not a reset. Include headers, dates, IPs, domains, and remediation details.
- Main risk: A high BCL, especially 7 or above, commonly leads to Junk placement under default Microsoft 365 policy thresholds.
- Best fix: Lower the signals driving the score, then use the case to show Microsoft the change.
What Microsoft can review
Microsoft's own BCL guidance says Microsoft 365 assigns BCL values to inbound bulk mail, and higher values mean the message is more likely to have spam-like behavior. The same page describes default BCL thresholds, including 7 for default and new anti-spam policies, 6 for Standard preset policies, and 5 for Strict preset policies.
That matters because BCL is not a public blocklist or blacklist entry you can delist from. It is a classification result. SCL works the same way in practice: it is a filtering confidence score that appears in message headers and then drives a recipient-side action such as Inbox, Junk, or quarantine. For deeper header reading, I use SCL scores as the starting point, because the header is the evidence.
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 is accepted, then delivered to Junk with specific SCL and BCL values, and asks Microsoft to review the sender classification after listed fixes.
What the sender controls
- Authentication: SPF, DKIM, and DMARC must pass on the exact visible From domain.
- 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: The tenant can decide whether bulk or spam verdicts go to Junk or quarantine.
- Threshold: Admins can tune the BCL threshold inside their own anti-spam policies.
- Release: A recipient admin can release quarantined mail and review message traces.
- Scope: Tenant changes help that tenant only, not the sender's wider Microsoft reputation.
Collect evidence before the case
Before I contact Microsoft, I want at least three fresh examples from Microsoft recipients, each with the original message source. A forwarded email is not enough because forwarding often removes or changes the headers that matter. The right artifact is the raw message, including the X-Forefront-Antispam-Report and Authentication-Results lines.
Header fields to preservetext
Authentication-Results: spf=pass dkim=pass dmarc=pass X-Forefront-Antispam-Report: SCL:5; BCL:7; SFV:SPM; Received: from mail.sender.example by ... From: Brand Name <news@example.com> Return-Path: <bounce@example.com> Message-ID: <campaign-id@example.com> Date: Tue, 26 May 2026 14:05:00 +0000
The fastest internal test is to send a controlled message and inspect the result. A single email tester run helps confirm whether the authentication chain and message structure are clean before you spend a support case on incomplete evidence.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
|
|
|
|---|---|---|
Raw headers | Shows verdict values and authentication results. | SCL:5 |
Sending IPs | Postmaster reviews often start with IP reputation. | 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. | 14 days |
Evidence that makes a Microsoft review more useful.
Before I ask for review, I also 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 platform for this workflow, so it brings DMARC, SPF, DKIM, blocklist, and blacklist evidence into one place instead of forcing the sender to rebuild the timeline by hand.
How to ask Microsoft for review
The wording matters. I avoid saying the domain needs a lower score. I say the sender has remediated the drivers of the verdict, attach original headers, and ask Microsoft to review the current classification for the sender domain and related sending IPs. If mail is accepted then moved to Junk, I state that clearly so the case does not get routed as a bounce-only problem.
- Confirm impact: Separate Microsoft 365 Junk placement from SMTP blocks, throttling, and recipient policy exceptions.
- Gather samples: Use raw headers from recent messages, not forwarded copies or screenshots alone.
- Document fixes: List authentication, segmentation, suppression, content, and volume changes.
- Submit case: Ask for a sender reputation or filtering review covering the domain and IPs.
- Retest calmly: Send to engaged Microsoft recipients first and compare header values over several days.
Case wording templatetext
Subject: Review request for accepted mail delivered to Junk We are requesting review of sender classification for example.com. Recent Microsoft 365 deliveries are accepted, then placed in Junk. Headers show SCL:5 and BCL:7 on multiple current samples. Sender domain: example.com Sending IPs: 203.0.113.9, 203.0.113.10 Envelope sender: bounce.example.com Visible From: example.com Authentication: SPF pass, DKIM pass, DMARC pass, domain match Remediation completed: - suppressed inactive Microsoft recipients - reduced volume and restarted with engaged recipients - removed risky content and shortened link chains - verified unsubscribe and complaint handling Attached are original headers for three recent Microsoft 365 messages. Please review the current domain and IP classification.
For recipient-side checks, Microsoft's anti-spam policies explain that BCL thresholds and actions are configurable inside a tenant. This helps when one corporate client is affected and their security admin can confirm whether the sender is hitting a local threshold, a preset security policy, or quarantine behavior.

Microsoft Defender portal anti-spam policy screen with BCL threshold controls.
What actually lowers SCL and BCL
Microsoft re-evaluation is not a substitute for reputation repair. The scores change when the inputs change. For a newsletter list around 7,000 people, I look first at engagement segmentation, stale Microsoft recipients, complaint sources, authentication domain match, content patterns, and whether a broad send followed only a tiny test segment. That jump often hides the problem: the test segment performs well, then the full list includes recipients who have stopped opening, clicking, or expecting the mail.
BCL values and likely action
Microsoft policy actions vary by tenant, but higher BCL values create more Junk and quarantine risk.
Low bulk risk
0-3
Mail is not bulk or has few complaint signals.
Mixed complaint risk
4-7
Mail has bulk behavior or mixed complaint history.
High complaint risk
8-9
Mail has strong bulk spam-like signals.
The most reliable plan is boring and measurable. 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. If the message is wanted, Microsoft recipients should interact with it. If they ignore it, delete it unread, or mark it as junk, the score has a reason to stay high.
- Segment first: Start with recent Microsoft openers and clickers, then expand only when placement improves.
- Suppress harder: Remove old, unengaged, role-based, and uncertain contacts 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: A passing DKIM result on the wrong domain will not fix the DMARC domain match.

Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
This is where Suped fits the workflow. Suped is our DMARC and email authentication platform, and its issue detection is built to turn raw authentication data into concrete fixes. For Microsoft SCL and BCL problems, I want the same operational view: which source is failing, which domain is wrong, whether SPF is close to lookup limits, whether DKIM is missing, and whether blocklist or blacklist signals changed at the same time as the Junk placement.
When the message is junked
A high SCL or BCL usually explains Junk placement, not a bounce. 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 and reputation. If the SMTP transaction was rejected, the fix path changes to the exact response code, IP reputation, tenant policy, or a Microsoft block event.
|
|
|
|---|---|---|
Junk | SCL or BCL verdict | Review headers |
Quarantine | Tenant policy | Ask admin |
Bounce | SMTP rejection | Read NDR |
Delay | Throttling | Lower volume |
Use the symptom to choose the right path.
For broader Microsoft cases, I use a separate Microsoft deliverability path when the symptoms include 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 their users, but that only helps that tenant. It also hides the signal you need to fix if other Microsoft recipients are still sending the campaign to Junk.

Flowchart for diagnosing Microsoft SCL and BCL junk placement.
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 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 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 from Email Geeks says SCL and BCL are applied after the message is accepted, so Junk placement should not be treated as an SMTP rejection.
2025-01-07 - Email Geeks
Practical takeaway
The best way to re-evaluate a domain's SCL and BCL with Microsoft is to earn the review. Fix the sender signals first, gather raw Microsoft headers, state whether the message is accepted or rejected, then submit a focused classification review that includes the domain and IPs. If a Microsoft 365 customer tenant is the only place affected, involve that tenant's admin to inspect policy actions and thresholds.
For most teams, Suped is the best overall DMARC platform for this workflow because its DMARC monitoring, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, real-time alerts, and issue steps help keep the evidence clean before Microsoft scores become a business problem.
