Gmail 5.7.29 error: message was not sent over TLS

Quick answer

Gmail 5.7.29 means Gmail blocked the message because it was not sent over a TLS connection. Check the actual outbound SMTP route that delivered the message to Gmail: sender, relay, gateway, TLS settings, certificate validation, and logs. A public inbound TLS check is useful, but it does not prove the TLS state of one outbound session to Gmail.

Gmail 5.7.29 is about the SMTP connection Gmail received

Google's sender guidelines FAQ maps 5.7.29 to a message blocked because it was not sent over a TLS connection. The related temporary code is 4.7.29; the permanent block is 5.7.29.

This is a transport-security error. Gmail is not saying the subject line was spammy or that SPF alone failed. It is saying the SMTP connection used for the message did not meet the TLS requirement.

Check the actual outbound path, not only the domain

The route that matters is the server path that connected to Gmail. That might be your mail server, an outbound gateway, a security appliance, an SMTP relay, an ESP, or a backup route used only for some messages.

If one mail stream fails and another succeeds, compare the routes. A newsletter tool, CRM, on-prem Exchange connector, backup relay, or regional SMTP pool may have different TLS settings than normal user mail.

The Gmail bounce and sending logs are the best evidence. A public domain check cannot see the exact TLS negotiation Gmail saw for a specific delivery attempt.

Understand what TLS proves in email delivery

SMTP STARTTLS, described in RFC 3207, lets SMTP peers upgrade a plaintext SMTP connection to a TLS-protected connection. TLS protects message transport between servers; it is not the same as SPF, DKIM, or DMARC authentication.

Google's TLS setup documentation says Gmail normally tries to use TLS when sending mail, but secure transport requires both sides of a connection to support TLS. For sender requirements, the important point is that bulk senders must use TLS/SSL for SMTP connections to Gmail.

MTA-STS, described in RFC 8461, is a receiving-domain policy mechanism. It can strengthen inbound transport security for a domain, but it is not direct proof that a particular outbound message to Gmail used TLS.

Check TLS settings on the sender or relay

For your own server or gateway, inspect SMTP logs and TLS settings. Look for whether the server offered STARTTLS, whether the connection upgraded, which TLS version was negotiated, and whether certificate validation failed.

For Google Workspace, Microsoft 365, or an ESP, check the provider's outbound TLS settings and route configuration. Some systems let administrators require TLS for specific domains or routes. A misconfigured route can bounce when TLS is required but negotiation fails.

For third-party relays, open a support case with the exact Gmail bounce, timestamp, sender, recipient domain, and message ID if available. The relay provider is often the only party with the SMTP transcript.

Check certificates and hostname validation when TLS is required

TLS can fail even when a server "supports TLS." Certificate problems, hostname mismatch, expired certificates, unsupported TLS versions, or policy settings that require certificate validation can all break delivery.

Google's TLS setup docs describe options such as requiring a CA-signed certificate and validating the certificate hostname for configured secure transport. If those checks fail on a required-TLS route, messages can bounce.

This is why a simple "TLS supported" result is not always enough. For a Gmail 5.7.29 bounce, the evidence should come from the actual sender logs or provider route diagnostics.

Use the Relaymetry TLS check for posture, not message-specific proof

Relaymetry's TLS check is useful for public domain posture: inbound SMTP TLS support, certificate basics, and related policy signals such as MTA-STS or TLS-RPT where implemented.

That does not prove the outbound SMTP session from your sender to Gmail used TLS. The outbound session depends on the sending platform, route, relay, policy, and runtime negotiation.

The route should say this clearly near the widget. The TLS checker helps find visible transport-security gaps. The bounce and logs prove what happened to a particular message.

How to fix Gmail 5.7.29

1. Keep the full Gmail bounce text.
2. Identify the sending platform and outbound route.
3. Check SMTP logs for STARTTLS negotiation if you control the sender.
4. Confirm the route requires and supports TLS where needed.
5. Check certificate validity and hostname validation settings.
6. If an ESP or relay sent the message, provide the bounce to that provider.
7. Send a controlled test through the same route after changes.
8. Continue with SPF, DKIM, DMARC, and reputation checks after TLS is fixed.

What this does not prove

Fixing Gmail 5.7.29 proves only that you addressed a TLS transport failure path. It does not prove authentication passes, Gmail reputation is healthy, content is safe, or accepted mail will land in the inbox.

Relaymetry cannot prove the TLS state of a specific outbound SMTP session to Gmail from a domain lookup. That requires bounce context, sender logs, or provider diagnostics.

Related guides

• Why Gmail rejects emails from your domain
• Gmail Postmaster Tools vs public checks
• Emails from my domain go to Gmail spam