Short for mail exchange record, an MX record is an entry in a domain name database that identifies the mail server that is responsible for handling e-mails for that domain name. Multiple MX records can be created and are assigned a priority, which a sending server uses to determine which server is responsible for receiving the email for a specific domain.
Microsoft launched Exchange Online Protection (EOP) in 2014, nearly five years ago. This service emerged out of Microsoft's acquisition of FrontBridge Technologies all the way back in 2005. EOP is included in most Office 365 plans and handles "table stakes" mail protection tasks like spam and signature-based malware filtering.
Exchange Online Protection deploys as the MX host for the customer's Office 365 tenant, making it the front door for email arriving from the internet. As such, it blocks the 40-70% of inbound email that is clearly spam, obviating the need for the downstream Exchange server to waste CPU cycles processing -- and disk space storing -- all of it.
Unfortunately, the standard Bayesian statistical techniques EOP and other spam filtering systems use don't work very well for more sophisticated malware or phishing emails. Even Microsoft's add-on protection service, Advanced Threat Protection (ATP) struggles to identify the majority of targeted phishing attacks.
Many vendors, therefore, offer their own alternative to ATP -- claiming that they block more malware and phishing attacks -- and these third-party systems also replace the Microsoft MX servers, becoming the customer's new, alternative MX host.
The main reason for this architecture is historical: until recently, the only way for a third-party service to process a customer's mail was to serve as the public-facing MX host; there simply was no other mechanism to get a third party into to the mail flow.
The problem, though, is that changing MX hosts is a pain. It requires the customer to modify DNS records, and these changes take time to propagate around the internet, during which interval some email will go to the old MX and some to the new. An MX cutover is also all-or-nothing: there's no way to test a new MX on just a subset of users' accounts, for example.
The good news is that all this has changed over the last few years. Microsoft now offers two new, less invasive ways to integrate mail processing services into the Exchange / O365 ecosystem -- without the hassle and disruption of changing MX records.
The first of these is the Microsoft Graph API, often called "the API" in the context of email*.
This API allows third party services to query a customer's delivered email, and the great news is that it requires nothing more to set up than an oAuth authentication by a customer Exchange/O365 admin, which takes less than a minute.
Because it's so simple, several vendors offer spam, malware, and phishing prevention services that integrate via this API. For many uses cases this kind of integration suffices and eliminates the need to touch the public facing MX record.
There are challenges with API integration, however. One significant limitation is that it can only process delivered email, while customers often wish to block phishing and malware before it gets to user inboxes. It's possible to (sort of) work around this by moving dangerous mail to the Junk/Spam folder soon after it is delivered, but this still leaves a brief window wherein a user might interact with a malicious email.
It's also worth noting that Microsoft really intends API access to be used by ancillary services; it's not meant for services that process 100% of a company's email. This means that it's subject to usage limitations, rate throttling and other controls that may limit scalability. In contrast, an MX solution scales arbitrarily as long as the third party provides enough servers and bandwidth to handle the load.
On the other hand, the Microsoft Graph API is useful for analyzing historical mail -- something that an MX-based solution can't do unless it archives all the incoming mail itself. API-based services can also see internal mail between employees -- not just inbound mail from the internet.
Another integration option in O365 is Microsoft Exchange Connectors (or "connectors" for short). Connectors allow third party services to insert themselves directly into the mail flow, downstream from the public-facing MX. This leaves the primary MX in place for basic spam filtering, while giving the third party the ability to analyze and block or quarantine malicious email before it gets to end users. Connectors can be configured to process just incoming or both incoming and internal emails. Connectors can also be limited to only certain recipient mailboxes, which allows a staged rollout of new mail services rather than the all-or-nothing cutover of an MX solution.
What's especially convenient about connectors is that they can be configured to run after the MX but before the normal Exchange mail flow rule processing. This means that a third-party connector can analyze an email and then add its own header to the email— a phishing score, for example—which standard Exchange mail flow rules can later reference.
Our INKY Phish Fence service, for example, typically deploys as a connector. It analyzes each mail and add its own score headers; customers can then determine the disposition of each mail based on INKY's analysis using mail flow rules—e.g., "if INKY's score says the mail is likely phish, move it to quarantine". This is great, because most Exchange admins already work with mail flow rules and editing them requires no new authentication credentials. So, it's easy and familiar.
The best of both worlds, we've found, is a hybrid deployment using both the API and the connector mechanism. For O365 INKY Phish Fence deployments we use connectors to install our service inline and therefore enable quarantine of dangerous emails prior to delivery. Running inline means we can also modify each email to add our own headers and user-friendly warning banners.
But we also use API access to support quick demos (an admin oAuth is all it takes to get started), perform historical analysis, and remove mail that has already been delivered but has subsequently been convicted as malicious.
And while we can support traditional MX-based integrations as well, there is really no reason in 2019 to favor this deployment model—at least within the Microsoft ecosystem.
Really the only remaining reason to favor an MX-based deployment is when you are looking not just for protection but redundancy as well. If you are concerned that Microsoft may go down—leaving your users locked out of their inboxes—you might consider an MX-based solution that archives all your inbound mail and makes it available via its own alternative interface.
To our minds unless it's really a backup service you're looking for, you should look to modern deployment options like the Graph API and Exchange Connectors and forgo the legacy MX host shuffle.
*an earlier API called Office 365 REST API is being retired in favor of the newer Graph API.