Why does O365 mark emails from my domain sent via a third-party ESP as spam?
Michael Ko
Co-founder & CEO, Suped
Published 11 Jul 2025
Updated 15 Aug 2025
8 min read
It can be incredibly frustrating when emails from your own domain, sent through a trusted third-party email service provider (ESP), end up in the spam folder, especially if it seems to only affect recipients on Microsoft 365. This situation often points to specific configurations or security features within O365 that are designed to protect users from spoofing and phishing attempts. While your SPF, DKIM, and DMARC records might be perfectly aligned and passing, O365 has its own layers of filtering that can sometimes be overly aggressive or misconfigured for legitimate mail streams.
The core of the issue often lies in how Microsoft 365 (formerly Office 365) interprets emails that appear to be from an internal domain but originate from an external source, like an ESP. This is a common challenge for businesses leveraging cloud email services alongside marketing or transactional email platforms. Understanding the nuances of Microsoft's filtering can help diagnose and resolve these deliverability roadblocks, preventing your important messages from being marked as junk.
Understanding O365's unique filtering mechanisms
Even with perfectly configured SPF, DKIM, and DMARC records, O365 may still flag emails as spam or phishing. This is often due to its internal anti-spoofing and anti-forgery mechanisms, which are designed to protect users from malicious emails appearing to come from their own organization. When a third-party ESP sends emails on behalf of your domain, O365's internal filters may see this as a potential spoofing attempt, even if all external authentication checks pass.
Another factor contributing to emails being marked as spam can be the reputation of the sending IP address or the specific ESP's shared IP ranges. If other senders using the same ESP have engaged in questionable practices, it can negatively impact your email deliverability, even if your domain reputation is strong. You can learn more about why emails might be marked as spam even with good domain reputation in our detailed guide.
Content is another common culprit. Spam filters, including those in O365, analyze email content for characteristics typically associated with spam, such as suspicious links, unusual formatting, or certain keywords. A sudden surge in email volume or a drastic change in content can also trigger these filters, leading to messages being blocked or sent to the junk folder. This is why many organizations consult an expert guide to prevent emails going to spam.
The role of O365's anti-forgery protection
One primary reason for this behavior is Microsoft 365's built-in anti-spoofing and anti-forgery features. These features are highly sensitive to emails where the `From:` address domain matches a domain configured within your O365 tenant, but the actual sending server (IP address) is external to Microsoft's infrastructure. Even if your email authentication protocols are correctly set up, O365 might still view this as an attempt to spoof an internal sender.
Advanced Threat Protection (ATP), now part of Microsoft Defender for Office 365, is another key component. ATP includes features like anti-phishing policies, safe attachments, and safe links, which can be configured to be very strict. If ATP settings are enabled and not specifically configured to allow your third-party ESP, they can (and often do) mark legitimate emails as spam or even quarantine them. This is particularly true for emails sent to O365 recipients.
It's also worth considering if your organization uses any third-party email security gateways, such as Mimecast or Proofpoint, in front of your O365 tenant. These services add an additional layer of filtering. They might have their own impersonation protection rules or aggressive spam policies that flag emails from your ESP. While they aim to protect, these can sometimes block legitimate mail, especially if the sender's domain has been flagged previously.
Typical ESP sending
Authentication: Relies on proper SPF, DKIM, and DMARC records to authorize the ESP to send on your behalf.
Trust Model: ISPs trust emails that pass these checks and have a good sender reputation.
Deliverability Factors: IP reputation, domain reputation, content, engagement metrics.
O365 internal filtering
Anti-Spoofing: Flags emails that appear to be from an internal O365 domain but originate externally.
ATP Policies: Advanced Threat Protection, including anti-phishing rules, can block or quarantine emails without explicit allow-list entries.
Local Configuration: Specific tenant settings can override general deliverability best practices.
Diagnosing the problem: header analysis and reputation checks
The first step in diagnosing this problem is to examine the email headers of a message that landed in spam. Specifically, look for the authentication results, such as SPF, DKIM, and DMARC. While they might pass for external recipients, O365 might add its own verdict or a high spam confidence level (SCL) score. This can reveal if Microsoft'sDefender for Office 365 is marking the email as spam despite correct authentication.
Example of email headers for diagnosistext
Authentication-Results: spf=pass (sender IP is 192.0.2.1) smtp.mailfrom=yourdomain.com; dkim=pass (signature was verified) header.d=yourdomain.com; dmarc=pass action=none header.from=yourdomain.com;
X-MS-Exchange-Organization-AuthSource: external.contoso.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-Forefront-Antispam-Report: ... SCL: 5 ... (High SCL indicates spam)
Additionally, check if your sending IP address or domain is listed on any internal Microsoft blocklists (or blacklists) or if your ESP's shared IP range has a poor reputation with Microsoft. Microsoft maintains its own internal reputation systems, which can be stricter than public blocklists. Using a blocklist checker can give you an indication, but Microsoft's internal view is paramount.
Finally, review your Microsoft 365 tenant's anti-phishing policies and connection filters. Specific rules might be configured to prevent spoofing of your domain, which could be inadvertently catching your legitimate ESP-sent emails. If you find your Salesforce Marketing Cloud emails going to spam after a domain switch, it might be due to similar reasons.
Remediation and configuration adjustments
Bypass anti-phishing for your ESP
In the Microsoft 365 Defender portal, navigate to Email & Collaboration > Policies & Rules > Threat policies > Anti-phishing. Edit the policy that applies to your domain. Under "Spoof intelligence" or "Spoof settings," you might find an option to create an allow entry for your ESP's sending IP addresses or domains. This tells Microsoft that emails from these sources, using your domain, are legitimate. You may need to review Microsoft'snew sender requirements to ensure full compliance.
Beyond allowing the ESP, it's crucial to ensure your SPF record includes all legitimate sending sources. If your ESP's IP ranges are not explicitly authorized in your SPF record, emails from that ESP will fail SPF checks, leading to spam placement. Similarly, confirm that DKIM is correctly implemented for your ESP, allowing them to digitally sign emails with your domain. This alignment is critical for passing DMARC policy. If you're experiencing issues, consider why transactional emails might be landing in spam despite proper authentication.
For specific internal rules, sometimes O365 administrators might have configured Transport Rules or Mail Flow Rules that inadvertently block or junk emails based on certain criteria, such as sender IP or domain patterns, or even content. Reviewing these rules within the Exchange admin center can often uncover hidden filters affecting your ESP's emails. Ensuring proper alignment and configuration, including your DMARC record, is key to preventing emails from being marked as junk or phishing in Outlook 365.
Views from the trenches
Best practices
Always include your ESP's sending IPs in your SPF record, or use an SPF `include:` mechanism.
Implement DKIM for your sending domain through your ESP's settings, ensuring keys are published.
Set up a DMARC record, starting with a `p=none` policy to monitor authentication results.
Use O365 Defender's anti-phishing policies to allow your ESP's IP or domain to bypass internal spoofing checks.
Monitor your DMARC reports for comprehensive insights into email authentication results and potential issues.
Common pitfalls
Overly strict anti-spoofing policies in O365 blocking legitimate third-party sends.
Missing or incorrect SPF entries for your third-party ESP, leading to SPF failures.
DKIM signatures not being properly applied by the ESP or not validating correctly.
Ignoring DMARC reports, which can highlight authentication failures from unauthorized senders.
Not configuring explicit allow-list entries for ESPs in O365's anti-phishing or transport rules.
Expert tips
Use a subdomain for ESP sending (e.g., `mail.yourdomain.com`) to separate reputation and potentially ease O365 filtering.
If using Mimecast or similar, check their impersonation protection rules for potential blocks.
Engage with Microsoft support if you've exhausted all troubleshooting steps and still face issues.
Consider segmenting your email sends; use O365 for internal/one-to-one and ESP for bulk sends.
Implement BIMI for stronger brand identity and improved sender trust with supported recipients.
Expert view
Expert from Email Geeks says to examine the authentication results, as Microsoft has unique processing for domains hosted there but sent from an external source.
2020-09-21 - Email Geeks
Expert view
Expert from Email Geeks notes that a configuration checkbox might exist to treat mail from a different SMTP server as forged, suggesting a local config or anti-forgery issue.
2020-09-21 - Email Geeks
Navigating O365's spam filters
Emails from your domain sent via a third-party ESP landing in O365 spam folders, while perplexing, often stem from Microsoft's robust (and sometimes overzealous) internal security mechanisms. These include anti-spoofing, anti-forgery, and ATP policies designed to protect users from internal domain impersonation.
By meticulously reviewing email headers, ensuring all DNS records (SPF, DKIM, DMARC) are correctly configured for your ESP, and making specific adjustments within your Microsoft 365 Defender portal, you can significantly improve deliverability. Often, it's a matter of explicitly telling Microsoft that your ESP is an authorized sender for your domain, even if it's external to their primary email system. This will help prevent your legitimate emails from being incorrectly flagged as spam or falling onto a blocklist (or blacklist).
Microsoft 365. This situation often points to specific configurations or security features within O365 that are designed to protect users from spoofing and phishing attempts. While your SPF, DKIM, and DMARC records might be perfectly aligned and passing, O365 has its own layers of filtering that can sometimes be overly aggressive or misconfigured for legitimate mail streams.
