Exchange Online 550 5.4.8 — MX Failed MTA-STS Validation

The policy and the MX records disagree

MTA-STS lets a domain declare which mail exchangers senders should accept and require TLS to them. The policy file lists host patterns; if a published MX record points somewhere the policy does not list, conforming senders refuse it. This is exactly the failure MTA-STS is designed to produce when infrastructure changes without policy updates.

The usual sequence: MX records were changed for a migration or a new filtering service, the mta-sts.txt policy was not updated, and senders that honour the policy — Microsoft, Google — began rejecting while senders that ignore it continued delivering.

Verify the mismatch

Run Mail Transport Security for the recipient domain. It fetches the policy, lists every MX host and shows which ones match. Any unmatched host is the cause.

Also check the policy id in the _mta-sts DNS record: if the policy file was updated but the id was not changed, senders keep using their cached copy of the old policy for its max_age.

• Compare each MX hostname against the policy’s mx patterns.
• A changed policy needs a changed id in DNS.
• Backup and failover MX hosts must be listed too.

Fix on the recipient side

Update the policy file to include every active exchanger using wildcard patterns where appropriate, change the id in the DNS record, and confirm the file is served correctly over HTTPS on the mta-sts subdomain. Consider testing mode with TLS-RPT for a period after any MX change.

If you are the sender, there is nothing to change; forward the NDR to the recipient organization.

Known limits

• Policy caching means the fix becomes visible to each sender only after its cached copy expires.
• Only the recipient domain can correct its policy.

Common questions