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 igno...
Updated Aug 07, 2025
Version 7.0
Blog Post
Mithun_Rathinam
Microsoft
MicrosoftJamesEpp , SPF validation does occur for direct send emails, but the final verdict based on CompAuth, can vary depending on where the domain's MX record is pointed.
Excellent post,JamesEpp
Mithun_Rathinam ,Arindam_Thokder
I understand why this behavior occurs, but I believe EOP should be more proactive in flagging spoofed senders—especially when emails don’t come from known connectors or trusted IPs. I’m investigating a similar case where, despite failing DMARC and SPF checks, an email sent from another M365 tenant and or Azure VM still gets delivered to user inboxes.
We have now restricted the partners mail connector by ip addresses only and disabled direct send.
In my case, I saw this:
compauth=none reason=451
compauth=none:
No composite authentication verdict was assigned.
reason=451:
This is a Microsoft-specific internal code.
Microsoft couldn’t confidently verify the message’s authenticity but didn’t find strong signs of spam or malicious intent.
Also, it’s concerning that the default anti-spam policy for all tenants has these two recommended settings turned off:
SPF hard fail (MarkAsSpamSpfRecordHardFail) – OFF by default
Sender ID filtering hard fail – OFF by default
Not sure why these aren’t enabled by default??
https://learn.microsoft.com/en-us/defender-office-365/anti-spam-policies-asf-settings-about
https://learn.microsoft.com/en-us/defender-office-365/recommended-settings-for-eop-and-office365#anti-spam-policy-settings