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

Comments

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

  1. Matthew Levy avatar
    Matthew Levy

    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. Brian Reid avatar

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

    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?

    1. Brian Reid avatar

      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. Rajesh Hirani avatar
    Rajesh Hirani

    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?

    1. Brian Reid avatar

      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.

  5. Jonathan K avatar
    Jonathan K

    As of 05/2024 Enhanced Filtering for Connectors now has the option to set

    “Automatically detect and skip the last IP address: We recommend this value if you have to skip only the last message source.”

    so you don’t need to account the mimecast IP’s if Mimecast is your last hop before EOP

    1. Brian Reid avatar

      So this option has existed with Enhanced Filtering since the feature existed. It only covers the single last IP before EOP. So in a case where your 3rd party anti-spam provider routes through more than one IP it is of no use and requires you to enter the actual IPs. In the specific case of Mimecast, I think from memory that it only does route through a single IP, so if your routing is Sender > Mimecast > EOP it would work, but if you had Sender > Mimecast > On-Premises Exchange Server > EOP (for example) it would not work. Therefore this article covers the better option of specifically listing the inbound IP addresses used by Mimecast.

Leave a Reply

Your email address will not be published. Required fields are marked *

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