Enable EOP Enhanced Filtering for Mimecast Users

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 > 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 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.

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 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 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,,,

Set-InboundConnector "Inbound from Mimecast Europe" -EFSkipIPs,,,

Set-InboundConnector "Inbound from Mimecast Germany" -EFSkipIPs,,,

Set-InboundConnector "Inbound from Mimecast Australia" -EFSkipIPs,,,

Set-InboundConnector "Inbound from Mimecast Africa" -EFSkipIPs,,,

Set-InboundConnector "Inbound from Mimecast Offshore" -EFSkipIPs,,,
The Enhanced Filtering for Connectors popout in the Office 365 Security and Compliance Center with one of the above ranges added to a connector called “Inbound from Mimecast”

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.

Microsofts update to honour DMARC in 2023 will cause 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

6 responses to “Enable EOP Enhanced Filtering for Mimecast Users”

  1. Wow, thanks Brian. Very interesting. My organization uses Mimecast in front of EOP and we have seen a lot of messages getting quarantined because they fail SPF or DKIM. So we have this implemented now using the UK region of inbound Mimecast addresses.

    If I understand correctly, enhanced filtering will skip the inbound IPs of Mimecast that apply to my system but look at the sender IP against the SPF record etc. But in the case of another Mimecast customer in the same region, it will look at the outbound Mimecast IPs for that customer (same ones I use) and compare to SPF which should pass if the customer has Mimecast Include in their SPF? Why do you recommend customer include their own IP in their SPF?

  2. That’s correct. SPF is all about who is legitimately the sender of the email, and so any public IP that you send from and I would say that includes your public IP to Mimecast, should be on your SPF record. You have no idea what the receiving system will do to process the SPF checks.

  3. Great Info! Trying to set up skiplisting with Mimecast using the same IP addresses you mentioned. Mine are still coming through from Mimecast on these as well. But the headers in the emails are never stamped with the skiplist headers. Did you ever try to scope this to specific users only?

    • I never tried scoping this to specific users, but this was only because if the email goes to anyone else then all the email will avoid skip listing. So for example if you have a Distribution List you are emailing for test purposes, and you scope Enhanced Filtering to the members of the DL then it will avoid skip listing because the email was sent to the DL and not the specific users. I always just enable this for the full domain because I find it works if you get the IP’s correct and where it does not work is when the IP is not what you list.

  4. thanks for the post, just want I need to help configure this.
    Question – should I see a different in the message trace source IP after making the change?

    • The source IP will not change, you are just telling Exchange Online Protection to look before the Mimecast IPs to see the sender IPs and then evaluating the truth about the sender based on the senders IP and not that EOP sees the message coming from Mimecast’s IPs.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.