SMTP TLS Negotiation Failed: Causes and How to Fix It

You press send, and your mail client or server log answers with smtp tls negotiation failed. The network is fine. The server answered. What broke is the step after that, where the two sides agree on encryption.

This guide explains what the error means, lists the causes in one table, and gives three fixes. It also shows how to tell whether the fault sits in your client, your server or the recipient's policy, because the fix lives in a different place for each.

What does TLS negotiation failed actually mean?#

Most SMTP submission on port 587 starts as plain text and then upgrades. The client connects, sends EHLO, and the server lists STARTTLS among its extensions. The client sends STARTTLS, the server replies 220 Ready to start TLS, and only then does the TLS handshake begin. This upgrade is defined in RFC 3207. Port 465 works differently: it expects TLS from the very first byte, with no upgrade step.

TLS negotiation can fail at four points. The server may never offer STARTTLS. The handshake may abort because the two sides share no protocol version or cipher. The client may reject the certificate because it is expired, issued for another name, or signed by a chain it does not trust. Or a policy such as MTA-STS may forbid delivering without a verified secure connection.

The wording changes by software. You may see TLS negotiation failed, wrong version number, certificate verify failed, unable to get local issuer certificate, 454 4.7.0 TLS not available due to temporary reason, or 530 5.7.0 Must issue a STARTTLS command first. They all point to the same stage of the conversation.

What causes an SMTP TLS handshake failure?#

Start with this table. Each row gives the usual symptom, a way to confirm it, and the fix. The three numbered fixes after it cover these rows in detail.

Fix 1: correct the client settings#

Check the client first. It is the cheapest place to look and the most common culprit when one device fails and others work.

1. 1

   Pair the port with the right security mode

   Use port 587 with STARTTLS, or port 465 with SSL/TLS. Choosing SSL/TLS on 587 gives a wrong version number error, because the client starts a handshake while the server sends a plain-text greeting. STARTTLS on 465 usually just hangs until it times out, as each side waits for the other.

2. 2

   Connect by the name on the certificate

   Enter the provider's mail host, such as smtp.provider.example, not your own domain or an IP address. A certificate is issued for specific names, and connecting by any other name triggers a mismatch.

3. 3

   Check the device clock

   A wrong date makes a valid certificate look expired or not yet valid. Turn on automatic time and retry.

4. 4

   Update the app and the operating system

   Old clients ship outdated trust stores and may only speak TLS 1.0 or 1.1, which current servers refuse.

5. 5

   Pause antivirus mail scanning

   Some security suites intercept SMTP with their own certificate. If the error disappears with scanning off, exclude your mail client in the suite's settings rather than leaving it off.

Fix 2: repair the server certificate and protocol#

If you run the sending or receiving server, or a relay, inspect what it presents. This command opens a STARTTLS session and prints the certificate chain. Replace the host with your own and keep the -servername flag, so the server returns the right certificate.

1. 1

   Check dates and names

   The certificate must be inside its validity window and list the exact host clients connect to, including every MX hostname if the server receives mail.

2. 2

   Renew or reissue if needed

   Issue a new certificate that covers every name in use. Automated issuance through ACME is the least error-prone route.

3. 3

   Serve the full chain

   Configure the leaf certificate plus intermediates. A server that sends only the leaf works on some clients and fails on others, which makes the fault look random.

4. 4

   Enable TLS 1.2 and 1.3

   RFC 8461 requires MTAs that support MTA-STS to speak TLS 1.2 or 1.3. Remove SSLv3, TLS 1.0 and TLS 1.1. In Postfix, review smtpd_tls_cert_file, smtpd_tls_key_file and smtpd_tls_protocols.

5. 5

   Reload and retest

   Reload the mail service, then rerun the openssl command. A Verify return code of 0 confirms the chain is trusted.

Fix 3: handle an MTA-STS or DANE refusal#

Sometimes your server and client are fine and one recipient domain still fails. The domain probably publishes a policy that says: deliver to us only over verified TLS. That policy is MTA-STS (RFC 8461) or DANE.

In enforce mode, a sender must not deliver to an MX host that fails certificate validation, fails to match the policy's mx list, or does not offer STARTTLS. RFC 8461 asks senders to treat this as a temporary failure and retry, which is why you often see a delay before a bounce.

1. 1

   Confirm a policy exists

   Look up the TXT record at _mta-sts.recipient.example, then fetch https://mta-sts.recipient.example/.well-known/mta-sts.txt. The file lists the mode (enforce, testing or none), the allowed mx hosts and the max_age.

2. 2

   Test the recipient's MX like any server

   Run the openssl command from Fix 2 against the recipient's MX host. An expired certificate, a name that is not in the policy's mx list, or a missing chain explains the refusal.

3. 3

   If you are the sender, tell the recipient and wait

   You cannot lawfully route around an enforce policy, and you should not want to. Report the failing host to the recipient's administrator. Your mail server will keep retrying.

4. 4

   If you run the recipient domain, fix the certificate, then the policy

   Repair the MX certificate, and update the HTTPS policy file before changing the TXT record id, as RFC 8461 recommends. To retire the policy, publish mode none with a short max_age and wait out the old cache first.

5. 5

   For DANE, update the TLSA record

   A new certificate with a new key no longer matches an old TLSA record. Publish the new record before the old certificate retires.

How do I tell which side owns the fault?#

The same error text can come from three places, so a few quick checks save a lot of guessing. Run them in this order.

How do I stop it coming back?#

Most TLS handshake failures are scheduled in advance: a certificate has an end date, and nobody put it in a calendar. Automate renewal, and alert on expiry well before the date instead of relying on memory.

If you publish MTA-STS, start in testing mode and add a TLS-RPT record (RFC 8460) so senders email you failure reports before anything is refused. Move to enforce only when the reports are clean. Test every MX host, including the backup. RFC 8461 notes that a broken backup MX may stay hidden until the primary goes down.

Keep clients patched, and retest with openssl whenever you change a certificate, a hostname or a mail server version.

• Automate certificate renewal and alert on expiry
• Cover every MX and submission hostname in the certificate
• Serve the full certificate chain
• Allow TLS 1.2 and 1.3 only
• Roll out MTA-STS in testing mode with TLS-RPT before enforcing

Where AI Emaily fits#

A large share of these errors come from hand-typed server settings: a port paired with the wrong security mode, or a hostname that is not on the certificate. We build AI Emaily, so we know the pattern well. When you add a mailbox, it verifies the connection before saving and hints at which setting is probably wrong, and Gmail and Outlook can be connected with one-click sign-in so you never touch server settings.

It cannot repair a server's expired certificate or a recipient's MTA-STS policy. Those belong to whoever runs the mail server. For what protects mail inside the app, see the encryption docs linked below. A 7-day free trial is available from the homepage, with plans on the pricing page.