Emails from Google Workspace flagged with SCL 9 after past domain spoofing (SPF, DKIM, DMARC passing)

Question

Hello everyone,

I am a Google Workspace administrator seeking guidance on resolving a persistent email deliverability issue when sending to Microsoft/Outlook tenants.

Background

About four months ago, our domain experienced a spoofing incident where malicious actors sent spam pretending to be from our domain. Following the incident, I immediately tightened domain security and fully implemented authentication policies.

Current Setup & Status

Authentication: SPF, DKIM, and DMARC are all fully implemented, passing, and aligned.

Problem: Emails sent to Microsoft Outlook accounts continue to be marked with a Spam Confidence Level (SCL) of 9, causing messages to land in recipient Spam/Junk folders or get quarantined.

• Duration: The SCL score has remained stuck at 9 for roughly four months despite our clean sending history since securing the domain. Given that authentication is passing cleanly, I anticipated the SCL score would recover organically over time. Since it hasn't, I would appreciate feedback on the following:
  1. Are there specific Microsoft tools or request forms (e.g., SNDS, Delist Portal, or Tenant Admin submissions) recommended for requesting a review of domain/IP reputation after an incident?
  What additional troubleshooting or remediation steps should I take to clear this historical reputation flag? Any insights or recommended procedures would be greatly appreciated. Thank you for your time!

Answer 1

Hi,

Since these messages are being sent from Google Workspace to Microsoft/Outlook recipients, I would recommend starting with Google Workspace Support (or your email service provider) to review the sender-side configuration and domain reputation.

While Microsoft 365 is the receiving platform that ultimately assigns the Spam Confidence Level (SCL) score, Google is in the best position to investigate the outbound mail flow, including SPF, DKIM, and DMARC alignment, Google Workspace routing, sending infrastructure, and any potential reputation impact that may have resulted from the previous spoofing incident.

It's also worth noting that even when SPF, DKIM, and DMARC pass successfully, messages can still be filtered as spam. This is because Microsoft evaluates many additional signals, such as sender reputation, historical sending patterns, message content, recipient engagement, complaint rates, and any characteristics commonly associated with bulk email traffic.

In addition, because your emails are being sent through Google Workspace, I would strongly suggest reviewing your domain in Google Postmaster Tools. This can provide valuable insights into factors such as domain reputation, spam rates, authentication status, and delivery-related issues that may be affecting inbox placement.

Here are a few next steps that I recommend:

1/ Contact Google Workspace Support:

I recommend asking Google Workspace Support to:

• Review your outbound mail flow and sending reputation.
• Confirm whether your domain or sending infrastructure has any reputation-related concerns.
• Verify that SPF, DKIM, and DMARC alignment are consistently passing for messages sent to external recipients.
• Check whether the earlier spoofing incident may still be affecting sender reputation.

2/ Review Google Postmaster Tools:

If you have not already done so, review your domain in Google Postmaster Tools and examine:

• Domain and IP reputation.
• Spam rate metrics.
• Authentication results.
• Delivery errors or unusual trends.

These reports can often help identify issues that may not be immediately visible elsewhere.

3/ Collect full message headers from affected recipients:

It would also be helpful to obtain the full message headers from one or more Outlook or Microsoft 365 recipients who received messages marked with SCL 9.

The header information may provide important clues about:

• Authentication results.
• Sending IP reputation.
• Routing paths.
• Content-related filtering signals.
• Other factors that contributed to Microsoft's classification decision.

This information can be very useful when working with Google Workspace Support during their investigation.

4/ Review the recipient side as well:

If the recipient belongs to a Microsoft 365 organization, their administrator may also be able to review the message within the Microsoft 365 security portal and, if appropriate, submit it as a false positive.

That said, because the emails originate from Google Workspace, I believe the primary investigation should begin on the sender side with Google Workspace or your email service provider, as they have visibility into the sending infrastructure and reputation data.

In summary, I would recommend engaging Google Workspace Support to review your sender reputation and outbound email configuration, while also gathering full message headers from affected recipients to support the investigation. Combining those findings with the information available in Google Postmaster Tools should help identify the underlying cause and guide the next steps toward improving email deliverability.

For more information, you can review: Resolve false positives for legitimate blocked emails in Microsoft Defender for Office 365.

I hope this helps clarify the situation and move things forward. Please feel free to share any updates or let me know if you need further assistance. I’ll be glad to help.

---

If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click "Comment".      

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.