Microsoft is changing MX records in Exchange Online

๐Ÿ”’ Secure Bits ๐Ÿ’ก
๐— ๐—ถ๐—ฐ๐—ฟ๐—ผ๐˜€๐—ผ๐—ณ๐˜ ๐—ถ๐˜€ ๐—ฐ๐—ต๐—ฎ๐—ป๐—ด๐—ถ๐—ป๐—ด ๐— ๐—ซ ๐—ฟ๐—ฒ๐—ฐ๐—ผ๐—ฟ๐—ฑ๐˜€ ๐—ถ๐—ป ๐—˜๐˜…๐—ฐ๐—ต๐—ฎ๐—ป๐—ด๐—ฒ ๐—ข๐—ป๐—น๐—ถ๐—ป๐—ฒ (๐—๐˜‚๐—น๐˜† ๐Ÿฎ๐Ÿฌ๐Ÿฎ๐Ÿฒ) โ€” ๐—ฎ๐—ป๐—ฑ ๐—ถ๐˜ ๐˜‚๐—ป๐—น๐—ผ๐—ฐ๐—ธ๐˜€ ๐˜€๐˜๐—ฟ๐—ผ๐—ป๐—ด๐—ฒ๐—ฟ ๐—ฒ๐—บ๐—ฎ๐—ถ๐—น ๐˜€๐—ฒ๐—ฐ๐˜‚๐—ฟ๐—ถ๐˜๐˜†.

A change coming to Exchange Online in ๐Ÿ“† July 2026 will modify how new accepted domains receive their MX records. Instead of the traditional \*.๐˜ฎ๐˜ข๐˜ช๐˜ญ.๐˜ฑ๐˜ณ๐˜ฐ๐˜ต๐˜ฆ๐˜ค๐˜ต๐˜ช๐˜ฐ๐˜ฏ.๐˜ฐ๐˜ถ๐˜ต๐˜ญ๐˜ฐ๐˜ฐ๐˜ฌ.๐˜ค๐˜ฐ๐˜ฎ, Microsoft will start provisioning MX records under \*.๐˜ฎ๐˜น.๐˜ฎ๐˜ช๐˜ค๐˜ณ๐˜ฐ๐˜ด๐˜ฐ๐˜ง๐˜ต.

At first glance this looks like a simple DNS change. In reality, itโ€™s a foundational step toward ๐—ฝ๐—ฟ๐—ผ๐—ฝ๐—ฒ๐—ฟ ๐——๐—ก๐—ฆ๐—ฆ๐—˜๐—– ๐˜๐—ฟ๐˜‚๐˜€๐˜ ๐—ฐ๐—ต๐—ฎ๐—ถ๐—ป๐˜€ ๐—ฎ๐—ป๐—ฑ ๐—ฏ๐—ฟ๐—ผ๐—ฎ๐—ฑ๐—ฒ๐—ฟ ๐—ฆ๐— ๐—ง๐—ฃ ๐——๐—”๐—ก๐—˜ ๐—ฎ๐—ฑ๐—ผ๐—ฝ๐˜๐—ถ๐—ผ๐—ป ๐—ถ๐—ป ๐— ๐—ถ๐—ฐ๐—ฟ๐—ผ๐˜€๐—ผ๐—ณ๐˜ ๐Ÿฏ๐Ÿฒ๐Ÿฑ.

๐Ÿค” ๐—ช๐—ต๐˜† ๐˜๐—ต๐—ถ๐˜€ ๐—บ๐—ฎ๐˜๐˜๐—ฒ๐—ฟ๐˜€
This change is primarily about security architecture, not routing. The legacy MX namespace has historically made it difficult to establish a clean DNSSEC trust chain into Microsoftโ€™s mail infrastructure. With the new namespace, Microsoft can better support ๐—ฆ๐— ๐—ง๐—ฃ ๐——๐—”๐—ก๐—˜ ๐˜ƒ๐—ฎ๐—น๐—ถ๐—ฑ๐—ฎ๐˜๐—ถ๐—ผ๐—ป and authenticated TLS between mail servers.

In practice this enables:
– MX endpoints aligned with DNSSEC-enabled infrastructure
– Improved support for TLSA records used by SMTP DANE
– Stronger validation of server identity during SMTP TLS negotiation

๐Ÿ› ๏ธ ๐—ช๐—ต๐—ฎ๐˜ ๐—ฑ๐—ผ๐—ฒ๐˜€ ๐—ถ๐˜ ๐—ฑ๐—ผ
Most email on the internet still relies on opportunistic TLS, which encrypts traffic but does not strongly authenticate the destination server.

This leaves a gap where DNS manipulation or certificate attacks could theoretically downgrade or intercept mail delivery.

Technologies like ๐——๐—ก๐—ฆ๐—ฆ๐—˜๐—– ๐—ฎ๐—ป๐—ฑ ๐—ฆ๐— ๐—ง๐—ฃ ๐——๐—”๐—ก๐—˜ help close that gap by:
– cryptographically validating DNS responses
– publishing TLS expectations via DNS
– ensuring mail servers connect only to verified infrastructure

๐——๐—ก๐—ฆ๐—ฆ๐—˜๐—– ๐—ฝ๐—ฟ๐—ผ๐˜๐—ฒ๐—ฐ๐˜๐˜€ ๐——๐—ก๐—ฆ ๐—ฟ๐—ฒ๐˜€๐—ฝ๐—ผ๐—ป๐˜€๐—ฒ๐˜€ ๐—ณ๐—ฟ๐—ผ๐—บ ๐˜€๐—ฝ๐—ผ๐—ผ๐—ณ๐—ถ๐—ป๐—ด, while SMTP DANE uses DNSSEC-protected TLSA records to authenticate the receiving server and ๐—ฝ๐—ฟ๐—ฒ๐˜ƒ๐—ฒ๐—ป๐˜ ๐—ฑ๐—ผ๐˜„๐—ป๐—ด๐—ฟ๐—ฎ๐—ฑ๐—ฒ ๐—ผ๐—ฟ ๐—บ๐—ฎ๐—ป-๐—ถ๐—ป-๐˜๐—ต๐—ฒ-๐—บ๐—ถ๐—ฑ๐—ฑ๐—น๐—ฒ ๐—ฎ๐˜๐˜๐—ฎ๐—ฐ๐—ธ๐˜€.

The new ๐—บ๐˜….๐—บ๐—ถ๐—ฐ๐—ฟ๐—ผ๐˜€๐—ผ๐—ณ๐˜ namespace makes it easier for Microsoft to build a complete DNSSEC trust chain into Exchange Online, strengthening end-to-end mail transport security.

๐Ÿ› ๏ธ What admins should do
Most tenants ๐˜ฅ๐˜ฐ๐˜ฏโ€™๐˜ต ๐˜ฏ๐˜ฆ๐˜ฆ๐˜ฅ ๐˜ต๐˜ฐ ๐˜ต๐˜ข๐˜ฌ๐˜ฆ ๐˜ช๐˜ฎ๐˜ฎ๐˜ฆ๐˜ฅ๐˜ช๐˜ข๐˜ต๐˜ฆ ๐˜ข๐˜ค๐˜ต๐˜ช๐˜ฐ๐˜ฏ, but this is a good opportunity to review and strengthen email transport security.

๐Ÿ›ก๏ธ ๐—ฅ๐—ฒ๐—ฐ๐—ผ๐—บ๐—บ๐—ฒ๐—ป๐—ฑ๐—ฒ๐—ฑ ๐—ฐ๐—ต๐—ฒ๐—ฐ๐—ธ๐˜€
– Ensure your public DNS zone is DNSSEC-signed.
– Confirm that any automated tooling or onboarding scripts do not assume the legacy MX hostname format.
– Use DNSSEC and mail connectivity testing tools.

โš ๏ธ ๐—œ๐—บ๐—ฝ๐—ผ๐—ฟ๐˜๐—ฎ๐—ป๐˜
Existing domains are not expected to break, but environments relying on hard-coded MX validation or automation should verify compatibility.

๐˜ˆ๐˜ถ๐˜ต๐˜ฉ๐˜ฐ๐˜ณ ๐˜ฐ๐˜ง ๐˜ต๐˜ฉ๐˜ฆ ๐˜ฑ๐˜ฐ๐˜ด๐˜ต:
Martin Strnad