Update 8/12/2025: Added the FAQ to the post. Also, to help shed more light on the Direct Send feature, we published a newer post called Direct Send vs sending directly to an Exchange Online tenant.
...
Updated Aug 29, 2025
Version 12.0
Blog Post
Arindam_Thokder
Microsoft
MicrosoftIf the email is blocked by Direct Send control, you won't be able to trace the message, because it will be blocked at the protocol layer with the following error-
The server response was: 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources.
The fact that you are able to run message trace for the message means it is not blocked by the Direct Send control.
Having said that, to see the connector data, you can run the following command (give it some time after sending the email so that the data is populated)
> Get-MessageTrace -MessageId "your message ID here" | Get-MessageTraceDetail | fl
In the output, you should be able to see the connector name like following-
You can also see the connector name under Email entity page (it will show the GUID of the connector)
How do we handle external sources that can send email in name of accepted domains (covered by SPF, DKIM and DMARC), but for which a connector is not possible or difficult to achieve? I am talking about third party platforms that are using cloud/hosted email services for distribution of email. I do not deem it to be wise to define connectors for these type of mails, for it will allow uncontrolled inbound traffic from these services going unchecked by DMARC coverage (namely DKIM, as SPF would be equally flawed for these types of setups)?
I guess this is expected behavior given what is outlined in the blogpost, but is there really no way for Microsoft to achieve this on Exchange Online side by for example having the protocol layer pass on an 'evaluation' to an intermediate layer which dictates the mail was received via Direct-Send or not. Then DMARC compliance should be evaluated and determine whether the email should be delivered to the inbox or not?
We are seeing this phenomenon with multiple of our clients who are taking the step to disabling Direct-Send.
Alisdair DouglasSuch services generally provide DKIM alignment capability now. DMARC authentication would suffice in such instances, though we do recommend use of inbound connectors where high volume traffic is expected inbound to the tenant from such services. Direct Send is really just sending directly to the mail server (in this instance, the mail server being O365), so essentially disabling direct send is saying "don't allow O365 to accept emails from my accepted domains unless it is via an authorized route.
Thank you for your reply, but unfortunately this is not what we are seeing with our customers.
- DMARC passing mails, be it via SPF, DKIM or both are still being rejected once Direct-Send has been disabled.
- We are able to resolve this by introducing a connector for the source IP's, but this brings me back to my original issue/question.
If you are interested, I have mail headers to illustrate the problem and an environment where we could test.- Alisdair Douglas
Direct Send really just means sending an email directly to O365. Generally this is what happens for every customer if their MX points to O365, but where customers expect their inbound traffic to come in via another route (or routes) then blocking Direct Send just essentially means preventing inbound emails bypassing their expected routing (ie where their MX record points, or their authorized servers send from). If the MX points to O365 then a restrictive DMARC policy action should be enough, no real need as I see it to block direct send as I see it.
Where MX points to a third party, we have published guidance for years advising the use of connectors to prevent attackers bypassing MX record and just smart-hosting directly to O365 Manage mail flow using a third-party cloud service with Exchange Online | Microsoft Learn as would be the case with any server or service that accepts inbound connections on port 25.