5.7.322 means TLS was negotiated but the destination presented an expired certificate, and the route required a valid one. Every sender enforcing certificate validation will fail the same way, so the fix is on the receiving mail exchanger.
Most common causes
- The destination SMTP certificate passed its validity end date
- A gateway still presents an old certificate after renewal
- Different MX hosts present inconsistent certificate versions
- TLS policy enforcement exposed a certificate lifecycle failure
What to verify next
- Run Mail Transport Security for every destination MX host
- Inspect the certificate validity window and SMTP hostname
- Check whether all gateway nodes received the renewed certificate
- Retest after the destination presents a current certificate
Why an expired certificate blocks delivery
Opportunistic TLS tolerates bad certificates; mandatory TLS with validation does not. When a connector requires a validated certificate or the recipient’s MTA-STS policy is in enforce mode, an expired certificate is a policy failure and the message is rejected rather than delivered insecurely.
The certificate belongs to whichever host accepted the SMTP connection — often a gateway, load balancer or filtering service rather than the mailbox server itself.
Check every exchanger, not just one
Renewals are frequently deployed to some nodes and not others. Mail Transport Security examines each MX host separately and reports the certificate validity window and hostname, so a partially deployed renewal shows up as inconsistent results across hosts.
Also confirm the certificate’s subject matches the MX hostname and that the intermediate chain is served; both produce validation failures that look similar to expiry from the sender’s side.
- Identify which MX host presented the certificate.
- Check all hosts — renewals are often partial.
- Verify hostname match and chain, not only the dates.
Fix and verify
If you are the recipient, install the renewed certificate on every mail exchanger and restart the SMTP service on each. If you are the sender, notify the recipient organization with the NDR; relaxing your connector should be a deliberate decision, not a workaround.
Retest with the transport-security check after deployment. TLS-RPT, if the recipient publishes it, will show whether senders still observe failures.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisMail Transport Security
Inspect MX, TLS, MTA-STS and transport-policy evidence for the destination.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- The sender cannot fix the recipient’s certificate.
- Certificate caching on some sending systems can delay the effect of a renewal briefly.
Common questions
Our certificate is valid on the website.
The web server and the mail exchanger often use different certificates. Check the one presented on port 25 by each MX host.
Does this affect all senders?
All senders that validate certificates on that route. Opportunistic senders may still deliver, which hides the problem.
Should we disable TLS validation?
No. Renew the certificate. Disabling validation silently downgrades security for every message.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.