What happens when an Office 365 customer doesn’t point to EOP as their MX?

5/5 - (2 votes)

I get asked this question quite frequently–usually by customers who want to continue using their existing on-premises antispam or antimalware gateway or want to attempt to implement a defense-in-depth strategy.

The graph and intelligence behind Exchange Online Protection (EOP) processes at least half a trillion (500,000,000,000) messages a month–the AI behind it is continually monitoring and learning what is spam and what is not. Some customers, however, still want to use additional layers.

I put together a blog here that outlines some of our best practices.  In this post, I’m going to go a little bit more into things that don’t work (or work as well) when EOP is not your MX record if you’re an Office 365 or Exchange Online customer.

Things that don’t work (or don’t work as well)

We’ll start with this list.  If you are pointing your MX to another service or infrastructure and are then using it to forward mail to EOP, there are some things that just don’t work (or don’t work as efficiently).

IP reputation blocks

Reputation is everything, and EOP makes significant use of reputation-based filtering.  Since the sending IP is now your other mail gateway, we can’t use the source’s sending IP to determine if it’s on a DNSBL or other known “bad” list. Update: We have a new feature called IP skiplisting or Enhanced Filtering to help with this.

IP throttling

Additionally, EOP utilizes a form of greylisting for IPs that it hasn’t seen before; delivering all mail from a single egress point masks the source IP so we don’t know what it is. This may result in mail delivery delays until the sending IP has enough reputation history to establish itself as “safe.”

DNS checks that rely on the sending IP

A variety of standard DNS-based security features (such as Sender Policy Framework or SPF) rely upon being able to validate sender domains and IP addresses.

IP allow or block entries

Similar to IP reputation and throttling issues, if you’re relaying all your mail through another host or service (either on-premises or third-party), that egress point is the only IP address seen. If you’ve configured connecting filtering rules, they won’t work.

Some spam filter rules that look for specific IP ranges or PTR records

This may seem a bit like a dead horse, but obviously, anything that relies on IP filtering (such as known-spam sender IP addresses) also will not work.

Anti-spoofing checks

As mentioned previously, SPF makes use of DNS and IP lookups.  More advanced techniques such as Domain Keys Identified Mail (DKIM) and Domain-Based Messaging And Reporting Conformance (DMARC) also make use of it, so EOP won’t be able to validate those records. If you have Exchange Transport Rules (ETRs) that depend upon specific DMARC results, those won’t work correctly.

Bulk mail filter

And finally, bulk mail filtering.  Many bulk mail senders have “known” addresses or ranges and those are used in the message analysis for solicited bulk email.

Things that still work

Despite all of those IP-based filtering and analysis tools that don’t work, there are still quite a few things that do.  Let’s take a look at those.

Malware filtering

Known-malware filtering is based largely on pattern/definition analysis and matching. So, if someone attaches a piece of malware to a message, it’s going to get trapped because the file signature will be detected regardless of header information.

Exchange Transport Rules (ETRs) that don’t rely upon the sending IP

Exchange Transport Rules that utilize keywords or evaluate senders and recipients directly won’t be affected.

Safe and blocked senders

The safe and blocked senders feature won’t be affected.

Safe and blocked domains

Similarly, the safe and blocked domains feature won’t be affected–mostly. If someone has spoofed the sender’s domain, that may present a problem as you’ve kneecapped how we can figure out if a message’s origination is where it says it is (DMARC and SPF features are primarily affected).

Advanced Threat Protection features (Safe Links and Safe Attachments)

The ATP features Safe Links and Safe Attachments are unaffected as well.  Safe Links evaluates hyperlinks in messages at the time-of-click in a user’s mailbox, helping protect against latent threats (threats that are inactive when the message is originally delivered but activated at a later time).  The Safe Attachments feature is a heuristic sandbox analysis tool that analyzes the behavior of attachments. Both of these features are content analysis-based and do not rely upon message header information.

Content filter

The content filter is not impacted.

What you can do to improve your experience if you insist on doing this

If an organization utilizing Exchange Online insists on using additional mail gateways, scanning services, or relays in front of Exchange Online Protection, you may need to update your Exchange Online protection configuration if you want to use EOP features in conjunction with other solutions.

IP Skiplisting or Enhanced Filtering is a newer Exchange Online feature that allows EOP to basically evaluate a message header and disregard the previous hop (or specified addresses) and treat the next one previous as the source.  This can be useful if you have multiple hops along your mail routing path or are attempting to use multiple services to filter and process mail.

author avatar
Aaron Guilmette
Helping companies conquer inferior technology since 1997. I spend my time developing and implementing technology solutions so people can spend less time with technology. Specialties: Active Directory and Exchange consulting and deployment, Virtualization, Disaster Recovery, Office 365, datacenter migration/consolidation, cheese.

2 Replies to “What happens when an Office 365 customer doesn’t point to EOP as their MX?”

  1. Question with regards to Connection Filter policy (IP Allow), when Enhanced Filtering is enabled in complex routing environments – does the connection filter come in to play at all? Eg if EOP is assessing based on the originating IP (as part of Enhanced Filtering) will an ip allowed in the connection filter bypass spam processing. I would have though this would not be the case and EOP only assess SPF based on the originating connecting IP but the documentation is not clear.

Comments are closed.