Forum Discussion
Google Workspace sender stuck at SCL=5 to all Microsoft-hosted recipients
Sending email from a new domain via Google Workspace. All mail to Microsoft-hosted recipients (both Outlook.com consumer accounts and Microsoft 365 Exchange Online tenants) is being routed to junk. Authentication passes perfectly on every message. This appears to be a domain reputation cold-start issue and I am looking for guidance on how to resolve it without waiting 2-4 weeks. Affected recipients are all Microsoft-hosted recipients tested (Outlook.com consumer + Microsoft 365 Exchange Online tenants). Please help me!!!
Confirmed via X-MS-Exchange-Organization-SCL: 5 and delivery header dest:J;OFR:SpamFilterAuthJ;RF:JunkEmail on all test emails including ones with normal subject lines and body text. Content makes zero difference to the score.
What has already been done:
- SPF hardened from ~all to -all
- DMARC upgraded from p=none to p=quarantine
- IP confirmed not listed on Microsoft's delist portal (sender.office.com)
- Domain confirmed not listed on Spamhaus DBL or SURBL
- Domain registered with Google Postmaster Tools
- JMRP enrollment attempted — not available to Google Workspace senders as SNDS requires IP ownership
- Outlook.com Postmaster support request submitted
2 Replies
There is no sender-side switch that instantly resets Microsoft reputation.
SCL 5 by itself is not enough to identify the root cause in cloud filtering. Check the X-Forefront-Antispam-Report header and review the CAT, SFV, and BCL values.
If you see CAT:SPM or SFV:SPM, the administrator for each affected Microsoft 365 recipient should submit the original message as a false positive through the Microsoft Defender Submissions page. Microsoft may create a temporary allow entry while the submission is reviewed.
For Outlook.com recipients, continue with the Postmaster Sender Support case and follow the automated response instructions exactly, otherwise the case may not progress.
Keep sending volume consistent, avoid unsolicited test traffic or lists that may generate complaints, and allow time for sender reputation to improve. SPF, DKIM, and DMARC confirm sender identity, but they do not override Microsoft reputation filtering.
Hi, passing SPF/DKIM/DMARC is necessary, but it does not automatically give a new domain good reputation with Microsoft recipients.
For a new Google Workspace domain, I would warm up sending slowly, keep volume consistent, avoid link-heavy test messages, avoid URL shorteners, and make sure DKIM and DMARC alignment are clean. If Microsoft 365 tenant recipients are available to you, have their admins submit the messages as false positives through Defender/Exchange reporting, because that gives Microsoft a much better signal than just users moving mail out of Junk.
For Outlook.com recipients, the Postmaster/support request is the right route, but there may not be a fast override if the domain is simply cold. Also check whether the domain, not only the sending IP, appears in any reputation or block systems. Unfortunately, for brand-new domains, a gradual warm-up is often part of the fix.
