Enhanced Status Code 5.7.5: Cryptographic Failure
Enhanced Status Code 5.7.5 means “Cryptographic Failure.” A receiving system that was entitled to validate or decrypt your message could not do so. In practice this is almost always a TLS problem: an expired or mismatched certificate, a failed MTA-STS check, or a cipher the two servers cannot agree on.
550 5.7.5 Remote certificate failed MTA-STS validation. Reason: certificate expired
What does 5.7.5 mean?
Enhanced status code 5.7.5 means cryptographic failure. RFC 3463 defines it as a transport system that was otherwise authorized to validate or decrypt a message being unable to do so. The receiver is not saying your message is unwelcome; it is saying the cryptography around the delivery did not work.
The overwhelming majority of real 5.7.5 responses concern TLS rather than message encryption. Microsoft returns 4.7.5 and 5.7.5 when a remote certificate fails MTA-STS validation, which happens when the certificate has expired, when its common name and subject alternative names do not cover the MX hostname, or when the chain cannot be built to a trusted root. Older on-premises servers also return it when the two ends cannot agree on a cipher suite, which is increasingly common as receivers retire TLS 1.0 and 1.1.
Because it is a certificate and configuration fault rather than a reputation one, 5.7.5 is usually all-or-nothing: mail to that destination stops entirely rather than degrading. That makes it easy to spot and easy to confirm, since you can reproduce it from the command line against the same MX host. It is also one of the few rejections where the fault is as likely to be at the receiving end as at yours.
How 5.7.5 plays out
5.7.5 rejectionWhere 5.7.5 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.7.5 is | ✓ this code |
What each provider means by 5.7.5
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.7.5
- The TLS certificate on one side has expired or is not yet valid
- The certificate does not cover the MX hostname it is presented for
- The certificate chain is incomplete and cannot be built to a trusted root
- MTA-STS is published for the destination and the presented certificate fails its policy
- The two servers share no mutually acceptable TLS version or cipher suite
- A middlebox or TLS-terminating proxy is substituting its own certificate
How to fix 5.7.5
- Test the destination directly with openssl s_client -starttls smtp -connect mx:25 and read the certificate
- Renew the certificate and confirm the expiry date is what you expect
- Make sure the certificate covers the exact MX hostname, including any subject alternative names
- Serve the full intermediate chain, not just the leaf certificate
- Check the domain MTA-STS policy at https://mta-sts.example.com/.well-known/mta-sts.txt
- Enable TLS 1.2 and 1.3 and retire TLS 1.0 and 1.1 on your own server