Microsoft has announced a significant change in how new Accepted Domains in Exchange Online are provisioned with MX records. Between early and late July 2026 (previously February), MS will gradually switch provisioning of all A records for new Accepted Domains into the new subdomains under mx.microsoft.
*.mx.microsoft
At first glance, this may look like a minor technical adjustment. In reality, it represents a fundamental architectural shift that directly reinforces the security model I previously recommended around DNSSEC and SMTP DANE.
This article explains why the change matters, how it strengthens email security, and what you should be paying close attention to.
From Recommendation to Platform Architecture
In my earlier article,: https://www.thomasjuhlolesen.dk/2024/09/next-level-email-security-smtp-dane-and-dnssec-for-exchange-online.html
I outlined how DNSSEC and SMTP DANE together form a strong foundation for secure email delivery:
- DNSSEC ensures that DNS responses cannot be tampered with.
- SMTP DANE uses TLSA records to verify that mail servers communicate over encrypted channels and with the correct certificates.
- Together, they protect against:
- DNS spoofing
- Man-in-the-middle attacks
- TLS downgrade attacks
Microsoft’s new MX provisioning model is, in practice, a platform-level implementation of this exact security architecture.
By moving MX records into a controlled namespace under mx.microsoft, Microsoft can:
- Consistently sign MX records with DNSSEC
- Maintain a verifiable DNSSEC chain of trust from your domain all the way into Exchange Online
- Enable DANE scenarios more reliably without requiring customers to engineer complex workarounds
This is a clear signal that DNSSEC and DANE are no longer edge-case security features — they are becoming core components of enterprise email security…. This is GOOD news !
What Is Actually Changing, Technically
Before
Most organizations and automation workflows assumed a fixed pattern:
MX =
<domain>.mail.protection.outlook.com
This was often hardcoded into:
- Tenant onboarding scripts
- provisioning scripts
- Domain lifecycle workflows
- M&A and carve-out playbooks
- Security baseline templates
After July 1, 2026
That assumption no longer holds.
Under the new model:
- The MX hostname is dynamically provisioned under
mx.microsoft - The only source of truth becomes Microsoft Graph (i suspect GUI will show record also, but documentation is unclear)
- Specifically:
List serviceConfigurationRecords
which returns:mailExchange = <actual MX value>OR good ole Powershell
Connect-MgGraph -Scopes "Domain.Read.All"
Get-MgDomainServiceConfigurationRecord -DomainId "contoso.com"
This unique value — not a pattern, not a suffix, and not an assumption — is what must be published in DNS.
How This Strengthens DNSSEC and SMTP DANE
In my original guide, I recommended the following approach:
- Enable DNSSEC on your domain
- Update the MX record to Microsoft’s DNSSEC-compatible endpoint
- Enable SMTP DANE
- Validate TLSA records and mail flow
With Microsoft’s new architecture, step 2 becomes fundamentally stronger.
Previously: you had to explicitly switch your MX record to a DNSSEC-compatible endpoint.
In the future if your domain is DNSSEC-enabled at your registrar, the Microsoft automatically extends DNSSEC into their MX zone
This means:
- DNSSEC becomes default-enforced at the platform layer
- DANE operates on a more stable and trustworthy DNS foundation
- The risk of customer misconfiguration is significantly reduced
This is a major step toward making “secure by design” a practical reality for email infrastructure.
IMPORTANT notice – YOU as a customer STILL decides and enables SMTP DANE !
Conclusion
My original recommendation to implement DNSSEC and SMTP DANE in Microsoft 365 is not only still relevant — it is now directly supported by Microsoft’s own platform strategy.
With the MX change:
- DNSSEC becomes easier to deploy correctly
- DANE becomes more reliable in real-world operations
- Mail infrastructure becomes significantly harder to attack at the DNS and transport layers
For organizations operating in regulated industries, critical infrastructure, or mature cybersecurity programs, this represents a clear opportunity to:
Move email from “protected” to “cryptographically verified.”
