Enable EOP Enhanced Filtering for Mimecast Users

Enhanced Filtering is a feature of Exchange Online Protection (EOP) that allows EOP to skip back through the hops the messages has been sent through to work out the original sender.

Take for example a message from SenderA.com to RecipientB.com where RecipientB.com uses Mimecast (or another cloud security provider). The MX record for RecipientB.com is Mimecast in this example. When EOP gets the message it will have gone from SenderA.com > Mimecast > RecipientB.com Servers > EOP, or it will have gone SenderA.com > Mimecast > EOP if you are not sending via any other system such as an on-premises network.

A second example is where a message from SenderA.com to RecipientB.com where both SenderA.com and RecipientB.com uses the same Mimecast region (or another cloud security provider IP addresses/region). The MX record for RecipientB.com is Mimecast in this example and outgoing email from SenderA.com uses Mimecast outbound as well. When EOP gets the message, it will have gone from SenderA.com > Mimecast > Mimecast > RecipientB.com Servers > EOP, or it will have gone SenderA.com > Mimecast > Mimecast > EOP if you are not sending via any other system such as an on-premises network. The Mimecast double-hop is because both the sender and recipient use Mimecast.

EOP though, without Enhanced Filtering, will see the source email as the previous hop – in the above examples the email will appear to come from Mimecast or the on-premises IP address – and in the first case neither of these are the true sender for SenderA.com and so the message fails SPF if it is set to -all (hard fail) and possibly DMARC if set to p=reject or p=quarantine. Note that EOP won’t, because of this complexity in routing, reject hard fails or DMARC rejects until August 2023. After this date Microsoft will honour the sender DMARC policy, and this could break mail flow in complex scenarios such as any with a 3rd party mail filter.

When the sender also uses the same Mimecast region as yourself, SPF does not fail at EOP, but this is only because the senders SPF records list the inbound IP addresses that EOP is getting all your email from, that is, the sender lists Mimecast in SPF and all your email is coming via Mimecast.

The fix is enhanced filtering

So how can you tell Exchange Online Protection about your complex routing and the use of some other service in front of EOP and configure EOP to cater for this routing? The fix is Enhanced Filtering. You add the public IPs of anything on your part of the mail flow route. This could include your on-premises network and, if you used one, the cloud filter that processes your emails as well. And you need to configure these public IPs on the Inbound Connector in the Exchange Online Management portal in Microsoft 365 and on the Microsoft 365 Security Center.

This article assumes you have already created your inbound connector in Exchange Online for Mimecast as per the Mimecast documentation (paywall!) as you need a connector in place to associate Enhanced Filtering with it.

For any source on your routing prior to EOP you need the list of public IPs and I have listed below the IPs (at the time of writing) for Mimecast datacenters in an easy to use PowerShell cmdlet to add them to your Inbound Connector in EOP – you need the PowerShell for your Mimecast region and the correct name in the cmdlet for your inbound connector.

Note that the IPs listed on these connectors are a subset of the IPs published by Mimecast. This list is ONLY the IPs that Mimecast sends inbound messages to the customer from. They do not publish this list (instead they publish the full inbound/outbound range as a single list in their docs).

When you configure an inbound delivery route in Mimecast it will only deliver from these below IPs per region and so in the scenario described above where you have the sender using Mimecast and you use Mimecast (both same region), the use of the full published range that Mimecast provides means Enhanced Filtering looks beyond both your Mimecast subscription and the senders subscription and requires that the sender lists their public IP before Mimecast in their SPF – and they probably won’t do this, as Mimecast says they do not need to (though I disagree, and all public IP addresses that send email for your domain should be in your SPF record).

All public IP addresses that send email for your domain should be in your SPF record.

Because Mimecast do not publish the list of IPs that they use for inbound delivery routes and instead publish their entire IP range (delivery outbound to MX and inbound delivery routes to customers) I recommend that you check that the four IPs listed below for your region are still correct. At the time of last update in July 2023 this list is correct, but not all these IPs are owned by Mimecast and they are changing those that they do not own to those that they do at some point. You can easily check the IPs by looking at a number of inbound messages to your email environment – they should all come from the below four addresses for your region. If this has changed, drop a comment below for everyone’s benefit. If you use these lists, drop a comment below so you get updated if we change the list based on other users investigations.

If you have the Defender for Office Plan 2 licence, you can use the Threat Explorer feature to export a long list of recently delivered email metadata (up to 200,000 records) and then look to see if the Sender IP for inbound email is more than just the IPs listed below.

Set-InboundConnector "Inbound from Mimecast USA" -EFSkipIPs 205.139.110.61/32,205.139.110.120/32,207.211.31.81/32,207.211.31.120/32,170.10.128.131/32,170.10.128.81/32

Set-InboundConnector "Inbound from Mimecast Europe" -EFSkipIPs 195.130.217.76/32,195.130.217.221/32,91.220.42.220/32,91.220.42.227/32

Set-InboundConnector "Inbound from Mimecast Germany" -EFSkipIPs 51.163.159.21/32,51.163.158.241/32,62.140.10.21/32,62.140.7.241/32

Set-InboundConnector "Inbound from Mimecast Australia" -EFSkipIPs 103.13.69.22/32,103.13.69.101/32,124.47.150.22/32,124.47.150.101/32

Set-InboundConnector "Inbound from Mimecast Africa" -EFSkipIPs 41.74.193.80/32,41.74.193.103/32,41.74.197.79/32,41.74.197.102/32

Set-InboundConnector "Inbound from Mimecast Offshore" -EFSkipIPs 213.167.75.27/32,213.167.75.25/32,213.167.81.27/32,213.167.81.25/32

In the above, get the name of the inbound connector correct and it adds the IPs for you. It takes about an hour to take effect, but after this time inbound emails via Mimecast are checked in EOP based on their source IP address and not the sender that EOP sees (for example Mimecast). Therefore SPF/DMARC checking in EOP is against the actual source and so checks pass rather than fail.

For organisations with complex routing this is something you need to implement

You also need to add your ARC Trusted Sealers setting as well, which for Mimecast is dkim.mimecast.com.

Note that when you enable Enhanced Filtering, SCL -1 overrides that you might have in place are still honoured, but should be able to be removed once Enhanced Filtering is working. IP Allow List overrides though are ignored once Enhanced Filtering is active. Therefore EOP will process messages and consider them for junk or quarantine becuase it sees them as coming from the original sender and not from any IP on the IP Allow List. This of course improves all the machine learning and reporting in EOP, becuase now every email does NOT originate from a single (range of) IP addresses.

Microsoft’s updated its settings to honour the senders DMARC settings in mid 2023 and this change will have caused mail flow issues if anything in this article applies to you, and especially as all emails routed inbound through Mimecast will also fail DKIM from an Exchange Online perspective.

Photo by Miguel Á. Padriñán from Pexels