# Why does Gmail report TLS errors? > Gmail TLS errors point to an encrypted SMTP connection or policy failure. Preserve the SMTP response, test STARTTLS, certificates, DNS, and MTA-STS. Gmail reports a TLS error when the SMTP connection cannot meet the encryption or authentication requirements applied to that route. Common causes include no STARTTLS support, incompatible TLS versions or ciphers, an expired or mismatched certificate, an incomplete certificate chain, DNS or MX drift, and an enforced MTA-STS policy that does not match the receiving host. Preserve the full SMTP response and direction of delivery before changing authentication records. SPF, DKIM, and DMARC do not repair a failed TLS handshake. ## Quick takeaways - TLS errors concern the SMTP transport connection. - The enhanced status code and complete response identify the correct branch. - Certificate name and chain failures differ from cipher negotiation failures. - MTA-STS can turn a best-effort TLS problem into a delivery failure. - Test the exact sending-to-receiving route, not only a browser certificate. ![Locate the failing TLS layer, shown as a four-step technical sequence.](/images/editorial/gmail-tls-errors/gmail-tls-errors-visual-guide.svg) *This diagram summarizes the article's diagnostic sequence. Use the linked standards, current provider documentation, and production evidence for exact decisions. [Open the full-size diagram](/images/editorial/gmail-tls-errors/gmail-tls-errors-visual-guide.svg).* ## What does the failure mean? TLS protects the connection between mail servers. [Gmail's SMTP error reference](https://support.google.com/mail/answer/3726730?hl=en) documents temporary and permanent responses used when a peer does not meet an applicable transport requirement. The error can occur when sending to Gmail or when Google Workspace sends to a domain that enforces MTA-STS, so first establish direction. Identity authentication is a different layer. The [SPF overview](/learning/what-is-spf), [DKIM overview](/learning/what-is-dkim), and [DMARC overview](/learning/what-is-dmarc) do not replace transport testing. ## What usually causes it? ### The server does not negotiate a supported TLS configuration The peer may omit STARTTLS, require an obsolete protocol, or offer no cipher that Gmail supports. Middleboxes can also interfere with the SMTP capability exchange. ### The certificate cannot be authenticated The certificate may be expired, not yet valid, issued for a different MX hostname, missing an intermediate, or chained to an untrusted authority. ### DNS and MTA-STS policy disagree with production An MX migration can leave an old host in DNS or omit the new host from the MTA-STS policy. In enforce mode, Google must apply the [published MTA-STS policy](https://www.rfc-editor.org/rfc/rfc8461.html) rather than silently deliver to an unauthorized host. ## How do I diagnose the failure? ### 1. Save the complete SMTP response Record the three-digit code, enhanced status code, Gmail text, gsmtp or gcdp identifier, timestamp, sender IP, recipient domain, and message ID. Do not diagnose from the phrase TLS error alone. ### 2. Confirm direction and policy Identify which server initiated the connection and whether the receiving domain publishes MTA-STS or another required TLS policy. Check whether a Google Workspace administrator also applied a route-specific secure transport rule. ### 3. Test SMTP STARTTLS directly Connect to every relevant MX from outside the network. Inspect the advertised capability, negotiated version and cipher, certificate subject names, dates, and full chain. ### 4. Compare DNS, policy, and server names Check MX records, forward and reverse DNS where relevant, the MTA-STS mx patterns, and the hostname presented in the certificate. Test lower-priority MX hosts too. ## How do I fix it? Enable STARTTLS on the correct SMTP listener and configure a version and cipher set compatible with [Gmail's current TLS documentation](https://support.google.com/a/answer/9795993?hl=en). Install a valid certificate whose names cover the MX hostname and serve the complete chain. Correct stale MX records, routing, or MTA-STS patterns. If a gateway or inspection device changes the handshake, test around it and correct that device rather than weakening the public policy. Coordinate with the remote domain when the failing component is outside your control. ## How do I validate the repair? Repeat the external STARTTLS test for every MX, then resend the same message flow. Confirm the SMTP response is successful and review later TLS aggregate reports for the failure category. Avoid declaring success from one primary MX when a backup still fails. Use Palisade's [DNS lookup tool](/tools/dns-lookup) for MX and policy records and [Email Security Score](/tools/email-security-score) for public posture. Direct SMTP evidence remains necessary. ## Frequently asked questions ### Is a Gmail TLS error caused by DMARC? No. DMARC evaluates authenticated identity. A TLS error occurs at the transport-security layer, although a message can have problems at both layers. ### Is TLS 1.2 always the exact problem? Not necessarily. Save the response and inspect negotiation. Certificate, DNS, MX, policy, or cipher problems can produce similar descriptions. ### Why does mail work to some recipients at the same domain? Different routes, MX hosts, gateways, or administrator policies may apply. Compare timestamps and receiving hosts. ### Can I disable certificate checks to restore delivery? No. Disabling certificate checks weakens transport security and may violate an enforced policy. Fix hostname, chain, trust, or routing instead. ### Does a successful browser HTTPS test validate SMTP TLS? No. SMTP STARTTLS runs on the mail listener and can present a different certificate, chain, protocol set, or network path.