4.7.5

Enhanced Status Code 4.7.5: Cryptographic Failure - Temporary

Temporary failure High severity Security RFC 3463
What it means

Enhanced Status Code 4.7.5 means “Cryptographic Failure - Temporary.” A TLS or certificate problem stopped delivery, and the receiver is deferring rather than rejecting. Microsoft returns it when a remote certificate fails MTA-STS validation.

At a glance
Code4.7.5
Bounce typeSoft (temporary)
SeverityHigh
CategorySecurity
What to doQueued and retried automatically
StandardRFC 3463
What it looks like in your mail logs 
451 4.7.5 Remote certificate failed MTA-STS validation. Reason: certificate host mismatch

What does 4.7.5 mean?

Enhanced status code 4.7.5 is the temporary form of a cryptographic failure. RFC 3463 defines X.7.5 as a transport system otherwise authorized to validate or decrypt a message being unable to do so, and the 4.x form defers instead of refusing, on the assumption that a certificate problem is likely to be fixed.

Microsoft is the most visible user of it, returning 4.7.5 with text saying a remote certificate failed MTA-STS validation. That happens when the destination publishes an MTA-STS policy, Exchange Online enforces it, and the certificate presented does not satisfy the policy: expired, not covering the MX hostname, or chaining to a root Exchange does not trust. Because MTA-STS is enforced rather than advisory, there is no silent fallback to cleartext, so the message queues instead.

The queueing is what makes this code worth attention. Mail is neither delivered nor bounced, so it accumulates silently until the queue lifetime expires and it becomes a 4.4.7 delivery time expired failure days later. By then the original cryptographic cause is buried. Alert on sustained 4.7.5 rather than waiting for the eventual expiry bounce.

How 4.7.5 plays out

Your server attempts delivery
The recipient defers with a temporary 4.7.5 reply
Your server queues the message and retries on a back-off schedule
It delivers on a later attempt, or becomes a hard bounce if it keeps failing

Where 4.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
4.7.5 is✓ this code

What each provider means by 4.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.

Exchange Online A remote certificate failed MTA-STS validation, deferred pending retry Reference

Common causes of 4.7.5

  • The destination certificate has expired
  • The certificate does not cover the MX hostname it is presented for
  • The certificate chain is incomplete or chains to an untrusted root
  • The destination publishes an MTA-STS policy that the presented certificate fails
  • No mutually acceptable TLS version or cipher suite is available
  • A TLS-terminating middlebox is substituting its own certificate

How to fix 4.7.5

  • Inspect the destination certificate with openssl s_client -starttls smtp and read the dates and names
  • If the destination is yours, renew the certificate and serve the full chain
  • Check the destination MTA-STS policy at https://mta-sts.example.com/.well-known/mta-sts.txt
  • Enable TLS 1.2 and 1.3 on your own server and retire 1.0 and 1.1
  • Alert on sustained 4.7.5 rather than waiting for the queue to expire into 4.4.7
  • Contact the receiving postmaster if the certificate at their end is the one at fault

Frequently asked questions

What does 4.7.5 mean?
It is a temporary cryptographic failure. The receiving or sending system could not complete TLS validation, so the message is deferred rather than rejected. Microsoft returns it when a remote certificate fails MTA-STS validation, which is the most common way senders encounter it.
Why does my mail queue instead of bouncing?
Because the failure is marked temporary, so your MTA holds the message and retries on a back-off schedule. That is correct behaviour for a certificate problem, which somebody may well fix. The risk is that nothing alerts on it: mail simply sits in the queue until the lifetime expires and turns into a 4.4.7 delivery time expired bounce days later.
How do I check the destination certificate?
Run openssl s_client -starttls smtp -connect their-mx-host:25 and read the returned certificate. Check the expiry date, check that the subject or a subject alternative name matches the MX hostname exactly, and check that a full chain was served. One of those three is nearly always the fault.
What is MTA-STS and why does it make this permanent?
MTA-STS lets a receiving domain publish a policy saying TLS is mandatory and certificates must validate. When a sender enforces it, there is no fallback to cleartext, so a certificate fault stops delivery instead of silently downgrading it. That is the intent, but it converts a previously invisible certificate problem into a visible mail flow outage.
Is 4.7.5 my problem or the recipient's?
Frequently the recipient's, which makes this unusual. If their MX certificate has expired or does not cover the hostname, there is nothing you can configure to fix it, and the correct action is to contact their postmaster. Check whose certificate is at fault before spending time on your own configuration.

Related bounce codes

5.7.5 Cryptographic Failure 4.7.29 Rate Limited - Connection Not Encrypted 5.7.30 REQUIRETLS Support Required 4.4.7 Delivery Time Expired 5.7.4 Security Features Not Supported

Sources & further reading

RFC 3463 · The standard that defines this reply code IANA registry · The authoritative list of enhanced status codes and their meanings Exchange Online NDR reference · Microsoft list of SMTP errors returned by Exchange Online
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes