STARTTLS failed: how to fix SMTP TLS negotiation errors

STARTTLS is an SMTP extension that upgrades a plaintext session to TLS mid-conversation. When it fails, the mail either goes out unencrypted or does not go out at all — and the error text is usually too vague to act on. The reliable diagnosis is to run the conversation yourself and see where it stops.

What the handshake looks like when it works

$ openssl s_client -starttls smtp -connect smtp.example.com:587 -crlf
250-smtp.example.com
250-STARTTLS
250-AUTH PLAIN LOGIN
...
Verify return code: 0 (ok)

The sequence is: connect in the clear, send EHLO, look for 250-STARTTLS in the capability list, issue STARTTLS, receive 220, renegotiate as TLS, then send EHLO again. Credentials and message data only travel after that second EHLO.

Two things follow. If 250-STARTTLS is missing from the capability list, the server will not upgrade on this port — the client is not at fault. And if your client sends AUTH before the upgrade, a correctly configured server refuses it.

Cause 1: the wrong port for the mode

Mismatching the port and the mode is the most common cause of all. A client set to "STARTTLS" against 465 hangs or reports a protocol error, because the server is waiting for a TLS handshake and the client is sending ASCII. A client set to "SSL/TLS" against 587 fails the same way in reverse. Fix the pairing before touching anything else.

Cause 2: the server does not advertise STARTTLS

Run the EHLO by hand. If 250-STARTTLS is absent, the possibilities are:

• The port only speaks implicit TLS — use 465.
• The service is configured without TLS at all, which for a submission server is a misconfiguration to fix on the server, not a client setting to work around.
• Something between you and the server is rewriting the capability list. Firewalls and "SMTP inspection" features on consumer-grade routers and some corporate appliances have historically stripped STARTTLS from the response so they can read the traffic. If the capability appears from one network and not another, that is your answer.

A client with "require encryption" set will correctly refuse to continue in that last case. Do not switch it to "optional" to make the error go away — that is the downgrade the attack is designed to produce.

Cause 3: the certificate check fails

The upgrade happens and then verification rejects it. Read the exact reason:

Verify return code: 21 (unable to verify the first certificate)   -> missing intermediate
Verify return code: 10 (certificate has expired)                  -> expired
Verify return code: 18 (self-signed certificate)                  -> self-signed
hostname mismatch                                                 -> cert CN/SAN != the host you connected to

Hostname mismatch is the subtle one: connecting to mail.yourdomain.com when the certificate names smtp.provider.net fails verification even though the certificate is perfectly valid. Either connect to the name on the certificate or get a certificate that includes the name you use. Missing intermediates are a server-side chain problem that only shows up for clients with a smaller trust store, which is why "it works in my mail client but not in the application" is so common.

Cause 4: temporary refusals

454 4.7.0 TLS not available due to temporary reason
530 5.7.0 Must issue a STARTTLS command first

The first is transient — retry with backoff rather than reconfiguring. The second means your client tried to authenticate or send before upgrading; it is a client ordering bug, not a server problem.

Diagnose in this order

1. Confirm the port and mode pairing.
2. openssl s_client -starttls smtp -connect host:587 -crlf and read the capability list.
3. If STARTTLS is advertised, read the verify return code.
4. If it is not advertised, retry from a different network to rule out interception.
5. Only then look at client settings, and change one at a time.

Why this matters beyond the error

Gmail's sender requirements include transmitting over TLS, so a sender that quietly falls back to plaintext is not merely less private — it is failing a published requirement. Opportunistic TLS is also, by design, downgradeable: a stripped STARTTLS silently sends your mail in the clear. The fix for that is policy rather than configuration — MTA-STS tells senders that your domain requires TLS, and DANE pins it to DNSSEC-signed records.

What not to do

• Do not disable certificate verification to clear the error. You have turned a visible failure into an invisible one.
• Do not set encryption to "none" or "optional" on a submission port. Credentials then travel in plaintext on any session where the upgrade fails.
• Do not issue `STARTTLS` on 465. It is already encrypted; the command is an error there.
• Do not change five client settings at once. You will not know which one fixed it, and one of them may be unsafe.
• Do not treat `454 4.7.0` as a configuration bug. It is temporary; retry.
• Do not assume a passing `openssl` test means your application works. Different trust stores produce different results on an incomplete chain.

How MailPilot helps

MailPilot connects mailboxes over OAuth for Gmail and Outlook, and over SMTP/IMAP for SendGrid, Amazon SES, Mailgun, Postmark and custom hosts — validating the port, encryption mode and credentials at connection time, so a misconfigured submission path is caught before it becomes a stalled warm-up. It also checks SPF, DKIM and DMARC on the sending domain and measures real per-provider inbox placement.