Microsoft 365 MX Records Move to *.mx.microsoft: What Changes for New and Existing Domains

Short answer: Since July 2026, new Microsoft 365 domains get an MX like contoso-com.o-v1.mx.microsoft, not contoso-com.mail.protection.outlook.com. Existing domains keep their MX; Microsoft has given no date to move them. Copy the MX from the admin center; never build it from a pattern.

WhoMicrosoft
Statusconfirmed
Dates
  • 2026-07-01: New accepted domains get MX hosts under mx.microsoft (rolled out through July 2026; first planned for 1 Feb 2026). No date for existing domains

Who is affected

Admins and IT providers who add new domains to Microsoft 365, and any script, DNS template, connector or third-party gateway that writes <domain>.mail.protection.outlook.com. Existing domains keep working on the old MX and can move early by turning on DNSSEC for the domain in Exchange Online.

What you will see

Check your setup today

  1. Run our checker and look at the MX line. .mail.protection.outlook.com is the old style and .mx.microsoft the new one. A mix of both is a half-finished move.
  2. Compare it with Microsoft 365 admin center → Settings → Domains → your domain → DNS records (or the mailExchange value from the Graph serviceConfigurationRecords API). They must match exactly.
  3. If you use MTA-STS, open https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Every MX you publish needs its own mx: line; a new-style MX isn't covered by an old mx: line.
  4. SPF needs no change: Microsoft's SPF value is include:spf.protection.outlook.com and doesn't contain the MX name.

How to fix it

  1. New domains: copy the MX value from the admin center or Graph into DNS. Microsoft says this is now the only source of truth; the new suffix can't be guessed from the domain name.
  2. Update scripts, DNS templates, connectors and third-party gateways (their smart host setting) that hard-code mail.protection.outlook.com.
  3. Moving an existing domain (optional, needed for inbound DANE): lower the MX TTL, put MTA-STS in testing mode, run Enable-DnssecForVerifiedDomain -DomainName yourdomain.com, add the returned MX at priority 20, test it, then set it to priority 0 and delete the old MX.
  4. MTA-STS during the move: in testing mode, replace the old mx: line with the new host, change the policy id, then return to enforce once mail flows. Rebuild the policy from your live MX with our MTA-STS generator.
  5. If DNSSEC at your DNS host breaks mail flow, Microsoft's fallback is to turn DNSSEC off for the domain at the DNS provider and ask them how to re-enable it safely.

Check your domain now

After the fix, send a test email to see SPF, DKIM and DMARC pass on a real message, then keep an eye on it: free DMARC monitoring shows every service that sends mail as your domain and which ones fail, in plain English.

Rather not touch DNS? I set up SPF, DKIM and DMARC without breaking your other senders, with a before/after report.

Get it fixed on Fiverr

Prefer to do it yourself? Get the step-by-step Fix Kit ($15) – 28-page guide, checklist, 20+ providers.

Related pages

Sources

Other upcoming changes