STARTTLS is advertised but the handshake does not complete
What this check looks for
Your mail server offers encryption and then fails to deliver it. This is worse than not offering it: senders that saw the offer may refuse to fall back to plain text and give up entirely.
Why it matters
A sender that accepts the STARTTLS offer and then cannot complete the handshake has no good option. Some retry in plaintext, some — including anyone enforcing MTA-STS or DANE — treat delivery as failed and bounce the message.
When the check passes, your report says: “The STARTTLS handshake completes and encryption is established”.
What it costs your score
When this check fails it removes 25 points from your Email transport score, before the status, confidence and repeat multipliers are applied. Email transport carries a weight of 8 in the overall score.
It shares the email-transport.smtp-tls family ceiling of 40 points: however many findings that family produces, together they cannot remove more than that from Email transport. One underlying problem showing up in several places is still one problem.
- Severity
- high
- Default confidence
- confirmed
- Status when triggered
- fail
- Deduction
- 25 points
- Family cap
- email-transport.smtp-tls · 40
- Category
- Email transport
- Module
- Email smtp tls
- Fix owned by
- mail provider
- In the ruleset since
- 2026.09
How to fix it
Fix the TLS configuration on ‹mx host› so the advertised STARTTLS actually completes.
An advertised extension that fails causes enforcing senders to bounce mail rather than retry.
Check the mail server's log at the moment of a connection attempt; a key file it cannot read is the most frequent cause and is logged clearly.
Confirm the certificate and key match:
openssl x509 -noout -modulus -in cert.pem | openssl md5and the same for the key.Confirm the service user can read the key file — after an ACME renewal the permissions are often reset.
Confirm the configured cipher list is not empty for TLS 1.2 and 1.3; an over-tightened list leaves no suite in common.
How to confirm it worked
openssl s_client -starttls smtp -connect ‹mx host›:25 -servername ‹mx host› — expect the handshake to complete and print a certificate.
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
‹mx host› advertised STARTTLS, but the session did not reach an encrypted state. Server reply: ‹starttls reply›. Handshake error: ‹handshake error›. RFC 3207 §4 requires a server that advertises STARTTLS to complete it; the common causes are a missing or unreadable key file, a certificate the server cannot load, and a TLS configuration with no cipher in common with modern clients.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.
Other email smtp tls checks
- Mail server's SMTP greeting does not conform to the protocol
- Mail server's TLS certificate has expired or is not yet valid
- Mail server's certificate does not cover its own hostname
- Mail server's TLS certificate does not verify
- Mail server does not offer STARTTLS
- Mail server does not accept connections on port 25
- SMTP transport security was not tested
- Mail server negotiates a deprecated TLS version