5.7.5

Enhanced Status Code 5.7.5: Cryptographic Failure

Permanent failure High severity Security RFC 3463
What it means

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.

At a glance
Code5.7.5
Bounce typeHard (permanent)
SeverityHigh
CategorySecurity
What to doSuppress the address; do not retry
StandardRFC 3463
What it looks like in your mail logs
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

Your server attempts delivery
The recipient server returns a permanent 5.7.5 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.7.5 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
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.

IANA registry Cryptographic failure: a system authorized to validate or decrypt could not do so Reference
Exchange Online A remote certificate failed MTA-STS validation Reference

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

Frequently asked questions

What does SMTP error 5.7.5 mean?
It means cryptographic failure. The receiving server was entitled to validate or decrypt your message but could not. Nearly always this is TLS rather than message-level encryption: an expired certificate, a certificate that does not match the hostname, an incomplete chain, a failed MTA-STS check, or no shared cipher suite. It is a configuration fault, not a reputation or content problem.
Is 5.7.5 caused by something on my side or theirs?
Either, and that is what makes it distinctive. If your server is the one presenting a bad certificate, every receiver enforcing TLS will reject you. If the destination is presenting the bad certificate and you enforce MTA-STS or DANE, only that destination fails. Test the specific MX host with openssl s_client and read the certificate: whichever end owns the expired or mismatched certificate owns the fix.
How is 5.7.5 different from 5.7.8?
They describe different failures that both get loosely called authentication. 5.7.5 is cryptographic: certificates, TLS negotiation, decryption. 5.7.8 is credential-based: the username and password you supplied to SMTP AUTH were rejected. If you are being asked to fix a login, it is 5.7.8. If you are being asked to fix a certificate, it is 5.7.5.
Does 4.7.5 mean the same thing as 5.7.5?
It is the temporary form of the same failure. Microsoft in particular returns 4.7.5 when a remote certificate fails MTA-STS validation, deferring rather than rejecting so the message survives while somebody renews the certificate. Treat a 4.7.5 as a warning that a 5.7.5 is coming if nothing changes, and investigate it with the same certificate checks.
Why did this start happening suddenly with no change on my side?
Certificates expire on a fixed date, so a destination that worked yesterday can fail today with nothing changed at your end. The other common trigger is a receiver enabling or tightening MTA-STS, which turns a certificate problem that was previously ignored into a hard requirement. Check the certificate expiry date first, then look for a newly published MTA-STS policy on the destination domain.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes