mailpassed research · 2026-10-25 · first published here

Microsoft 365 + MTA-STS: the mx.microsoft trap

Short answer: 96.0% of Microsoft 365 domains that enforce MTA-STS list only the old *.mail.protection.outlook.com host – exactly what Microsoft's own MTA-STS guide shows. When such a domain moves to Microsoft's new mx.microsoft hosts, senders that enforce MTA-STS refuse its mail, and the obvious fix mx: *.mx.microsoft doesn't match those hosts.

Why it matters

Microsoft gives new Microsoft 365 domains (since July 2026), and domains that turn on DNSSEC/DANE, MX hosts like contoso-com.o-v1.mx.microsoft instead of contoso-com.mail.protection.outlook.com. Microsoft's MTA-STS article (updated 21 Jul 2026) still shows only mx: *.mail.protection.outlook.com. Its DANE guide (same date) does tell admins to switch the policy to testing and replace the mx row with the new host before the move, and Enable-DnssecForVerifiedDomain reports a missing row as error ES001. Existing domains keep their MX until their own admin changes it; Microsoft has given no date for moving them. A domain whose policy is in enforce mode and whose MX moves without a policy update makes Gmail, Microsoft and other MTA-STS senders refuse delivery (Exchange Online answers with 5.4.8 MX hosts … failed MTA-STS validation).

The tempting fix, mx: *.mx.microsoft, does not work: under RFC 8461 a wildcard covers exactly one label, and the new hosts have two labels in front of mx.microsoft. In our scan 11 policies already use that non-matching line. Even microsoft.com's own policy lists only the old name (its MX hasn't moved).

Separately, 18.6% of all domains with MTA-STS have a policy-host problem (expired or soon-expiring certificate, unreachable or non-200 policy): 13 enforce-mode policies sit behind an expired certificate. Senders keep their cached policy for a while, so this fails quietly – until the MX changes.

Check your domain

1. Run our checker: it reads your policy, compares every mx: line with your live MX the way senders do, and warns about the mx.microsoft trap.
2. Open https://mta-sts.yourdomain/.well-known/mta-sts.txt and note the mode and mx: lines.

How to fix it

1. Before moving your MX to mx.microsoft (DNSSEC/DANE or a new domain), set the policy to mode: testing and change the policy id.
2. Add the exact new MX host Microsoft gives you (Microsoft 365 admin center → Domains → DNS records, or Get-DnssecStatusForVerifiedDomain), or *.<region>-v1.mx.microsoft – not *.mx.microsoft.
3. Move the MX, confirm mail flows (TLS-RPT reports help), then return to enforce with a new id.
4. Keep the policy host's certificate auto-renewing – MTA-STS generator.

How we measured

We resolved the public DNS of the 99,704 live registrable domains in the Tranco top-100,000 list (scan of 2026-10-25): MX, SPF (with every include followed and counted the way receivers do), DMARC, MTA-STS and TLS-RPT, and fetched each MTA-STS policy over HTTPS with certificate checks. Unknown answers (DNS timeouts) are kept apart from missing records. We publish totals only and never name affected domains.

Related

• Microsoft 365 MX Records Move to *.mx.microsoft: What Changes for New and Existing Domains
• MTA-STS generator

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.