TLS negotiation failed

The connection opened and the encryption handshake did not

Where you saw it: Mail logs showing a TLS error before delivery, a bounce naming certificate verification, or delivery failing only to domains that enforce encryption.

Why it happens

  • An expired certificate on one end, which is the most common cause by a wide margin.
  • A certificate whose name does not match the hostname being connected to.
  • An incomplete chain, where the intermediate certificate was not installed and the far end cannot build a path to a trusted root.
  • A protocol mismatch, as receivers disable TLS 1.0 and 1.1 and older servers offer nothing newer.
  • A cipher suite mismatch after one side tightened its configuration.
  • An MTA-STS or DANE policy requiring valid TLS, which turns a warning into a refusal.

The fix, in order

  1. Test the handshake directly

    Run openssl s_client -starttls smtp -connect mailserver:25 and read the output. It reports the certificate, the chain and the negotiated protocol.

  2. Check the expiry date first

    The output shows the validity window. An expired certificate explains the whole failure and takes minutes to fix.

  3. Verify the chain is complete

    A verify error about a local issuer means the intermediate certificate is missing. Install the full chain your certificate authority supplied, not only the leaf.

  4. Confirm the name matches

    The certificate's subject or subject alternative names must include the hostname the other side connects to, which is usually your MX hostname.

  5. Check which protocol versions you offer

    Support TLS 1.2 and 1.3. Anything older is being turned off across the industry and will fail against more receivers each year.

Shell
openssl s_client -starttls smtp -connect mail.example.com:25

Read the certificate chain and the verify return code at the end.

How to know it worked

The short version

  • openssl s_client completes with a verify return code of 0.
  • Mail logs show successful TLS on connections that were failing.
  • Delivery to domains enforcing MTA-STS succeeds.

Questions people ask

Does a TLS failure stop mail entirely?

It depends on the receiver. With opportunistic TLS many will fall back to an unencrypted connection. With an MTA-STS or DANE policy in force, the delivery fails.

Which certificate does a mail server need?

One covering the hostname it presents, from a publicly trusted authority, with the full intermediate chain installed. A self-signed certificate works for opportunistic TLS and fails anything that validates.

Does this affect verification?

Rarely. Our probe closes the connection before any message body, so a failed handshake usually means we fall back or report the domain as unreachable rather than guessing about the mailbox.

Bounces from addresses that never existed are a different problem

We check a list before you send and label what nobody can resolve. 100 free checks a month, no card.