Microsoft continues to improve the security foundations of Exchange Online, this time by focusing on DNS — a core but often overlooked part of email transport. In an April 2026 update, Microsoft outlined progress on introducing modern DNS protections for Exchange Online mail flow, including support for DNSSEC, SMTP DANE, and MTA-STS.
While most administrators spend time securing mailboxes, policies, and identities, mail delivery still depends on infrastructure protocols that were designed decades ago. DNS remains one of them. The protocol works well, but by default, it does not verify authenticity or integrity. That leaves room for spoofing, tampering, and interception.
Microsoft’s latest work aims to close that gap.
The Missing Security Layer in Email Delivery
When someone sends a message to your organization, the sending system must first discover where your domain accepts email. That means querying DNS for MX records. The assumption has always been simple: ask DNS, trust the answer. That trust model has become increasingly problematic.
DNS requests are traditionally unauthenticated. If an attacker can interfere with DNS resolution — through spoofing, poisoning, or redirection — they may be able to influence where mail is delivered or how transport security is negotiated.
That’s where Microsoft’s recent work matters. The company is strengthening how Exchange Online validates the path mail takes before it reaches the service.
Microsoft’s DNS Security Push
The announcement covers three technologies:
- DNSSEC
- SMTP DANE
- MTA-STS
These aren’t new standards, but broad adoption has been slow because setup can be complex, especially in hybrid environments.
Microsoft is trying to make adoption easier while enabling stronger defaults across Exchange Online.
DNSSEC Enablement Wizard Arrives in 2026
One of the most practical additions is a new DNSSEC Enablement Wizard planned for the Exchange admin center in Q3 2026.
This is likely the most useful part of the announcement for tenants considering inbound SMTP DANE.
The wizard will:
- validate DNS prerequisites,
- provision a dedicated DNSSEC-capable mail endpoint,
- assist during MX cutover,
- prepare domains for SMTP DANE.
That’s important because DNSSEC adoption has often required multiple manual steps involving registrars, DNS providers, and record validation. Microsoft moving some of that into the admin center should reduce deployment friction.
PowerShell will still be required to fully enable SMTP DANE enforcement, so this isn’t a complete GUI experience yet.
Better Control for Outbound Connectors
Microsoft also introduced new control for outbound connectors.
This change started rolling out in February 2026 and adds two parameters:
MtaStsModeSmtpDaneMode
These apply to outbound connectors and allow organizations to decide how Exchange Online handles validation when delivering mail externally.
The three modes are straightforward:
1. Opportunistic
This remains the default. Exchange attempts validation when possible but still sends mail if the receiving domain doesn’t support DNSSEC or MTA-STS.
This works well for compatibility but provides weaker guarantees.
2. None
Validation is disabled. This may be necessary for certain legacy partner routes, but it removes protections that help prevent downgrade attacks and redirected mail flow.
Using this option should be deliberate.
3. Mandatory
This applies to SMTP DANE. Exchange requires successful validation and queues mail if the destination cannot satisfy the requirement.
If validation never succeeds, mail is rejected.
This is the strongest mode and likely the best fit for regulated organizations that require assured secure transport.
The Delayed MX Transition
One notable part of the announcement is what hasn’t happened yet. Microsoft previously discussed moving accepted domains to dedicated DNSSEC-enabled endpoints under the mx.microsoft namespace. That work is now delayed until the second half of 2026.
This suggests the backend changes are more complex than originally expected. That’s unsurprising. Any change affecting global mail routing at Microsoft scale touches service reliability, customer DNS dependencies, and large operational risk.
Microsoft is being cautious, which is sensible.
mail.protection.outlook.com Stays the Same
Another point worth noting is that mail.protection.outlook.com is not receiving DNSSEC. That means organizations wanting DNSSEC-protected inbound mail will still need to transition to Microsoft’s dedicated DNSSEC-capable subdomains under mx.microsoft. This matters because many tenants may assume Microsoft would simply update the existing mail endpoint.
That isn’t the plan.
The existing domain will, however, gain TCP and EDNS support later in 2026. That improves reliability and gives Microsoft more flexibility for future enhancements.
Closing Thoughts
Microsoft often focuses announcements on user-facing security features — Copilot protections, Defender improvements, identity controls. This update is different. It addresses the infrastructure underneath Exchange Online.
The security of email doesn’t begin in the mailbox. It begins when one server tries to find another. By modernizing DNS validation and transport verification, Microsoft is tightening a layer that has remained largely unchanged for years.
It’s not a dramatic feature release, but it is a meaningful one.
And for organizations serious about transport security, it’s worth tracking as these changes continue through 2026.
