TLS handshake failures on outbound SMTP
Transportconnectionaction: retry
A TLS handshake failure means the connection opened but encryption could not be negotiated. Occasional failures are normal. A failure rate concentrated on one destination or one IP range is almost never a certificate problem, it is a reputation problem being expressed at the transport layer.
This one is worth internalising. A near-total TLS failure rate against a single provider from a single IP range looks exactly like a configuration bug and is usually reputation damage. The diagnostic that separates them is comparing separated egress paths to the same destination, which is only possible if the estate was built with that separation in the first place.
What it looks like in the log
TLS handshake failedCannot start TLS: handshake failureSSL routines: ssl3_read_bytes: sslv3 alert handshake failureWhy it happens
- A genuine mismatch in protocol versions or cipher suites, which is increasingly rare.
- An expired or misconfigured certificate on either end.
- Middleboxes interfering with STARTTLS.
- The receiver declining the connection at handshake time because of the source IP.
What to do
- Compare handshake outcomes across different egress paths to the same destination. If one range fails and another succeeds, the range is the problem, not the configuration.
- Confirm your own certificate and protocol support before assuming the receiver is at fault.
- If TLS-RPT is published for the destination, read the reports rather than inferring.
Related
Domain check reports what the domain publishes for TLS, and whether the policy behind it resolves. Open domain check