How to resolve Office 365 SCL rating issues for corporate email from Google Workspace?
Michael Ko
Co-founder & CEO, Suped
Published 10 May 2025
Updated 26 May 2026
11 min read
Summarize with
To resolve Office 365 SCL rating issues for corporate email sent with Google Workspace, start by proving that the mail is authenticated, wanted, and separated from any risky marketing or third-party streams. Then collect full headers from Microsoft 365 recipients, confirm whether the message is getting SCL 9, and submit the case through Microsoft's sender portal or through the receiving tenant's Microsoft support contract. There is no private shortcut that reliably bypasses this evidence work.
I treat this as a filtering investigation, not a Google Workspace outage. Microsoft 365 can assign a high Spam Confidence Level even when SPF, DKIM, and DMARC pass, because SCL also reflects content, sender reputation, recipient tenant policy, complaint signals, previous behavior, and Microsoft Defender detections.
Confirm the symptom: Get headers from affected Microsoft 365 recipients and record the SCL value, delivery action, recipient tenant, sender address, and exact send time.
Prove authentication: Check SPF, DKIM, DMARC, visible From domain matching, and Google Workspace DKIM signing before asking Microsoft to review anything.
Separate mail streams: Keep corporate one-to-one mail away from marketing, transactional, support, affiliate, and sales automation traffic.
Escalate with evidence: Use the Microsoft sender portal first, then ask a receiving Microsoft 365 tenant with a strong support contract to open a ticket if business mail is being quarantined or junked.
What an SCL 9 means in Microsoft 365
SCL is Microsoft's spam confidence score. An SCL 9 result means Microsoft classified the message as high confidence spam. For a corporate Google Workspace sender, the common mistake is assuming that a clean Google setup guarantees clean Microsoft inboxing. It does not. Authentication is required evidence, but Microsoft still decides placement using its own filtering and tenant controls.
If you need the baseline terminology first, read SCL and BCL basics. The key point for this case is simple: SCL is a message-level judgement, not a pure DNS result.
Signal
Meaning
Why it matters
SCL 9
High spam
Explains junk or quarantine
BCL
Bulk score
Shows marketing pressure
Auth
SPF and DKIM
Proves source legitimacy
Policy
Tenant rule
Can override inboxing
Compact Microsoft 365 signals to capture before remediation.
A sudden SCL 9 spike usually comes from one of four places: a sender reputation hit, a compromised account, content that looks risky to Microsoft, or reputation bleed between corporate and bulk mail. The fourth one is common when a domain uses Google Workspace for people, then sends marketing, support, transactional, and sales mail under closely related subdomains without strict separation.
Microsoft Defender portal message details showing SCL 9 for an authenticated inbound email.
Fast triage before contacting Microsoft
Before opening a Microsoft case, I build a packet that makes the issue easy to understand. Microsoft support and filtering teams are not helped by "our client is important" or "nothing changed." They need headers, recipient evidence, repeatable test results, and a reason to believe the sender is not causing the signal.
Run a real inbox test using the same Google Workspace sender, the same signature, and the same kind of message that failed. A stripped-down test message proves less than people think. If the normal mail has calendar links, attachments, disclaimers, tracking URLs, or a CRM signature block, test that normal mail.
Collect headers: Save headers from at least five affected Microsoft 365 recipients and two unaffected recipients if you have them.
Compare recipients: Separate failures caused by Microsoft global filtering from failures caused by a single tenant's transport rules or quarantine policy.
Check people risk: Review recent Google Workspace logins, OAuth grants, forwarding rules, mailbox delegates, and unusual sending volume.
Freeze bulk sends: Pause cold outreach, affiliate activity, scraped-list campaigns, and aggressive marketing while the corporate stream recovers.
Record examples: Keep exact timestamps, subject lines, sender addresses, recipient domains, SCL values, and final delivery actions.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
The goal is not to prove that Google Workspace is perfect. The goal is to prove what Microsoft saw. If the same message passes authentication, lands in Gmail, and still gets SCL 9 at multiple Microsoft 365 tenants, you have a clean problem statement.
Do not chase a private shortcut first
Microsoft does not provide a dependable out-of-band path for a sender to override filtering because a sender asks for it. The workable path is evidence, standard intake, and recipient-side support when the receiving organization has a contract that can raise the issue.
Use evidence: Full headers and repeatable recipient examples get further than business impact statements alone.
Use intake: Microsoft's sender portal is still the normal front door, even when the issue is filtering rather than a hard IP block.
Use recipients: A receiving Microsoft 365 tenant can open a stronger ticket because their users are not receiving wanted mail.
Prove Google Workspace authentication first
The authentication baseline has to be clean before you ask Microsoft to reconsider anything. For Google Workspace, that means SPF includes Google's sender infrastructure, DKIM is enabled with a current key, DMARC exists at the organizational domain, and the visible From domain has a valid DMARC pass path through SPF or DKIM.
Use a domain health check for the sending domain, then keep ongoing DMARC monitoring active while you make changes. One-time DNS checks help, but SCL cases need timelines: what source sent the mail, what authenticated, and when the failures started.
I do not jump straight to p=reject when Microsoft is already assigning SCL 9. First I want the reporting data to prove every legitimate stream. Then I move through policy staging once the sources are identified and the risky streams have their own subdomains.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product is the best overall DMARC platform for most teams working through this because it brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring, and real-time alerts into one workflow. That matters in an SCL case because the sender needs a clear history of sources, authentication results, DNS changes, and new failures.
Google SPF: Keep the record under lookup limits and avoid stacking old vendors into the organizational domain.
Google DKIM: Use a current selector and confirm Microsoft sees a DKIM pass in the received headers.
DMARC domain match: Confirm the visible From domain passes DMARC through either SPF or DKIM, not only a hidden bounce domain.
Subdomain policy: Set separate policies for corporate, marketing, transactional, and support mail instead of treating them as one sender.
Separate corporate mail from risky streams
When corporate Google Workspace mail gets SCL 9, I look hard at reputation bleed. A company can say corporate mail is clean and still have Microsoft reacting to related-domain behavior: marketing complaints, affiliate traffic, cold sales sequences, support mail with risky attachments, or transactional mail sent through vendors that share the same parent domain identity.
This is where subdomain segmentation matters. The corporate stream should be boring: human users, expected message volume, clean signatures, no tracking-heavy templates, and no bulk behavior. Bulk and automated streams should have their own subdomains, their own authentication, and their own monitoring.
Mixed sender identity
Corporate risk: People mail shares reputation with campaigns and automations.
Harder proof: DMARC reports show many senders under one domain.
Noisy fixes: A bad campaign can make clean mail harder to defend.
Separated sender identity
Corporate proof: Google Workspace mail has its own source pattern.
Cleaner reports: Each stream has its own DNS and DMARC data.
Faster recovery: You can pause one source without breaking everything.
Also check blocklist and blacklist status for the sending domains and related IPs, even when Google Workspace is the visible sender. A blocklist (blacklist) listing is not the same as SCL 9, but it is still evidence that Microsoft support and recipient administrators can understand. Use blocklist monitoring to watch changes during the recovery period.
Flowchart showing Google Workspace corporate mail separated from marketing and transactional streams before Microsoft review.
When to contact Microsoft
Contact Microsoft after the evidence packet is ready, not before. The normal sender-side intake is Microsoft's sender portal at sender.office.com. That portal is framed around blocked IPs and bounce evidence, so it does not perfectly fit junk-folder placement caused by SCL 9. It is still the normal sender-side front door.
If a specific Microsoft 365 customer is missing important mail, ask that receiving organization to open a support ticket from its tenant. A recipient-side ticket has a stronger framing: their users are not receiving wanted business email. A sender asking to be trusted has a weaker position.
This is a known pain point for Google Workspace senders into Microsoft 365. Public examples such as a Microsoft Answers thread and community SCL 9 reports show the same pattern: authentication can be correct and Microsoft can still filter the mail.
Start sender-side: Submit through Microsoft's sender portal with headers, timestamps, sending IPs, and affected recipient domains.
Add recipient-side: Ask an affected Microsoft 365 recipient with paid support to open a tenant support case.
Mention scope: State whether the issue affects one tenant, many Microsoft 365 tenants, or all Microsoft-hosted recipients tested.
Ask for review: Ask Microsoft to review the filtering verdict for authenticated business mail, not to whitelist the domain blindly.
What to include in the ticket
A useful ticket has raw headers, message IDs, SCL values, recipient domains, send times with timezone, authentication results, Google Workspace sending account, sending IP, message samples, and a short note describing whether bulk traffic has been paused.
If corporate Google Workspace mail is genuinely clean, authenticated, and wanted, the fix becomes reputation hygiene and isolation. Microsoft filtering is data-driven. The strongest response is to remove every mixed signal that makes corporate mail look connected to bulk or risky behavior.
I start with the domain tree. The organizational domain should carry identity and policy. Corporate mail should use the main domain or a clearly controlled subdomain. Marketing, sales automation, transactional mail, support systems, and partner mail should each have their own subdomain and authenticated source map.
Pause questionable traffic: Stop cold outbound, affiliate mail, old-list campaigns, and high-complaint segments until the SCL pattern changes.
Audit Google accounts: Look for compromised users, new OAuth grants, mailbox forwarding, unexpected delegates, and suspicious API access.
Simplify content: Test plain business mail, then add signature blocks, calendar links, attachments, and tracked links one at a time.
Stage DMARC policy: Move known-good streams toward quarantine or reject after reporting confirms legitimate senders.
Track Microsoft only: Measure Microsoft 365 separately because success at Gmail does not prove success at Outlook or Exchange Online Protection.
For new Google Workspace tenants, time can be part of recovery because Microsoft has limited prior signal for the domain and source pattern. For an established company, I do not rely on waiting. I look for the event that changed Microsoft's view: a spike in complaints, a new sales tool, a compromised mailbox, a vendor DNS change, or a domain relationship that pulled corporate mail into the same reputation group as bulk mail.
Views from the trenches
Best practices
Collect raw headers and recipient examples before asking Microsoft to review filtering.
Segment corporate, marketing, support, and transactional mail into distinct sources.
Use recipient-side support when a Microsoft 365 tenant is missing wanted business mail.
Common pitfalls
Assuming SPF, DKIM, and DMARC passes are enough to override Microsoft SCL scoring.
Blending human mail with bulk sends, then arguing the corporate stream is clean.
Escalating through personal contacts before the standard intake path has evidence.
Expert tips
Treat SCL 9 as a data problem first, then request a formal Microsoft filtering review.
Audit compromised accounts because one mailbox can damage otherwise clean sending.
Pause risky campaigns during recovery so new negative signals do not keep arriving.
Expert from Email Geeks says the sender should first rule out incomplete authentication and undisclosed cold or affiliate traffic before asking Microsoft for help.
2024-10-17 - Email Geeks
Expert from Email Geeks says Microsoft generally has no private deliverability shortcut, so teams need to work backward from headers and filtering data.
2024-10-17 - Email Geeks
The practical path back to inbox
The direct fix is a disciplined sequence: prove the SCL 9 verdict with headers, verify Google Workspace authentication, audit people and sending behavior, separate corporate mail from bulk streams, pause risky mail, then submit the evidence through Microsoft intake and recipient-side support where available.
Suped's product fits the operational part of that sequence: DMARC visibility, SPF and DKIM monitoring, hosted SPF, hosted DMARC policy staging, hosted MTA-STS, blocklist and blacklist monitoring, real-time alerts, and multi-tenant reporting for agencies or MSPs. The reason it works well here is practical: it gives the sender a clean record of what changed and what passed, which is exactly what an SCL remediation case needs.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
