In part one of this series, we explained why Proofpoint and Mimecast customers might be susceptible to email attacks that other Office 365 and Gmail customers are not. After receiving numerous questions about the post, many of which asked for more detail, we have decided to write this follow up post. Here, we will show examples and provide technical details to further explain how introducing an MTA (a Mail Transfer Agent that changes your MX record) will blind Microsoft and Google's default security to incoming threats.

How We Know

Avanan Deployment Diagram

Avanan is uniquely positioned to measure the effectiveness of Microsoft's email security. Because we connect via API, we are able to see the email after it has been scanned by Microsoft, but before it arrives in the user's mail box. This is true across all of our customers—regardless of if they use only Microsoft's default security, Advance Threat Protection (ATP), or an MTA before it reaches Office 365. This allows us to compare the effectiveness of each email provider's security during large phishing or malware outbreaks.

How It Was Discovered

A month ago, we reported on an attack that was bypassing both Microsoft's default security as well as Advanced Threat Protection. Eventually, Microsoft learned to detect this particular threat, and we stopped seeing the malicious messages.


We continued to see (and block) these malicious messages on a handful of customers. For nearly a week, our engineers could not understand why only these accounts were affected. Eventually, we discovered what these customers had in common: all of them had an MTA email security product deployed.

Somehow, the malicious mail was getting by the MTA gateway, but also bypassing Microsoft's own security—which we knew should have been able to block it. 

Why Is Microsoft Missing It?

Microsoft's built-in security misses this threat because in order to deploy any MTA Email Gateway like Mimecast or Proofpoint, the customer must first disable Office 365's own built-in security.


One of the most basic email checks is the SPF and DKIM authentication of the sending SMTP server. This validates that an email from "" truly came from "". However, when you change your MX record and send it through an MTA gateway, every email is sent from the MTA IP address and fails both of these fundamental checks. 


So, in order to prevent Microsoft from rejecting every email sent by the MTA gateway, you must put the Proofpoint and Mimecast servers on a list of "Trusted Servers". 

"To ensure emails are delivered from Mimecast to Office 365, the Mimecast service IP Ranges should be added to the Allowed List in the Connection Filtering Policy within the Office 365 Exchange Admin Center (EAC).” - Mimecast Deployment Instructions 

Unfortunately, this "Allowed List" transport rule effectively by-passes Microsoft's own protection.

You can see this in the header of every email that uses an MTA (see Microsoft Message Headers).

Email header analysis

mta deployment diagram


So, from Office 365's perspective, this IP address that belongs to Mimecast is marked as a trusted sender for every email. Therefore, every email will bypass Microsoft's filters and be delivered to the user's inbox. If the MTA misses a malicious email, Microsoft's own security will never never see it.

This would not be a problem if the MTA caught 100% of attacks, but this is not always the case, especially in the first hours or days of an event. From a ‘defense-in-depth’ perspective, it is disheartening to know that in order to deploy a second layer of security, you must essentially disable the first.

So, to be clear: this is not about Mimecast or Proofpoint missing a particular email. All security tools miss some. What we are demonstrating is that replacing one security (Microsoft) with another (Proofpoint or Mimecast) might fail you in many cases. This is why the best-practice in security is the multi-layered approach where several solutions work in sync because the landscape is constantly changing and no single vendor will catch everything.

How Is Avanan Different?

avanan deployment security stack

First, Avanan adds security to Office 365 default security, rather than replacing it. Working via API, we scan emails after they pass through Microsoft's filters, but before they reach the inbox—focusing specifically on what they miss. Because we connect directly to Microsoft's back end, we can analyze and block a malicious email before it gets to the user's inbox.

Second, deploying via API offers 100% visibility and more advanced enforcement. Because we are working within Microsoft's infrastructure, we can monitor inbound, outbound and internal email that would normally be missed by an external email gateway. In fact, we can go back in time and search the company's inbox for past attacks, identifying compromised accounts. (In one case, we identified an ongoing insider threat that originally started within an account that had been disabled when the employee left a year before.) More importantly, we can reach into a user's inbox and quarantine emails that are discovered to be malicious after they are delivered. (For example, when it was discovered that an internal account had been compromised, we were able to quarantine every previous email sent by that account across the enterprise.)

Third, we are not one security company, but the combined intelligence of 60+ of the industry's most advanced vendors - practically all the leading names in security. Because no single company can be 100% accurate, 100% of the time, we scan each email with multiple tools in parallel, improving detection rates and reducing false positives with no additional latency. Because we are entirely cloud-based, we can offer this full-stack security as a one-click deployment that is often cheaper than the MTA alternative.  

Avanan is the only way to deploy true defense-in-depth, multi-layer security for cloud-based email.