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
I had a ticket open with a 3rd party Microsoft vendor that alluded to the possibility that the 'mydomain.mail.onmicrosoft.com' records were the reason for the spoofing attacks in how they are able to find that our domain/tenant exists in the M365 cloud. Then the attacker used the DirectSend for the attack. I opened a ticket with Microsoft to have those MX records updated since we don't own the .onmicrosoft.com domain. Why is it that we can't change those MX records? That would would help tremendously to ensure that ALL of our stuff is not pointing directly to the cloud.
With that being said, we personally follow and have strict SPF, DKIM, and DMARC in place and this attack STILL bypassed all of those. When I analyzed the message headers, they stated ALL failed... including ARC, and yet a couple of messages still go through. So anything regarding that DirectSend was protected by these is false.
Here's what I think we all need to see changed is the tenant lockdown... all tenants, need to be treated like an on-premise system. I get that there are things in place like Defender, Forefront, etc, but if I have a 3rd party (i.e Barracuda, Proofpoint, etc), and I want that to be front door, I should have the means and control to ensure ALL emails flow through only the front door. That's the way my on-premise is setup. There are no windows or other doors that it can be accessed. My tenant needs to be the same. Introducing features like this and have a 'default' inbound connector that a tenant admin cannot control or touch only leaves to more vulnerability. Yes I know Microsoft publishes articles on best practice and how to secure your tenant, but it should closed off completely by default. I shouldn't have to make changes in the defender portal anti-spam policies if I have other protections in place. I do have an inbound connector built to reject all emails coming directly to the tenant. In hindsight, I should not have to build that. I should not see messages quarantined in the Microsoft defender because of attempted access through an open protocol/port that I can't control or is on by default.
are you positive your anti-phishing policy has 'honor dmarc' set to reject/quarantine and high confidence phishing to quarantine/reject? What none of these MS blogs and other articles state very clearing is that:
There is no direct send issue if:
- you have dmarc setup in dns to reject/quarantine with proper alignment
- your O365 anti-phishing policies have the proper reject/quarantine setting as mentioned above
I have done multiple tests, we do not have DirectSendReject to $true, O365 properly quarantines or rejects 99% (depending on the domain I test with) of the emails when it looks like it's a direct send attack in the headers (99% of my test emails are quarantined/rejected). I am dealing with them on the remaining percentage that gets delivered.
- Mithun_Rathinam
Microsoft
The *.mail.onmicrosoft.com domain is automatically assigned to a Microsoft 365 tenant and used internally by Microsoft for mail routing (especially in hybrid setups). You can't change or remove its MX records because Microsoft owns and manages the onmicrosoft.com domain and its DNS records , tenants have no control over them.
Attackers may exploit DirectSend if the tenant is misconfigured, but the MX record itself isn’t the root cause; it’s about how your tenant is configured to accept mail.
Additional explanations have already been shared with you in other chats by me and Arindam.
