5.4.8: MX hosts of the domain failed MTA-STS validation
Microsoft 365 didn't deliver the message because the recipient domain's MTA-STS policy is in enforce mode and its mail server didn't pass validation: wrong MX host or bad certificate.
MX hosts of '<domain>' failed MTA-STS validation
Microsoft's text for 5.4.8 in its MTA-STS article, where <domain> stands for the recipient domain; 5.7.5 reads "Remote certificate failed MTA-STS validation. Reason: <validityStatus>".
What 550 5.4.8 means
Microsoft says Exchange Online checks every outbound message to MTA-STS-protected domains with the TLS and certificate checks the standard defines, and that this is always on. If the destination isn't secure and its MTA-STS policy is set to enforce, the sender can get an NDR with one of two codes. 5.4.8, "MX hosts of '{domain}' failed MTA-STS validation", means the destination MX host wasn't the host the domain's policy expected. 5.7.5, "Remote certificate failed MTA-STS validation", means the server's certificate didn't chain to a trusted root, or its name didn't match the host in the policy.
MTA-STS is defined in RFC 8461. A domain publishes a policy file listing its allowed MX hosts and a mode. In enforce mode, sending servers that support MTA-STS refuse to deliver if TLS or the certificate fails, which protects against downgrade and interception attacks. The flip side is that a mistake in the policy bounces real mail.
The fix is on the recipient domain's side. The usual cause is an MX change, such as a move to a new provider or filtering service, without updating the mx lines in the MTA-STS policy, or an expired or mismatched certificate on the MX host. Microsoft suggests switching the policy to testing mode during incidents: senders still fetch the policy and send TLS reports, but stop enforcing it.
Likely causes
- The recipient domain changed its MX records but didn't update the mx lines in its MTA-STS policy.
- The MX host's certificate expired, isn't trusted, or doesn't cover the host name (code 5.7.5).
- A policy file with a typo or a stale mail server name.
How to fix it
If you sent the message
- Tell the recipient's IT team: the fix is on their domain. Include the full NDR and the code (5.4.8 or 5.7.5).
- Resend after they confirm the policy or certificate is fixed.
If you're the recipient or their admin
- Update the mx lines in your mta-sts.txt policy to match your current MX hosts, then change the id in the _mta-sts TXT record.
- Check the MX host's certificate chain and names.
- During an incident, switch the policy to mode: testing until it's fixed, and watch your TLS-RPT reports.
Frequently asked questions
We changed email providers and now Microsoft 365 senders get 5.4.8. Why?
Your MTA-STS policy still lists the old MX hosts. Microsoft 365 enforces the policy, sees that your new MX host isn't in it, and refuses to deliver. Update the mx lines and the policy id.
How do I stop MTA-STS bounces quickly while I fix the policy?
Microsoft suggests changing the policy mode to testing. Senders then fetch the policy but don't enforce it, and still send TLS reports, so mail flows while you correct the MX list or certificate.
Sources
- Enhance mail flow with MTA-STS (Microsoft Learn)
- Email nondelivery reports (NDRs) and SMTP errors in Exchange Online (Microsoft Learn)
- RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
Provider messages are quoted as the provider publishes them. Servers can change their wording, so the bounce you received may differ slightly.
Related codes
- 450 4.4.317 450 4.4.317: cannot connect to remote server [Message=UntrustedRoot]
- 550 5.7.29 550 5.7.29: Gmail blocked a message not sent over TLS
- 530 5.7.0 530 5.7.0: authentication required (or STARTTLS first)
- 550 5.4.1 550 5.4.1 Recipient address rejected: Access denied
- 550 4.4.7 550 4.4.7 QUEUE.Expired: message expired
- 550 5.7.506 5.7.506: access denied, bad HELO
- 550 5.2.121-122 5.2.121 and 5.2.122: recipient's per hour message receive limit exceeded
Related guides
MTA-STS and TLS-RPT explained: how to set them up safely
What MTA-STS and TLS-RPT protect against, the DNS records and policy file you need, testing vs enforce mode, and safe rollout behind a filtering gateway.
9 min read Email security basicsIs my email encrypted in transit? STARTTLS, MTA-STS and DANE explained
What STARTTLS does for email, why opportunistic TLS can be downgraded, how MTA-STS and DANE enforce it, what Gmail's lock icons mean, and where TLS stops.
9 min read Switching & migrationHow to change MX records without losing email
A cutover checklist for MX changes: lower TTL, stage the new destination, keep the old server accepting mail, verify with headers and roll back cleanly.
11 min read