In today’s evolving threat landscape, organizations increasingly rely on layered email security solutions to protect users and sensitive data. Microsoft supports and collaborates with Integrated Cloud Email Security (ICES) vendors that work in conjunction with Microsoft Defender, and customers who choose a layered approach to email security to ensure the maximum level of email protection.
It is, however, key that when integrating ICES solutions with Microsoft Defender, to follow best practices to maximize security and operational efficiency.
In this blog, we explain these best practices in more detail and outline three other routing techniques commonly used across ICES vendors. This will allow organizations to understand the impact of non-standard mail routing configurations on their security operations (SOC) effectiveness and partner with their ICES vendors on the best approach.
Best practices for ICES vendor integration
Microsoft has outlined best practices for third-party solutions integrating with Microsoft 365, where recommended and supported approaches include DNS mail routing or the Graph API. This article provides more details on these approaches and also outlines integration techniques that we do not recommend. By using these best practices, any 3rd party email security vendor can ensure that their solution works seamlessly alongside Microsoft Defender. In addition, we recently launched the Microsoft Defender ICES vendor ecosystem. This gives partners an additional option for integration, where we partner directly with the solution provider to build a deeper integration between the ICES solution and Microsoft Defender. We harmonize telemetry, email verdicts, security policies, and more, to provide joint customers with optimized protection and SOC workflows in the Defender portal.
Non-standard email routing techniques used by ICES vendors
We know that as the ICES space evolved, several vendors integrated with Microsoft Exchange using non-standard email routing techniques, such as journaling, connector-based routing, and post-delivery actions. These functions were originally designed for different purposes. When deployed alongside Microsoft Defender, these integration approaches can introduce unique complexities for mail flow and SOC operations. Understanding how these techniques work and their potential impact is essential for making informed decisions about your organization’s email security architecture and are outlined below.
Journaling for email security benchmarking
Email journaling (Figure 1) is a legacy Exchange Online feature originally designed for archiving and to help organizations meet legal, regulatory, and organizational compliance requirements by recording inbound and outbound email communications.
Figure 1: Email routing when journaling is implemented
While journaling was designed for archiving and similar use cases, we know that various ICES vendors utilize journaling rules to route emails to the vendor’s test environment to evaluate the effectiveness of their solution. Journaling occurs before Defender filtering, so both solutions act independently and partially, complicating operational clarity for SOC teams.
This approach can lead to duplicate catch scenarios, therefore misstating the unique catch rate of the ICES vendor. If a journaled copy of a phishing email is routed to an ICES vendor, this occurs before it was filtered by Microsoft Defender. Consequently, both Microsoft Defender and the ICES vendor now simultaneously assess the message, and both solutions may act on it independently. This often results in duplicate catch scenarios and creates ambiguity around which solution blocked the threat, ultimately making it challenging to assess the true effectiveness of each layer. Some ICES vendors may consider every email they filter “a miss by Microsoft Defender”. However, as journaling occurs before Defender filtering, it’s generally an incomplete representation.
Therefore, we do not recommend the implementation of journaling for benchmarking or operational clarity purposes of ICES vendor solutions that operate next to Microsoft Defender.
Journaling + post-delivery actions
Some vendors combine journaling with post-delivery actions via Graph API or Exchange Web Services (EWS). This approach enables them to take remediation actions on emails after they have been delivered to users’ mailboxes, such as moving messages to the Junk folder or adding labels to alert users of potential threats. However, if Defender quarantines a message first, the ICES vendor may not be able to perform these actions, limiting their impact. Furthermore, when a vendor deletes and recreates a message using EWS, it can result in duplicate message IDs, which fragments SOC visibility and slows incident response. As a result, these configurations should be avoided, as they can lead to unreliable investigations and operational complexity.
Connector-based implementations
Connectors are typically used to route mail between Exchange Online and on-premises or non-Microsoft systems. Some vendors repurpose this mechanism to:
- Route messages out of Exchange Online after Microsoft Defender filtering.
- Apply their own filtering.
- Reinject the message as a new email.
Using connectors to send messages out of Exchange Online after Microsoft Defender filtering, apply additional vendor filtering, and then return them as new emails introduces major operational risks. Reinjecting messages strips the original sender authentication context (SPF, DKIM, DMARC), which can lead to false positives, duplicate quarantines, and inconsistent reporting across tools like Explorer, Advanced Hunting, and Message Trace in Microsoft Defender. With this configuration, SOC teams may see multiple message IDs for the same email, making it difficult to correlate events and accurately track message disposition. This also impacts post-delivery protections such as Zero-hour Auto Purge, which may fail or be misapplied. These issues increase investigation time, reduce visibility, and can undermine existing protections, impacting the overall security of an
organization. That’s why our documentation states that we strongly recommend avoiding this configuration.
When assessing statistics or performance claims about Microsoft Defender’s effectiveness, it’s important to keep in mind how deployment configurations can shape outcomes. As outlined above, techniques such as journaling, connector-based routing, and post-delivery actions may introduce complexities that affect how performance is measured. These integration approaches can result in discrepancies within metrics, making it challenging to accurately attribute detections or gauge overall effectiveness. It is essential for security leaders and SOC teams to interpret results and make informed decisions about your organization’s email security posture.
Microsoft’s commitment to effective ICES vendor integration
By understanding the impact of the various integration techniques, security leaders can ensure their layered email security delivers streamlined SOC workflows and the highest level of protection for email.
Microsoft is committed to working collaboratively with all ICES vendors to help them embrace best practices in integrating with Microsoft Exchange so they can work effectively alongside Microsoft Defender. Whether using the documented best practices with Microsoft Exchange or joining the Defender ecosystem to build an even deeper integration, either approach will help ensure that the solutions work seamlessly alongside Microsoft Defender.
Learn more
Microsoft