5.7.325

Enhanced Status Code 5.7.325: Certificate Hostname Mismatch

Permanent failure High severity Security
What it means

Enhanced Status Code 5.7.325 means “Certificate Hostname Mismatch.” The destination presented a valid, unexpired certificate that does not cover the hostname it was reached at. Under enforcement, a name mismatch is as fatal as an expired certificate.

At a glance
Code5.7.325
Bounce typeHard (permanent)
SeverityHigh
CategorySecurity
What to doSuppress the address; do not retry
What it looks like in your mail logs 
550 5.7.325 certificate-host-mismatch: Remote certificate must have a common name or subject alternative name matching the destination host

What does 5.7.325 mean?

Microsoft returns 5.7.325 with the text certificate-host-mismatch, meaning the remote certificate must have a common name or subject alternative name matching the hostname being connected to, and does not. The certificate may be perfectly valid and current; it simply does not cover the name in the MX record.

This is a configuration mismatch rather than a certificate fault, and it is common after infrastructure changes. A domain adds a new MX host and points it at an existing server whose certificate covers the old name only. Or mail is moved behind a provider whose certificate covers the provider's own hostnames rather than the customer's. In both cases everything works for anyone not checking names, and fails immediately for anyone enforcing MTA-STS or DANE.

The fix at the destination is either to reissue the certificate with the MX hostname included as a subject alternative name, or to change the MX records to a hostname the existing certificate already covers. Both are straightforward once identified, and neither is something a sender can do.

How 5.7.325 plays out

Your server attempts delivery
The recipient server returns a permanent 5.7.325 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.325 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.325 is✓ this code

What each provider means by 5.7.325

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 The remote certificate does not cover the destination hostname Reference

Common causes of 5.7.325

  • The MX hostname is not listed in the certificate common name or subject alternative names
  • A new MX host was added without the certificate being reissued to cover it
  • Mail was moved to a provider whose certificate covers only its own hostnames
  • The certificate covers the bare domain but the MX points at a subdomain
  • A wildcard certificate does not cover the depth of the MX hostname
  • A load balancer presents a certificate for a different name than the MX record

How to fix 5.7.325

  • Do not suppress the recipient, since the address is valid and the fault is their configuration
  • Tell the receiving organisation which hostname their certificate needs to cover
  • Read the certificate with openssl s_client and compare its names to their MX records
  • Check every MX host, since only one may be mismatched
  • Do not disable enforcement to work around a name mismatch
  • Where you host mail yourself, ensure every MX hostname is a subject alternative name

Frequently asked questions

What does 5.7.325 mean?
It means the destination presented a TLS certificate that does not cover the hostname it was contacted at. The certificate can be entirely valid and current; the problem is that the MX hostname does not appear in its common name or subject alternative names. Under enforced TLS that is fatal.
How do I confirm the mismatch?
Run openssl s_client -starttls smtp -connect their-mx-host:25 and read the subject and subject alternative names from the returned certificate. Compare that list against the hostnames in their MX records. If the MX name is absent from the list, that is the fault, stated precisely enough for them to act on.
Why does this happen after infrastructure changes?
Because certificates are issued for the names known at the time. Adding an MX host, migrating to a mail provider, or moving behind a load balancer all introduce a hostname the existing certificate was never issued for. Everything works for clients that do not check names, so the problem stays hidden until an enforcing sender arrives.
Can a wildcard certificate cause this?
Yes. A wildcard covers one level only, so a certificate for *.example.com does not cover mx1.mail.example.com. An MX hostname nested one level deeper than the wildcard fails validation despite the certificate looking correct at a glance.
Is the recipient address still valid?
Yes. This is purely about transport security between the servers and says nothing about the mailbox. Once the destination corrects its certificate or its MX records, delivery resumes normally to the same address.

Related bounce codes

5.7.5 Cryptographic Failure 4.7.5 Cryptographic Failure - Temporary 5.7.30 REQUIRETLS Support Required 5.4.8 MTA-STS Validation Failed 5.7.324 Destination DNSSEC Records Invalid

Sources & further reading

How SMTP DANE works · Microsoft reference for DANE, TLSA records and the 5.7.32x codes 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