Microsoft would like you to think that Office 365 just works and that online Exchange is just a service you can consume without worry.  However scratch below the surface and you discover their architecture has a few flaws.

Office 365 is ever changing – so what I write now will probably be wrong in 3 months time…. but here goes anyway!

Many companies have existing gateway email protection, such as Mimecast or MessageLabs.  They also might run DLP or journaling on their Internet email.  As a result wanting all of your inbound and outbound email to go via the existing route is quite a common request when moving to Exchange Online.  When you run the Hybrid Configuration Wizard you have the option of centralised routing, which will make your outbound route go via your on-premises Exchange servers, what it doesn’t do in any way restrict mail flowing directly in to your tenant.  Because your tenant is wide open to receive email, other Office 365 tenants will suddenly start performing direct delivery.  This means other tenants do not use your MX records and instead send them directly in to your tenant.

To stop this behaviour you have to create a partner connector.  This is well documented and can be found on https://community.mimecast.com/docs/DOC-1608. The basic principle is, create a partner connector and only allow known IP addresses to connect.  Now those trying to connect directly to your tenant will be refused, and those who are also tenants will switch to MX record based delivery methods.

What all this doesn’t do is fully lock down your incoming email, some things will still be getting through directly to your tenant.  The best way to see what these are is to create a transport rule such as this one created for a Mimecast customer:

You will now see things appearing in your quarantine that arrive via different routes other than your authorised incoming route.

I spotted a bunch of spam arriving, somehow totally ignoring the connector I had created.  Upon investigation it turns out that these emails were arriving in a different Office 365 region, being processed by Exchange Online within that region and forwarded over to our region and delivered to the tenant.  Microsoft confirmed that they don’t replicate any form of connection filtering between regions, but they do have mail flow between regions.  Therefore when the email lands on the alternate region it can see that it is an O365 hosted mailbox, but it cannot see the connectors that say do not accept emails unless they are from the specified IP addresses.

This also highlighted some other issues with Exchange online.  Some system messages, specifically generated by EOP such as your quarantine report, well they’re tagged as external emails, so they get blocked.  If a user forwards a meeting request that was originally sent by an external email address, that gets tagged as external and blocked.

The rule also highlighted a few instances of poorly configured email systems elsewhere, for example if someone is an O365 tenant and uses it as the outbound smart host for their email delivery, they can end up in the same situation as the spammers – bypassing the connection filtering and having your email delivered directly.

So while Microsoft would have you believe a partner connector will block all inbound routes except those you specify, it still does let some emails through that should be blocked.  Plus who knows what other routes in Microsoft may open up in the future that you don’t know about or want.  Ultimately it is best to have a transport rule such as the one here if you are using a third party message hygiene service, but just be aware of the false positives that may result.