Update 8/12/2025: Added the FAQ to the post. Also, to help shed more light on the Direct Send feature, we published a newer post called Direct Send vs sending directly to an Exchange Online tenant.
...
Updated Nov 12, 2025
Version 14.0
Blog Post
Arindam_Thokder
Microsoft
MicrosoftIf you do not want anyone to bypass your MX which is pointed to a 3rd party service, you can achieved this by creating an Inbound connector as recommended on step 4 in the support article mail flow best practices when using a third-party cloud service with Exchange Online using either TlsSenderCertificateName (preferred) or SenderIpAddresses parameters (you need to mention the Certificate presented by the 3rd party or the IP Address of the 3rd party), then set the corresponding RestrictDomainsToCertificate or RestrictDomainsToIPAddresses parameters to $True. With this configured, only mail that passes through the inbound connector is allowed into your tenant, otherwise it will be rejected. To know more, please refer to What is Direct Send and how to secure it
This is what we've done. But in hindsight, we shouldn't have to do this. I shouldn't see attempted messages being quarantined by EOP because some protocol or function was opened and available for an attacker to use which is why I'm stating about the .onmicrosoft.com MX records. We should have control over the 'default inbound connector' and our tenant be treated like it's an on-premise system. From a security standpoint, when things were on-premise we locked up our systems to only allow mail to come through 1 door and 1 door only for protection purposes this way everything is checked. And YES I get that building this connector does help with that, but the fact I still see spoofing attempts in EOP tells me that someone is still able to bypass the correct mail flow.