Manage mail flow using a third-party cloud service with Exchange Online
This topic covers the following complex mail flow scenarios using Exchange Online:
Scenario 1 - MX record points to third-party spam filtering
Scenario 2 - MX record points to third-party solution without spam filtering
Note
Examples in this topic use the fictitious organization, Contoso, which owns the domain contoso.com and is a tenant in Exchange Online. This is just an example. You can adapt this example to fit your organization's domain name and third-party service IP addresses where necessary.
Using a third-party cloud service with Microsoft 365 or Office 365
Scenario 1 - MX record points to third-party spam filtering
Important
Microsoft strongly recommends that you enable Enhanced Filtering for Connectors or bypass filtering completely using a mail flow rule (check out point 5). Failure to follow this step inevitably results in misclassification of inbound main into your organization, and a subpar experience for Microsoft 365 email and protection features.
Microsoft also recommends that you add third-party services that modify messages in transit as Trusted ARC sealers, if the service supports ARC sealing. Add the service as a trusted ARC sealer helps affected messages pass email authentication checks, and helps prevent legitimate messages from being delivered to the Junk Email folder, quarantined, or rejected. Third-party services that modify messages and don't support ARC sealing will invalidate the DKIM signatures of those messages. In these cases, you should review the Spoof detections report and create allow entries for spoofed senders to override email authentication failures for legitimate messages.
I plan to use Exchange Online to host all my organization's mailboxes. My organization uses a third-party cloud service for spam, malware, and phish filtering. All email from the internet must first be filtered by this third-party cloud service before being routed to Microsoft 365 or Office 365.
For this scenario, your organization's mail flow setup looks like the following diagram:
Best practices for using a third-party cloud filtering service with Microsoft 365 or Office 365
Add your custom domains in Microsoft 365 or Office 365. To prove that you own the domains, follow the instructions in Add a domain to Microsoft 365.
Create user mailboxes in Exchange Online or move all users' mailboxes to Microsoft 365 or Office 365.
Update the DNS records for the domains that you added in step 1. (Not sure how to do this? Follow the instructions on this page.) The following DNS records control mail flow:
MX record: Your domain's MX record must point to your third-party service provider. Follow their guidelines for how to configure your MX record.
SPF record: All mail sent from your domain to the internet originates in Microsoft 365 or Office 365, so your SPF record requires the standard value for Microsoft 365 or Office 365:
v=spf1 include:spf.protection.outlook.com -all
You would only need to include the third-party service in your SPF record if your organization sends outbound internet email through the service (where the third-party service would be a source for email from your domain).
When you're configuring this scenario, the "host" that you need to configure to receive email from the third-party service is specified in the MX Record. For example:
In this example, the host name for the Microsoft 365 or Office 365 host should be hubstream-mx.mail.protection.outlook.com. This value can vary from domain to domain, so check your value at Configuration > Domain > <select domain> to confirm your actual value.
Lock down your Exchange Online organization to only accept mail from your third-party service.
Create and configure a Partner inbound connector using either TlsSenderCertificateName (preferred) or SenderIpAddresses parameters, then set the corresponding RestrictDomainsToCertificate or RestrictDomainsToIPAddresses parameters to $True. Any messages that are smart-host routed directly to Exchange Online will be rejected (because they didn't arrive over a connection using specified certificate or from the specified IP addresses).
For example:
New-InboundConnector -Name "Reject mail not routed through MX (third-party service name)" -ConnectorType Partner -SenderDomains * -RestrictDomainsToCertificate $true -TlsSenderCertificateName *.contoso.com -RequireTls $true
or
New-InboundConnector -Name "Reject mail not routed through MX (third-party service name)" -ConnectorType Partner -SenderDomains * -RestrictDomainsToIPAddresses $true -SenderIpAddresses <#static list of on-premises IPs or IP ranges of the third-party service>
Note
If you already have an OnPremises inbound connector for the same certificate or sender IP addresses, you still need to create the Partner inbound connector (the RestrictDomainsToCertificate and RestrictDomainsToIPAddresses parameters are only applied to Partner connectors). The two connectors can coexist without problems.
There are two options for this step:
Use Enhanced Filtering for Connectors (highly recommended): Use Enhanced Filtering for Connectors (also known as skip listing) on the Partner inbound connector that receives messages from the third-party application. This allows EOP and Microsoft Defender XDR for Office 365 scanning on the messages.
Note
For hybrid scenarios where third-party applications rely on an on-premises Exchange server to send to Exchange Online, you also need to enable Enhanced Filtering for Connectors on the OnPremises inbound connector in Exchange Online.
Bypass spam filtering: Use a mail flow rule (also known as a transport rule) to bypass spam filtering. This option will prevent most EOP and Defender for Office 365 controls and will therefore prevent a double anti-spam check.
Important
Instead of bypassing spam filtering using a mail flow rule, we highly recommend that you enable Enhanced Filtering for Connector (also known as Skip Listing). Most third-party cloud anti-spam providers share IP addresses among many customers. Bypassing scanning on these IPs might allow spoofed and phishing messages from these IP addresses.
Scenario 2 - MX record points to third-party solution without spam filtering
I plan to use Exchange Online to host all my organization's mailboxes. All email that's sent to my domain from the internet must first flow through a third-party archiving or auditing service before arriving in Exchange Online. All outbound email that's sent from my Exchange Online organization to the internet must also flow through the service. However, the service doesn't provide a spam filtering solution.
This scenario requires you to use Enhanced Filtering for Connectors. Otherwise, mail from all internet senders appears to originate from the third-party service, not from the true sources on the internet.
Best practices for using a third-party cloud service with Microsoft 365 or Office 365
We strongly recommend that you use the archiving and auditing solutions that are provided by Microsoft 365 and Office 365.
Important
There is a 3rd scenario where MX record points to Microsoft 365, however, the third-party service operates after Microsoft 365. In this setup, emails leave the Microsoft 365 environment and are routed to the third-party service for spam, malware, and phishing filtering. Once filtered, the messages return to Microsoft 365. For more details on this setup, including its challenges and complexities, refer to the article Integration via in-and-out mail routing
See also
Mail flow best practices for Exchange Online, Microsoft 365, Office 365 (overview)
Set up connectors for secure mail flow with a partner organization
Manage all mailboxes and mail flow using Microsoft 365 or Office 365
Manage mail flow using a third-party cloud service with Exchange Online and on-premises mailboxes