Both Microsoft 365 and G-Suite include their own email filters for spam, phishing and malware. When you deploy an external email gateway, however, you must put them on the server’s “Always Trust” list, disabling these built-in protections. This configuration effectively turns off the built-in layer of protection you have already paid for. 

Why do gateways tell you to disable built-in security?

Every SEG vendor provides detailed instructions on bypassing the native filters in their deployment instructions.

Because they act as a Mail Transfer Agent (MTA), gateways receive every inbound message and then send it along to your real email servers from a single set of IP addresses. 

This breaks most every form of email authentication, verification and reputation that the industry has developed to prevent phishing. Sender Policy Framework (SPF), DomainKey Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC) all fail because, from Microsoft’s or Google’s point of view, your gateway is essentially spoofing every email server in the world. 

If you did not disable the built-in Google or Microsoft protection, every single one of your inbound emails would fail authentication and be sent to the junk folder. 



 

This is the fundamental and inherent flaw in the gateway architecture.

What’s the harm of disabling native protection? 

Industry best practices promote defense-in-depth, layered security with the assumption that at some point, a single layer will fail. By implementing several independent layers, the likelihood of an attack coming through drops dramatically. 

This is even more important when attackers know your first line of defense. For external gateways, it is a matter of a simple DNS MX lookup. 

 

Your choice of email gateway is not a secret.

 

One of the ironies of deploying an external gateway is that it may result in less security than having no external gateway at all. In a recent report, we demonstrated an attack that Microsoft knew to block as a malicious email but because the Secure Email Gateway was added to its Trusted Sender list, the attack got through. 

Here is the header from an email that would have been caught by Microsoft had it not been disabled.

 

 

What will your vendor tell you? 

This problem is inherent to the gateway architecture.

Many of these gateways are starting to offer email security via API, which is what Avanan does. Avanan pioneered this a number of years ago, and was routinely dismissed by the gateway players. Now, these gateways have realized the advantages of deploying via API. However, as Gartner has noted, there is nothing inherently different about these offerings than what is on the market, because they are still unable to get around Avanan's patent, which allows it to automatically deploy inline, before the inbox. 

The gateways may tell you that one layer of security is enough, but this does not consider:

  • The fundamental tenet of Defense-in-Depth security is multiple layers of protection.
  • While Microsoft and Google have their own vulnerabilities, it is better to augment them than disable them altogether.
  • You have already paid for Microsoft and Google’s filters.

It's no wonder, then, that the gateways are trying to figure out new ways of securing email.