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 > 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 (added to blog March 2020) is where a message from SenderA.com to RecipientB.com where both SenderA.com and RecipientB.com uses the same Mimecast (or another cloud security provider) region. The MX record for RecipientB.com is Mimecast in this example and outgoing email from SenderA.com leaves Mimecast as well. When EOP gets the message it will have gone from SenderA.com > Mimecast > Mimecast > RecipientB.com > 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. Note that EOP won’t, because of this complexity in routing, reject hard fails or DMARC rejects immediately.
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.
So how can you tell EOP 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 your (in this case as we as are talking about Mimecast) 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 Office 365 and on the Enhanced Filtering portal in the Office 365 Protection Center.
This article assumes you have already created your inbound connector in Exchange Online for Mimecast as per the Mimecast documentation (paywall!). You need a connector in place to associated Enhanced Filtering with it.
For any source on your routing prior to EOP you need the list of public IPs and I have listed here are 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 datacenter 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 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 IP senders of my domain should be in my 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 writing in March 2021 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 20 or so 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.
Set-InboundConnector "Inbound from Mimecast USA" -EFSkipIPs 22.214.171.124/32,126.96.36.199/32,188.8.131.52/32,184.108.40.206/32 Set-InboundConnector "Inbound from Mimecast Europe" -EFSkipIPs 220.127.116.11/32,18.104.22.168/32,22.214.171.124/32,126.96.36.199/32 Set-InboundConnector "Inbound from Mimecast Germany" -EFSkipIPs 188.8.131.52/32,184.108.40.206/32,220.127.116.11/32,18.104.22.168/32 Set-InboundConnector "Inbound from Mimecast Australia" -EFSkipIPs 22.214.171.124/32,126.96.36.199/32,188.8.131.52/32,184.108.40.206/32 Set-InboundConnector "Inbound from Mimecast Africa" -EFSkipIPs 220.127.116.11/32,18.104.22.168/32,22.214.171.124/32,126.96.36.199/32 Set-InboundConnector "Inbound from Mimecast Offshore" -EFSkipIPs 188.8.131.52/32,184.108.40.206/32,220.127.116.11/32,18.104.22.168/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 skipped for spf/DMARC checking in EOP and the actual source is used for the checks instead.
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.
Photo by Miguel Á. Padriñán from Pexels