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. Despite that, some customers still want to use additional protections.
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.
- Things that don’t work (or don’t work as well)
- Things that still work
- What you can do to improve your experience if you insist on doing this
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.
Additionally, EOP does implement 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. IP
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, 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.
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.
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.
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.
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.
The content filter is not impacted.
What you can do to improve your experience if you insist on doing this
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.