Enhanced Status Code 5.4.8: MTA-STS Validation Failed
Enhanced Status Code 5.4.8 means “MTA-STS Validation Failed.” The destination publishes an MTA-STS policy and its own mail servers do not satisfy it. The domain has promised a security guarantee its infrastructure is not delivering.
550 5.4.8 MX hosts of example.com failed MTA-STS validationWhat does 5.4.8 mean?
Microsoft returns 5.4.8 with text saying the MX hosts of a domain failed MTA-STS validation, deferring first as 4.4.8 and escalating afterwards. MTA-STS lets a domain publish a policy, fetched over HTTPS, declaring which MX hostnames are legitimate and that TLS is mandatory. A sender that honours the policy will not deliver to anything outside it.
A validation failure means the domain's published promise and its actual infrastructure disagree. Most often the policy lists MX hostnames that no longer match the ones in DNS, because MX records changed and the policy file was not updated. It can also mean the policy file itself cannot be fetched, that its certificate is invalid, or that the servers it names fail TLS for one of the reasons covered by 5.7.321 through 5.7.325.
Because the policy is published by the destination, the failure is theirs to resolve, and the sender's correct action is to alert rather than to bypass. Adopting MTA-STS is worthwhile precisely because it is enforced, and a sender that routes around a failed policy has given up the guarantee for that domain.
How 5.4.8 plays out
5.4.8 rejectionWhere 5.4.8 sits: soft vs hard bounce
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| SMTP class | 4xx | 5xx |
| What to do | Let it retry | Suppress the address |
| Recoverable? | Often | No |
| 5.4.8 is | ✓ this code |
What each provider means by 5.4.8
A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.
Common causes of 5.4.8
- The MTA-STS policy lists MX hostnames that no longer match the DNS records
- MX records were changed without the policy file being updated
- The policy file at the well-known URL cannot be fetched
- The HTTPS certificate serving the policy file is invalid or expired
- An MX host named in the policy fails TLS validation for another reason
- The policy is in enforce mode while the infrastructure is not ready for it
How to fix 5.4.8
- Do not suppress the recipient, since the address is valid and the policy is theirs
- Tell the receiving organisation that their MTA-STS policy and MX records disagree
- Fetch their policy from https://mta-sts.their-domain/.well-known/mta-sts.txt and compare it to their MX records
- Check whether an individual MX host is failing for a certificate reason
- Do not bypass the policy, which discards the guarantee it exists to provide
- Where you publish MTA-STS yourself, keep the policy in testing mode until MX changes settle