After our recent post Introducing more control over Direct Send in Exchange Online, there have been more questions about scenarios that are not actually Direct Send such as senders being able to ignore a domain’s MX record and send directly to an Exchange Online tenant. This post tries to address those questions.
How does mail flow work in Exchange Online?
Exchange Online is a cloud environment where organizations (tenants) can host mail services by signing up for a Microsoft 365 subscription that includes Exchange Online service. The tenant admin can set up users, and assign them a license, so they can use mail services.
Any tenant with an active Exchange Online subscription will have an endpoint that is automatically created for use by customers to configure their MX records. That endpoint is an easy-to-use replacement to having to use IP addresses. For example:
contoso-com.mail.protection.outlook.com
Note: This endpoint is not supposed to be a secret, and anyone can guess what it is. There is no security threat in anyone knowing this publicly facing endpoint. This endpoint has no authentication associated with it. It simply resolves to the IP addresses of our service. Someone could send an email to Contoso’s endpoint and address it to the mailbox of a different tenant and that email would be attributed to the actual recipient’s tenant in case where the tenants’ regions allow it.
For example, Contoso and Fabrikam are two different tenants hosted in Exchange Online. A sender uses contoso-com.mail.protection.outlook.com to connect to Exchange Online and sends an email to a fabrikam.com mailbox. That email is delivered directly to Fabrikam’s tenant and mailbox and Contoso’s tenant is not involved. Their (Contoso's) endpoint merely resolved to a shared IP used in the service.
We receive numerous claims of emails being relayed from one tenant to another by using this method which is incorrect. No relaying takes place from one tenant to the other.
While we offer a fully featured protection suite as part of Exchange Online and millions of customers trust us to receive emails directly, some customers choose more complex routing configurations that include setting their MX records to point to other filtering and relay services before emails are routed to Exchange Online.
Customers who choose to introduce complex routing into their mail flow need to understand the ramifications of doing so and take action to change the default behavior with which Exchange Online operates. As email was designed, by default, we accept all emails addressed to your mailboxes that are sent directly to us.
For organizations with complex mail routing needs, administrators can create custom connectors and mail flow rules to configure their mail flow. To learn more about connectors and mail flow rules in Exchange Online, you can check the following articles:
- Configure mail flow using connectors in Exchange Online | Microsoft Learn
- Mail flow rules (transport rules) in Exchange Online | Microsoft Learn
What is "Direct Send"?
Direct Send, as defined in the blog post linked above in detail, is the term used for sending emails directly to your mailboxes from a domain you own without any user or on-premises connector authentication. Direct Send is a method of sending emails to yourself when other options are not viable. If a customer does not use this method, we introduced a setting to turn it off so that any bad actors trying to spoof your own domains and send emails to your mailboxes are rejected outright. Direct Send emails could be sent to the MX record endpoint we provide or the endpoint that 3rd party service provide so that emails first route to them.
Direct Send and how to disable it is described in more detail in the blog post: Introducing more control over Direct Send in Exchange Online | Microsoft Community Hub.
Further information on how to use Direct Send for sending emails from a device or application can be found here: How to set up a multifunction device or application to send email using Microsoft 365 or Office 365 | Microsoft Learn
What Direct Send is not
Given the definition above, there is a scenario customers have been bringing up that is not “Direct Send” but the more general concept of sending directly to an Exchange Online tenant. With the publicly known and accessible Exchange Online provided endpoint, anyone on the internet can send emails to your tenant by default. That is how email works. Customers who introduce complex routing to their mail flow may define that ability as a “loophole” and might not like it. If that is the case, it’s a situation created by a configuration decision (complexity was added into email routing) which then needs to be closed.
How to secure against sending directly to your Exchange Online tenant when your MX is not pointed to Exchange Online?
In some cases where MX records for a domain are pointing to a service other than Microsoft 365, organizations may not want email to be delivered directly via their Exchange Online endpoint or may want to limit such email to ensure it is processed in a predefined way.
The recommended solution to secure this “email sent directly to your public Exchange Online endpoint” path is to configure the service to reject messages unless they come through defined inbound mail flow connectors. This can be achieved by creating an Inbound connector as recommended on step 4 in the support article mail flow best practices when using a third-party cloud service with Exchange Online to limit traffic to the specified connector by including the “RestrictDomainsToCertificate” or “RestrictDomainsToIPAddresses” depending on the connector type. With this configured, only mail that passes through an inbound connector is allowed into your tenant, otherwise it will be rejected. The above steps should be sufficient to protect against direct delivery to your tenant. However, you can also choose to enable “Reject Direct Send”, which will reject any emails where the P1 sending domain, envelope sender, is an accepted domain in the tenant unless these are attributed to a configured Inbound connector. For more details about this feature and how to implement it, please see the following article: Introducing more control over Direct Send in Exchange Online | Microsoft Community Hub.
“What if we are not ready to lock down the tenant or enable Reject Direct Send?”
If you are concerned about rejecting unknown legitimate mail traffic by securing sending directly, we recommend that you create a transport rule that quarantines or redirects all mail that is not coming from the remote IPs you approved.
Here is an example of mail flow rule configurations that could be used. The recommendation is to set the mail flow rule priority to zero to be processed before any other rules and enable “Stop Processing more rules”.
Please note that this example is simplified and that every organization may need to adapt the mail flow rule to their existing mail flow configuration and requirements. If any assistance is required with mail flow rule configuration, please contact Microsoft Support.
This mail flow rule will quarantine all emails, not coming from MX records IPs or on-premises IPs or from other authorized IPs sending emails directly to Exchange Online with or without a connector.
Rule parameters are:
- Apply this rule if: Apply to all messages
- Do the following: Deliver the message to the hosted quarantine and Stop processing more rules
- Except if: sender ip addresses belong to one of these ranges: ''MX records + on-premises IPs + other authorized IPs“
OR
- 'X-MS-Exchange-Organization-AuthAs' header contains ''Internal''
To do this through PowerShell, you can use the following command:
New-TransportRule -Name "Redirect to quarantine if not coming from known IPs" -Quarantine $true -ExceptIfHeaderContainsMessageHeader 'X-MS-Exchange-Organization-AuthAs' -ExceptIfHeaderContainsWords 'Internal' –ExceptIfSenderIpRanges ‘MX records + on-premises IPs + other authorized IPs ' -StopRuleProcessing $true -Priority 0
“How can we see all emails sent directly to our tenant (i.e. not through a connector)?”
There are a few ways to generate reports with emails received without an Inbound connector. For organizations that don’t have an Inbound connector created for the emails received from the 3rd party service used as MX records, the reports will include these emails too, so they need to be filtered out.
The following options are helpful when the MX is pointed to a third-party service. If the MX is pointed directly to Exchange Online, these options may display all inbound emails.
Option 1: Use the Historical Message Trace to generate a report with all inbound emails received without a connector. The report can be generated for the last 90 days:
Start-HistoricalSearch -ReportTitle DirectSendMessages -StartDate 07/01/2025 -EndDate 07/24/2025 -ReportType ConnectorReport -ConnectorType NoConnector -Direction Received -NotifyAddress admin@contoso.com
To generate the same report as above from the UI, you can use the Inbound messages report from Exchange Admin Center > Reports > Mail flow. Inbound messages and Outbound messages reports in the new EAC in Exchange Online | Microsoft Learn (Please note the exceptions where messages will not be included in these reports).
Option 2: Organizations that have Defender for Office P2 subscription can use Threat Explorer and Advanced Hunting to generate additional reports
If you use the following filter in Threat Explorer, it’ll show all emails received in the tenant without a connector and it can be generated for the last 30 days:
Directionality = Inbound, Connector > equals none of > list all the Inbound connectors in the tenant comma separated (without quotes).
Use the following queries in Advanced Hunting then use Export to CSV.
EmailEvents
|where Timestamp > ago(30d)
|where EmailDirection == 'Inbound' and Connectors == '' and isnotempty(SenderIPv4)
|project Timestamp, RecipientEmailAddress, SenderFromAddress, Subject, NetworkMessageId, EmailDirection, Connectors, SenderIPv4,
A query to summarize and count emails per sending IP address:
EmailEvents
| where EmailDirection == "Inbound" and Timestamp>= ago(30d) and Connectors == "" and isnotempty(SenderIPv4)
| summarize count() by SenderIPv4
Microsoft 365 Messaging Team
