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.
Blog Post
8 Comments
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
Microsoft
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.
It would be great to be able to tell what connector and/or if DS was used for a given message. Where is the connector information in the Extended Message Trace data??? As previously mentioned, I am unable to locate it.
connector_id is meaningless gibberish, unique for every received message and I do not see it anywhere else...
Found an article that claims it is in custom_data field, but not finding it their either.
Can you provide an example?connector_id BL0PR1901MB4724\Default BL0PR1901MB4724 BL1PPF0258AA1FF\Default BL1PPF0258AA1FF BL1PPF0770E4D24\Default BL1PPF0770E4D24 BL1PPF2D3CE36FC\Default BL1PPF2D3CE36FC BL1PPF3852682CB\Default BL1PPF3852682CB BL1PPF637DB2734\Default BL1PPF637DB2734
SeanMSFTHi DeanTeam,
Definitely, please open a support ticket for an major bugs that deviate from the expectations set by this blog post. We'll look out for it. It is possible to identify the connector attributed to a message in the Extended Message Trace logs. It's identified in the Event Data column for the SMTP RECEIVE event with a format S:InboundConnectorData=Name=<NAME>;ConnectorType=Partner;
