Why are my emails marked with a high BCL score and landing in junk folders, and how can I fix it?
Matthew Whittaker
Co-founder & CTO, Suped
Published 27 Apr 2025
Updated 21 May 2026
7 min read
Summarize with
A high BCL score means Microsoft has enough signals to treat your message as bulk mail. If that message lands in junk, the junk decision is coming from Microsoft filtering, the recipient's mailbox or tenant policy, or reputation signals around the sender, content, IP, domain, and recipient reaction. SPF, DKIM, and DMARC passing do not guarantee inbox placement.
The SPF domain-match issue is a separate problem. With Amazon SES, SPF can pass because SES is authorized to send, but the DMARC SPF check can fail when the Return-Path uses an SES domain instead of a domain that matches your visible From domain. Fix that with a custom MAIL FROM domain. Do it, but do not expect it to lower BCL by itself.
- Read the header: BCL is Microsoft's bulk confidence score, not a DMARC authentication result.
- Fix identity: Make SPF, DKIM, and DMARC pass with the right domain matching, especially after sender changes.
- Fix placement: Warm the Microsoft stream, reduce complaint risk, and send mail people asked for.
- Check policy: For Office 365 recipients, the tenant owner can choose what happens at each threshold.
What BCL means in Microsoft filtering
Microsoft Outlook on the web message source showing BCL and authentication headers.
BCL means bulk complaint level or bulk confidence level, depending on the Microsoft context people use when talking about it. Practically, it is the score Microsoft adds when it thinks a message behaves like bulk mail. A lower value means lower bulk confidence. A higher value means stronger bulk confidence.
The important point is that BCL is not the same thing as SCL. BCL is about bulk classification. SCL is about spam confidence. If you need a deeper comparison, the SCL and BCL ratings breakdown is useful. In the case that triggered this page, BCL:4 and BCL:6 were visible in the X-Microsoft-Antispam header, but those numbers alone did not prove that DMARC was broken.
Header sampletext
X-Microsoft-Antispam: BCL:6; Authentication-Results: spf=pass smtp.mailfrom=bounce.example.com; Authentication-Results: dkim=pass header.d=example.com; Authentication-Results: dmarc=pass action=none header.from=example.com;
|
|
|
|---|---|---|
0-1 | Low bulk confidence | Usually filtered by other signals |
4 | Moderate bulk signal | Depends on policy |
6 | Stronger bulk signal | Junk or quarantine in stricter tenants |
7-9 | High bulk confidence | Often treated as unwanted bulk |
BCL values are signals, not universal delivery rules.
Do not treat BCL as the whole verdict
I have seen messages with low BCL still land in junk because the mailbox or sender reputation looked weak. I have also seen BCL values pass through to inboxes when the tenant's policy allows it. BCL is one input. It is not the entire Microsoft filtering decision.
Why SPF can pass but fail the DMARC domain match
SPF has two different jobs in this problem. First, it checks whether the sending service is allowed to send for the envelope sender domain. Second, DMARC checks whether that envelope sender domain matches the visible From domain closely enough. That second check is the SPF domain match.
With Amazon SES, the common failure looks like this: SES sends the message with a Return-Path under an SES-controlled domain, so SPF authentication passes, but the DMARC SPF domain match fails because the visible From domain is your domain. If DKIM passes with your domain in the DKIM d= value, DMARC can still pass through DKIM. If DKIM is missing or uses the wrong domain, DMARC fails.
SPF pass with domain mismatchtext
From: billing@example.com Return-Path: 01000190abcd@amazonses.com SPF result: pass DMARC SPF domain match: fail DKIM result: pass, d=example.com DMARC result: pass through DKIM
The fix is a custom MAIL FROM domain, often a bounce subdomain such as bounce.example.com. After that, the Return-Path uses your domain, SPF passes on that domain, and the DMARC SPF domain match passes in relaxed mode. I also check the final record with the SPF checker because small DNS mistakes can make the whole change look correct while it still fails at receivers.
Custom MAIL FROM DNS patterndns
bounce.example.com. MX 10 feedback-smtp.us-east-1.amazonses.com. bounce.example.com. TXT "v=spf1 include:amazonses.com -all"
This fixes identity, not bulk classification
A custom MAIL FROM domain is worth doing because it cleans up the DMARC SPF domain match and bounce identity. It does not, by itself, make Microsoft view the mail as wanted. BCL improves when the sending pattern, audience quality, and reputation signals improve.
How to fix high BCL and junk placement
I fix this in two tracks. One track proves that the sender is technically legitimate. The other track proves that the mail is wanted by Microsoft recipients. If you only work on DNS, you can end up with perfect authentication and the same junk placement.
Identity fixes
- MAIL FROM: Use a custom return path under your domain for Amazon SES.
- DKIM domain: Sign with the same organizational domain as the visible From domain.
- DMARC record: Publish reporting first, then increase policy after real pass rates hold.
- SPF limit: Keep SPF under the 10 DNS lookup limit and remove unused senders.
Placement fixes
- Warmup: Increase Microsoft volume slowly, especially after source or template changes.
- Audience: Send first to recipients who recently opened, clicked, logged in, or bought.
- Complaints: Suppress complainers, stale addresses, role accounts, and unknown sources.
- Content: Remove misleading subject lines, URL clutter, and mixed-purpose templates.
The fastest first test is to send a real copy of the message, not a simplified test, then inspect headers, authentication, and rendering in one place. Use the email tester for that first pass, then compare the result with what Microsoft shows in the received header.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
- Capture headers: Save X-Microsoft-Antispam, Authentication-Results, and the Return-Path.
- Separate issues: Treat SPF domain matching, DKIM signing, DMARC policy, BCL, and SCL as separate signals.
- Fix DNS: Use custom MAIL FROM, correct DKIM signing, and one valid SPF record.
- Reduce risk: Pause cold segments and restart with the most engaged Microsoft recipients.
- Watch policy: If only one company is affected, ask its Office 365 admin to check tenant rules.
- Measure trend: Track Microsoft placement separately instead of averaging it with all mailbox providers.
How I diagnose Microsoft junk placement
BCL triage bands
Use BCL as a triage clue, then confirm the actual cause with headers, authentication, recipient policy, and engagement.
Low
0-1
Bulk signal is low. Look at SCL, tenant policy, content, and mailbox reputation.
Moderate
2-4
Bulk signal is present. Segment Microsoft mail and check recent changes.
High
5-6
Bulk signal is strong. Slow volume and improve audience quality before scaling.
Severe
7-9
Bulk signal is very strong. Stop broad sends and rebuild reputation deliberately.
The pattern matters more than one header. If BCL jumped after a new template, new link domain, new IP pool, changed bounce domain, or a list import, I roll that change back or isolate it. If BCL is steady but junk placement increased, I look at SCL, tenant filtering, complaint rates, and audience decay.
Flowchart for diagnosing Microsoft junk placement by checking headers and warming mail slowly.
|
|
|
|---|---|---|
SPF pass, domain mismatch | Return-Path mismatch | Set custom MAIL FROM |
BCL 4, junk | Policy or reputation | Check tenant and warmup |
BCL 0, junk | Other filter signal | Review SCL and content |
Only one tenant affected | Admin policy | Ask admin to review rules |
Common patterns and the next action I take.
I also keep a separate view for Microsoft recipients. Microsoft can react differently from Gmail and corporate gateways, so a blended deliverability average hides the problem. If you need a broader Microsoft checklist, the Outlook junk placement guide covers the adjacent SCL path.
Where Suped fits
Suped's product is useful here because it keeps the authentication side honest while you work on Microsoft reputation. I do not treat BCL as a DMARC error, but I do want DMARC data showing whether Amazon SES, DKIM selectors, SPF records, and reporting are behaving as expected.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For most teams, Suped is the best overall DMARC platform for this workflow because it turns raw authentication reports into detected issues, alerts, and specific fix steps. Suped brings together DMARC monitoring, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, DKIM diagnostics, MSP dashboards, and blocklist monitoring in one place. Blocklist (blacklist) checks are not a BCL decoder, but a new domain or IP listing can explain sudden filtering pressure.
What Suped will and will not fix
- Will detect: Broken DMARC, SPF lookup problems, missing DKIM, and source changes.
- Will guide: Teams through DNS fixes, policy staging, and sender verification.
- Will alert: When failures spike or a sending source starts failing authentication.
- Will not claim: That a DNS change alone forces Microsoft to lower BCL.
Views from the trenches
Best practices
Separate BCL, SCL, SPF domain matching, and DMARC results before choosing the fix path.
Use custom MAIL FROM for Amazon SES so bounce identity matches the visible domain.
Warm Microsoft recipients after source, IP, template, or audience changes are made.
Keep Microsoft placement metrics separate so blended reports do not hide junking.
Common pitfalls
Treating BCL as a DMARC failure wastes time and leaves reputation work untouched.
Changing the Return-Path helps SPF domain matching, but it does not reset Microsoft trust.
Testing only new inboxes gives noisy results because new recipients lack history.
Trying to decode opaque Microsoft headers rarely beats tracking clear placement data.
Expert tips
Start with the most engaged Microsoft users and rebuild volume in controlled steps.
Keep a header archive so BCL, SCL, Return-Path, and DKIM changes can be compared.
Ask affected Office 365 admins about tenant rules when only one company sees junk.
Check blocklist and blacklist status when Microsoft filtering changes suddenly or BCL shifts.
Expert from Email Geeks says BCL is separate from DMARC domain matching, so the first step is to stop treating the two signals as one failure.
2021-07-15 - Email Geeks
Expert from Email Geeks says BCL values show Microsoft's bulk confidence, and Office 365 tenants can choose their own handling threshold.
2021-07-15 - Email Geeks
The practical fix
The fix is not one DNS record. Set the custom MAIL FROM domain so SPF domain matching is clean, make sure DKIM signs with your domain, keep DMARC reporting active, and then work on Microsoft-specific reputation. That means controlled volume, engaged recipients first, cleaner templates, fewer risky links, and fast suppression of stale or complaining recipients.
If BCL:4 or BCL:6 is landing in junk across many Microsoft mailboxes, treat it as a reputation and recipient-quality problem after authentication is correct. If it happens only at one company, treat tenant policy as a real suspect. Either way, the answer starts with headers, not guesswork.
