Exchange Online: Microsoft strengthens DNSSEC, SMTP DANE and MTA-STS

Microsoft keeps strengthening DNS security around Exchange Online.

It is an important change for every organisation that runs business email.

For a long time, DNS remained a weak link in email transport: often unencrypted by default, unauthenticated by default and exposed to spoofing, MX hijacking or interception scenarios.

With DNSSEC, SMTP DANE and MTA-STS, Microsoft is pushing a simple idea: make the email delivery path reliable, not just the sender’s identity.

Official source: Microsoft Exchange Team Blog.

What Microsoft is announcing

Microsoft highlights several changes around Exchange Online and DNS / SMTP security.

The most important points:

• a DNSSEC wizard is due in the Exchange admin center in the third quarter of 2026;
• SMTP DANE and MTA-STS become easier to control on outbound connectors;
• administrators can choose the enforcement level depending on the flow;
• opportunistic mode remains useful to progress without abruptly blocking exchanges;
• mandatory mode for SMTP DANE lets you harden certain critical paths;
• new DNSSEC-capable endpoints use domains under mx.microsoft.

This is not just an admin feature. It is a clear signal: email security no longer stops at SPF, DKIM and DMARC.

Why DNS matters so much for email

When a server has to deliver an email, it relies on DNS to know where to send the message.

It looks up the MX records in particular, then opens an SMTP connection to the receiving server.

If this DNS layer is manipulated or poorly secured, an attacker may try to divert the message path, force a less secure connection or cause delivery to illegitimate infrastructure.

That is exactly where DNSSEC, SMTP DANE and MTA-STS become useful.

They do not replace SPF, DKIM and DMARC. They protect another level: the transport and DNS resolution used during delivery.

DNSSEC, SMTP DANE, MTA-STS: who does what?

These mechanisms share a goal but play different roles.

DNSSEC lets you cryptographically verify that DNS answers have not been altered. It helps reduce the risk of DNS spoofing or record manipulation.

SMTP DANE relies on DNSSEC to publish and verify the mail server’s TLS information. The goal is to make sure the SMTP server contacted presents the expected certificate.

MTA-STS lets a domain declare a TLS policy for receiving email. It helps compatible sending servers refuse insecure delivery when the policy requires it. Our article on MTA-STS and TLS-RPT details how it works.

In short:

• SPF, DKIM and DMARC answer: is this email legitimate for this domain?
• DNSSEC, SMTP DANE and MTA-STS rather answer: is the transport path reliable and secure?

The risk: an invisible but critical layer

DNS is often discreet in email projects. You change it during a migration, add an MX, an SPF record, a DKIM key, and then it drops off the radar.

Yet it is a critical layer.

A bad configuration or missing protection can open the door to several scenarios:

• hijacking or manipulation of MX records;
• adversary-in-the-middle attacks;
• downgraded TLS security in transit;
• delivery to the wrong infrastructure;
• routing errors that are hard to diagnose;
• loss of trust between technical partners.

These issues are not always visible to users. But when they break, the impact is direct: blocked emails, delivery delays, SMTP errors, lost trust or a security incident.

What this changes for administrators

The interesting new feature is granularity.

Microsoft gives administrators more control over outbound connectors, notably with modes that adapt the level of enforcement to the context.

In practice, this makes it possible to distinguish:

• standard flows, which can stay in opportunistic mode;
• sensitive partners, for which a stricter level can make sense;
• special cases, where temporary compatibility must be kept;
• environments in transition, where you want to move forward without causing an outage.

This is a good approach, because email security is not always deployed in a single block.

A critical flow with a well-managed partner can support strong enforcement. A legacy flow, poorly documented or dependent on an old SMTP relay, will often need analysis before being hardened.

Beware of the domino effect

These mechanisms affect email transport. They must not be enabled blindly.

A DNS change, an overly strict MTA-STS policy, mandatory DANE validation or a wrong endpoint can cause rejections or queued mail.

Before hardening, understand:

• which domains are concerned;
• which MX records are actually used;
• which outbound connectors exist;
• which partners receive critical flows;
• which third-party services are in the chain;
• which logs and reports let you check the results;
• how to roll back if a delivery fails.

The right strategy is gradual: test, observe, harden, monitor.

A checklist before enabling

Before moving to DNSSEC, SMTP DANE or MTA-STS on Exchange Online, a simple checklist helps.

Points to check:

• the state of accepted domains in Microsoft 365;
• the MX records in production;
• any third-party mail gateways;
• inbound and outbound connectors;
• existing MTA-STS policies;
• TLS certificates used on SMTP paths;
• the registrar’s ability to manage DNSSEC properly;
• available monitoring tools;
• errors visible in logs and message traces;
• the rollback plan in case of blocking.

This preparation keeps a security improvement from turning into a production incident.

What this says about where email is going

Email keeps evolving.

In recent years, requirements around SPF, DKIM, DMARC, spam complaints and reputation have advanced a lot. Gmail, Yahoo, Microsoft and the major providers are all pushing for more authentication and quality.

But the next step also plays out on the transport layer.

Email trust no longer depends only on message content or domain reputation. It also depends on how servers find each other, connect and verify the security of the path.

For companies, this means gradually mastering:

• DNS records;
• MX records;
• DNSSEC;
• MTA-STS;
• SMTP DANE;
• TLS certificates;
• connectors;
• the operational impact of a routing change.

Conclusion

Microsoft’s announcement is good news for email security.

It makes advanced mechanisms more accessible and easier to control in Exchange Online. That matters, because DNSSEC, SMTP DANE and MTA-STS can genuinely strengthen trust in email transport.

But this kind of change must stay under control.

Email is critical infrastructure: DNS or SMTP hardening is prepared domain by domain, with tests, monitoring, documentation and a rollback plan.

SPF, DKIM and DMARC remain essential. But they are no longer alone in the equation.

The next battle for email deliverability and security is also being fought at the DNS level.

To check your environment, see Dharmail’s Microsoft 365 and Google Workspace mail audit (page in French).