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 Oct 06, 2025
Version 13.0
Blog Post
Direct Send is a bug, not a feature!
Direct Send enabled... Fully configured SPF, DKIM, DMARC(p=quarantine sp=quarantine pct=100), with Org, partner and "relay" connectors secured to specific IPs and we were getting Direct Send "SPAM".
Direct Send disabled and valid emails passing DMARC on those same locked down connectors are being blocked ! "Diagnostic-Code: smtp;550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources."
How can I authorize sources other than with locked down connectors?????
So enabled, direct send bypasses connectors and SPF/DKIM/DMARC, but disable it and it blocks things on those same connectors that pass all inspections...
Our testing so far appears to tie at least some of the rejected by DS messages when they are send from a valid tenant mailbox address to another valid tenant mailbox address. Sending from an invalid tenant address on the same domain may/does not get blocked.
valid1@domain to valid2@domain fails. invalid@domain to valid@domain works.
Confirm have same issue as DeanTeam Have set flag to $True and a vendors email that sends using our domain is now blocked from direct send. Have Create a partner connector and this has made zero difference, still blocked with the "Direct Send not allowed for this organization from unauthorized sources." error. Will see if we need the new connector needs to be active for 24/48 hours and will test again.. but at this stage the setting looks like a bust
Have now set the rejectdirectsend flag to $false. Even with a partner connector that used the IPs from which mail was sent, it would get rejected.
I think the report that shows what is using DirectSend is important, and such a report should be available to O365 admins before it is made GA.
- Arindam_Thokder
Microsoft
DeanTeam - Direct Send really is how any SMTP server works - it listens on port 25 and accepts messages addressed to recipients within the tenant's accepted domains. However, by design, basic SMTP protocol is vulnerable to spam attacks, as it lacks built-in mechanisms to effectively prevent them.
In your case, you've implemented strong protections: Fully configured SPF, DKIM, DMARC(p=quarantine sp=quarantine pct=100), with Org, partner and "relay" connectors secured to specific IPs for your organization. These measures should effectively block unauthorized email. Any illegitimate messages should either be directed to the Junk Mail folder or quarantined.
In your case, enabling or disabling Direct Send is largely irrelevant, because you anyway are not accepting email from any unauthorized source, you already blocked that by "connectors secured to specific IPs".
If someone does not have such connector, the EOP policies should junk/quarantine those messages because you "Fully configured SPF, DKIM, DMARC(p=quarantine sp=quarantine pct=100)". If this is not happenning, chances are high that your EOP/MDO policies are not configured properly.Is there any way to identify or message trace in 365 the messages that are either being allowed or blocked by Direct Send depending on if it is enabled or not?
What if any Delivery Status would they appear as? I am not immediately seeing them in Failed or SPAM status.
Without some way of tracking them, I don't know how we are going to be able to troubleshoot this.I agree, that is how it should work, but that is not how it actually appears to be working in the wild.
Enabled, Direct Send appears to bypass all connector restrictions, which appears to be as designed. "“Anonymous” in this context means that the messages are not attributed to any mail flow connector when they are sent to Exchange Online."
However, disabled, Direct Send starts blocking valid messages on the same restricted connectors, most apparently so far, when they are both to & from valid tenant mailbox addresses as if it has some undocumented anti-spoofing logic is built in???
The real troubleshooting challenge is that so far, I have not found a way to identify the incoming connector that a message traverses or doesn't in the case of direct send. It does not appear to be logged in the headers, and the "connector_id" field in an extended Report Message trace does not appear to correlate to an actual Mail Flow connector in any intelligible way...
I am willing to open a support ticket with our MSP, but in my experience, it will be impossible to escalate it to the level required to find an technician/engineer capable of understanding and troubleshooting something at this level of complexity and newness.- Arindam_Thokder
We tested the scenario again today in our lab and it is working as expected. If you have a different experience, as mentioned by Sean, please make sure the email is attributed to the correct connector using extended message trace data. If it is attributed to the inbound connector and email is still getting blocked by REJECT DIRECT SEND setting (and not by any other filter), please open a support ticket.
