# 5.4.8: MX hosts of the domain failed MTA-STS validation URL: https://iblockspam.com/smtp-errors/550-5-4-8 Last updated: 2026-11-03 Code: 550 5.4.8 (permanent failure, the message bounced) Provider: Microsoft 365 / Outlook.com 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. What the bounce says: ``` MX hosts of '' failed MTA-STS validation ``` Microsoft's text for 5.4.8 in its MTA-STS article, where stands for the recipient domain; 5.7.5 reads "Remote certificate failed MTA-STS validation. Reason: ". 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. ## Common 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 (sender) - 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. ## How to fix it (recipient or 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. **Q: 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. **Q: 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): https://learn.microsoft.com/en-us/exchange/security-and-compliance/enhance-mail-flow-using-strict-transport-security - Email nondelivery reports (NDRs) and SMTP errors in Exchange Online (Microsoft Learn): https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online - RFC 8461: SMTP MTA Strict Transport Security (MTA-STS): https://www.rfc-editor.org/rfc/rfc8461 --- Source: iBlockSpam, https://iblockspam.com/smtp-errors/550-5-4-8 (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt