The EXO 3rd Party gateway bypass is even worse than you thought

By | April 1, 2025

If you have a 3rd party mail gateway in front of your Exchange Online tenant and haven’t already fixed the bypass issue, then you’re opening yourself up to inbound emails that completely skip the usual checks performed by Exchange Online Protection.

What is the bypass issue?

If you use a 3rd party gateway as your front door for emails, then the MX record for your email domain(s) will point to your 3rd party gateway for delivery instead of the MX record associated with your Exchange Online tenant. If you don’t restrict your tenant to only accept emails from your 3rd party gateway, then anyone can send to your mail recipients by submitting emails directly to the MX name associated with your M365 tenant name.

In the example above, fisheagle.onmicrosoft.com is the name of associated with my M365 tenant. fisheagle.mail.protection.outlook.com is the MX target for the tenant.

I can submit SMTP emails (e.g. using Powershell) specifying fisheagle.mail.protection.outlook.com as the server name and they will be accepted and delivered. I can choose to use any of the Accepted Domains configured for the EXO tenant. So for example, I could send an email to judith.prietht@fish-eagle.net using this method and the email would be delivered (assuming of course that’s a valid email address in the tenant).

Why is the bypass a problem?

If you use a 3rd party mail gateway, then it’s probably there for a reason. Perhaps it offers additional message hygience protections, or maybe it provides some custom mail handling. Whatever the reason you have, you probably don’t want people bypassing the gateway. The spammers, phishers (made up word?), and other bad guys out there know about the bypass and will be looking to exploit it to work around any protections provided by your gateway.

OK, but why is it really a problem?

By now, you’re probably thinking that the bypass is bad, but not really that bad. I mean, EXO/EOP/MDO has all manner of protections in place by itself, right? Right? Well, yes it does, but only if you are not using a 3rd party gateway. If EXO knows it is not the MX target for your Accepted Domains, then it will not bother with the checks it normally does for inbound email.

Testing the behaviour

This all sounded really bad when I heard about it, so I decided to test it using one of my tenant’s Accepted Domains (open-a-socket.com). The first thing I did was to set up an MX record for the domain to point to a dummy 3rd party mail gateway IP address. The next step was to send a spoofed (and altogether quite dodgy-looking) email using Powershell and targeting my EXO tenant in the server name.

Send-MailMessage -To smtp.tests@open-a-socket.com -From the_boss@open-a-socket.com -Subject "Invoice Due" -Body "Please urgently pay USD1000" -SmtpServer openasocket-com01f.mail.protection.outlook.com

Given that that from address is clearly spoofed, and that my domain has a DMARC action set to “p=reject”, I would expect Exchange Online Protection to simply drop the email. Failing that, I would expect other (MDO) protections to kick in and either quarantine the item or mark it as Spam and deliver it to the Junk Email folder. Did any of these things happen? No!!! The email was delivered right into the Inbox.

When checking the message headers, the Authentication-Results clearly show the DMARC failure.

Interestingly, the Authentication-Results also show Composite Authentication (compauth) as “none” with the reason as “451”. According to Microsoft online documentation, this indicates that the mail item bypassed Composite Authentication completely.

4xx or 9xx: The message bypassed composite authentication (compauth=none). The last two digits are internal codes used by Microsoft 365. Source: Anti-spam message headers – Microsoft Defender for Office 365 | Microsoft Learn

My testing indicates that pretty much all the normal checks you would expect from EOP/MDO on inbound emails are bypassed using this method. It’s a bit like rolling out the red carpet to welcome the bad guys.

So, what can you do about it?

Fixing the bypass issue

Basically, the fix is to configure a new EXO Connector to re-route any email received via the bypass mechanism to your 3rd party gateway. This ensures that all emails ultimately come through your intended front door. I would explain the setup here, but the good folks over at Practical 365 already have a well established article that goes through what is required in some detail. Check it out here: https://practical365.com/how-to-ensure-your-third-party-filtering-gateway-is-secure/

Conclusion

If you use a 3rd party mail gateway as your front door for your EXO tenant, it is really important that you fix the bypass issue to stop the bad guys flooding your mailboxes with spam and/or phishing emails.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.