Securing Direct Send in Exchange Online: closing the gaps in EOP-based MX setups

Table of Contents

In the previous article we explored how to identify emails sent via Direct Send in environments where the MX endpoints are configured to route through third-party services. Now, we’ll focus on detecting and securing Direct Send usage in tenants whose MX records point to Exchange Online Protection (EOP).

Use Case

This article guides organizations with EOP-based MX setups on how to monitor Direct Send usage before considering tenant-wide deactivation.

If you’re unfamiliar with Direct Send in Exchange Online, check out the previous article where we break down its behavior and use cases in environments with third-party MX configurations.

Securing the tenant

In this section, we’ll explore how to analyze mail flow to detect messages sent via Direct Send when your MX records are configured to point to Exchange Online Protection (EOP), Microsoft’s email filtering service. We’ll then explore alternative configurations to enhance the security of outbound email delivery. Finally, once Direct Send usage has been ruled out, we’ll walk through the steps to safely disable it within your environment.

Prerequisites

Minimum roles and permissions:

To access Advanced Hunting in Defender XDR:
- Email & collaboration metadata (read) under Security operations / Raw data in Defender XDR Unified RBAC or
- Security Reader in Defender XDR Email & collaboration roles

Licenses:

Microsoft Defender for Office Plan 2

Checking Direct Send usage

As we covered in the previous article, Direct Send only supports intra-organization emails, where both the sender and recipient domains are listed as accepted domains in your Microsoft 365 tenant.

However, to accurately identify which emails are being sent using Direct Send, it’s important to first understand how mail typically flows when intra-org messages are sent through legitimate, authenticated methods. These standard flows, such as sending via Outlook client and OWA, are handled internally by Exchange Online and bypass SPF checks.

We can confirm this behavior by running the following KQL query in the Advanced Hunting section of the Microsoft Defender portal:

EmailEvents
| where SenderFromDomain in ("your-accepted-domain-1", "your-accepted-domain-2", "your-accepted-domain-N") and RecipientDomain in ("your-accepted-domain-1", "your-accepted-domain-2", "your-accepted-domain-N")
| where isempty(Connectors) and EmailDirection == "Intra-org"
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, AuthenticationDetails, NetworkMessageId, SenderIPv4, EmailDirection, Connectors

Now let’s take a closer look at one of the emails returned by the KQL query above by opening it in the Microsoft Defender portal. This allows us to inspect the message headers, helping us validate whether the email was truly sent via an intra-org flow.

From the Analysis blade, copy the message header and paste it to the Message Header Analyzer.

In the results, we need to look for two specific headers to confirm that the message was sent through a legitimate intra-org flow:

X-MS-Exchange-Organization-MessageDirectionality should be set to Originating, indicating that the message originated from within the organization—either from Exchange Online or via an authenticated on-premises inbound connector.
X-MS-Exchange-Organization-AuthAs should be set to Internal, confirming that the sender was an authenticated mailbox in Exchange Online.

Now that we’ve confirmed these emails were sent from a system that Exchange Online recognizes as authenticated, we can return to the KQL query results and examine the AuthenticationDetails column.

We’ll notice that all emails classified as IntraOrg lack SPF information in this field. This is expected because when a message is marked with X-MS-Exchange-Organization-MessageDirectionality: Originating and X-MS-Exchange-Organization-AuthAs: Internal, it bypasses external filtering mechanisms such as SPF validation, spoof verdicts, phishing detection, and anti-impersonation controls.

Info

Sender Policy Framework (SPF) is an email authentication protocol that allows domain owners to specify which IP addresses are authorized to send mail on their behalf. When properly configured, SPF helps receiving mail servers verify that incoming messages claiming to be from your domain are legitimate. This protects other organizations and recipients from spoofed emails that could otherwise appear to come from your domain, enhancing your domain’s reputation and contributing to a more secure email ecosystem.

Now that we understand how to identify standard mail flow, let’s build a KQL query to detect emails sent using Direct Send.

EmailEvents
| extend auth = parse_json(AuthenticationDetails) | where isnotnull(auth.SPF)
| where in ("your-accepted-domain-1", "your-accepted-domain-2", "your-accepted-domain-N") and RecipientDomain in ("your-accepted-domain-1", "your-accepted-domain-2", "your-accepted-domain-N")
| where isempty(Connectors) and EmailDirection == "Inbound"
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, AuthenticationDetails, NetworkMessageId, SenderIPv4, EmailDirection, Connectors

The EmailDirection field set to Inbound identifies messages that are received from outside the organization. These emails typically include the following headers:

X-MS-Exchange-Organization-MessageDirectionality: Incoming, indicating that the message did not originate from within Exchange Online or an authenticated inbound connector.
X-MS-Exchange-Organization-AuthAs: Anonymous, meaning the sender was not authenticated and the message originated from the internet.

This combination confirms that the message was treated by Exchange Online Protection (EOP) as external, even if both the sender and recipient domains are accepted domains within the tenant. As a result, all filtering mechanisms apply, including SPF validation.

If the Direct Send configuration is legitimate, meaning the sending IP address is properly included in the domain’s SPF record, the email will pass SPF checks. Otherwise, it will not pass SPF, either due to a hard fail or a softfail, depending on how the domain’s SPF record is defined. This makes SPF a reliable indicator for detecting Direct Send usage and identifying misconfigured or unauthorized devices attempting to send mail on behalf of your domain.

Are You Exposing Your Tenant to Risk by Using Direct Send?

If your domain’s MX record points to Exchange Online Protection (EOP) and your SPF record is properly configured to include Microsoft 365 (include:spf.protection.outlook.com), you’re in an acceptable position, even if Direct Send is enabled. In this configuration, any unauthorized sender attempting to spoof your domain will fail SPF validation, ensuring that only trusted sources can deliver mail successfully.

Additionally, if you’re using Direct Send from specific IP addresses (such as on-premises devices or applications), those IPs should be explicitly listed in your SPF record to pass validation. In this scenario, however, it’s recommended to use SMTP Relay (see next section) for a more secure setup.

Once SMTP Relay is in place and SPF is correctly configured, Direct Send can be safely disabled to further reduce exposure to unauthenticated mail flow.

Disabling Direct Send for the tenant

Details on disabling Direct Send, along with guidance for handling workloads that still rely on unauthenticated submission, have already been addressed in the previous article.

Conclusion

Direct Send in Exchange Online can be a hidden vulnerability, and if your organization doesn’t rely on it, disabling Direct Send improves security. For legacy systems that still need it, use authenticated connectors to stay protected.