Exchange Online Third Party Anti-spam bypass
Hello,
It’s a common thing to put a third party anti-spam solution in front of Office 365 & EOP (Exchange Online Protection). Generally, you do it by pointing your MX record to your third party anti-spam like:
- ProofPoint
- IronPort
- Mail in Black
- Barracuda
- etc…
If you only do that, you are still exposed through an anti-spam bypass. Indeed, as soon as you add a domain to Office 365, Microsoft will provide you a MX record target in form of a DNS name that can be guessed:
- <TenantName>.mail.protection.outlook.com
- <low level domain name>-<top level domain name>.mail.protection.outlook.com.
You can find those records under “settings”, “domains” on your Office 365 admin portal.
How does it works
As soon as someone knows your have your mailboxes on Office 365 and you have a different MX than the one Microsoft provides, they can assume that they can bypass your third party anti-spam if you are not protected against it.
This kind of “attack” is achievable if you have a mail server with custom mail rule at reach. In the case of Exchange Online or Exchange 2013/2016/2019, you can use a outbound connector targeting the specific target domain and routing the email through smart hosts that is the MX DNS record that Microsoft provide instead of the MX record the target uses (their third party anti-spam).
This bypass assume that your Exchange Online Protection is not configured or not as performant as your third party anti-spam solution. If this is true, the “attack” has a high chance of success.
How to protect
The easiest way to protect your-self against this type of bypass is to create an inbound connector that only accept emails from your third party anti-spam IPs like this one:

The important settings are in the red squares:
- Identify the partner organization by verifying that messages are coming from these domains: *
- Reject messages if they don’t come from within these IP address ranges: 1.1.1.1
You can use this line of PowerShell to create this kind of connector:
New-InboundConnector -Name 'Secure Inbound' -ConnectorType 'Partner' -ConnectorSource 'AdminUI' -Enabled:$true -CloudServicesMailEnabled:$false -TlsSenderCertificateName 'thirdparty-antispam.com' -SenderIPAddresses @('1.1.1.1') -SenderDomains @('*') -RequireTls:$true -RestrictDomainsToCertificate:$true -RestrictDomainsToIPAddresses:$true
Of course, you need to adapt it to fit your needs.
Important points:
- You need to be sure to list all IPs that sends legitimate email directly to your Office 365 tenant
- Partners
- On premises Exchange servers
- On premises multi function printers
- You can have multiple connectors like this one, you can create one for each need
How do you know it’s working
You can verify if it’s working by trying to bypass the third party anti-spam and deliver an email to the MX DNS record that Microsoft provide with a custom connector from another Exchange/Exchange Online organization :

You can use this line of PowerShell to create this kind of connector:
New-OutboundConnector -Enabled:$true -ConnectorType 'Partner' -AllAcceptedDomains:$false -IsTransportRuleScoped:$false -Name 'ByPass Anti-Spam' -CloudServicesMailEnabled:$false -Comment '' -TlsSettings 'CertificateValidation' -TlsDomain $null -UseMXRecord:$false -RecipientDomains @('ItForDummies.net') -SmartHosts @('itfordummies.mail.protection.outlook.com') -RouteAllMessagesViaOnPremises:$false
If it worked, the sender will receive an NDR like this one:

Conclusion
Now you’re protected against this type of attack, it’s not the only way to do it, but it’s a simple and working one.
It is also a good idea to configure a basic security baseline in EOP even if you don’t use it. You can find some best practices here.