If you use Office 365 but your MX record doesn't point to Office, you may want to close down your security settings

  • Article

Even though it's not a recommend configuration for our customers (in terms of spam filtering), some customers of Office 365 route their email through a competing spam filtering service in the cloud, or through an on-prem server. That is, the mail flow looks like this:

I've written previously about the problems this can cause, see Hooking up additional spam filters in front of or behind Office 365. However, if you must do it, you may want to ensure that you force all email to go through the 3rd party server. If you hook up a 3rd party server, email can be delivered to your organization in Office 365 through that server or by connecting directly to EOP (Exchange Online Protection). This is not good because our spam filters don't understand that email was sent directly to the service and not through a gateway; if your MX record does not point to Office 365 or EOP, some spam filtering checks are suppressed automatically to avoid false positives.

Therefore, to get the fullest protection possible, I recommend relying upon the 3rd party service, and then maybe or maybe not doing double-filtering in EOP (accepting the fact that there will be false positives and false negatives). But, don't just rely on EOP.

So, to force email through your on-prem server, you will need to install a TLS cert in your on-prem server, and then always ensure that it's used when connecting from the server to Office 365. Then, create a partner connecter using a seldom used attribute which isn’t exposed via the mainstream UX but only through cmdlet. It’s called AssociatedAcceptedDomains.

To do this with TLS-cert-based connectors using cmdlets:

New-InboundConnector
–Name "OnlyAcceptEmailFrom<OnPremServer>"
-ConnectorType Partner
-SenderDomains *
-RestrictDomainsToCertificate $true
-TlsSenderCertificateName <Full set of TLS cert names>
-AssociatedAcceptedDomains <full list of accepted domains that belong to your organization>

For more information on TLS connectors and how to set up a partner connector, see Set up connectors for secure mail flow with a partner organization.

You may have to tweak this a bit to get it right, so you may want to experiment with some smaller domains before enabling it for every domain in your organization.

What this does is reject messages that don't come over the TLS cert; so long as your on-prem server is correctly configured, any email that tries to connect directly to Office 365/EOP should be rejected.

You would want to use this when you are connecting through an on-premise mail server and you can control the certificate. However, if you are connecting through a shared service and cannot specify the TLS-cert, then this would probably not be appropriate without some modifications to the connector.

Hopefully, you find this useful.