Why am I getting TLS errors when sending to Gmail?
Updated on 21 Oct 2026: We clarified Gmail TLS errors and added checks for MTA-STS delivery failures.
If the response includes 421 4.7.29, Gmail received the affected SMTP transaction without TLS and temporarily rate limited the mail. Google also documents 550 5.7.29 for messages blocked because they were not sent over TLS. Gmail's sender guidelines require TLS for all senders to personal Gmail accounts, while the text of these errors specifically calls out bulk senders.
The fix is not a DMARC record change. First prove whether the affected outbound server negotiated STARTTLS with Google's MX host for the exact failed transaction. Then check the outbound TLS policy, supported protocols and ciphers, local CA trust store, system clock, network path, routing, and whether only one sending pool or relay has the fault.
Typical Gmail TLS deferraltext
421-4.7.29 Your email has been rate limited because this message wasn't sent 421-4.7.29 over a TLS connection. Gmail requires all bulk email senders 421-4.7.29 to use TLS/SSL for SMTP connections.
First identify which Gmail connection failed
The phrase 'sending to Gmail' describes two different SMTP paths. Identify the hostname and response code before changing TLS settings, because a receiving-MX error and a Gmail account submission error do not share the same diagnosis.
Sending to Gmail recipients
- Connection: Your MTA connects to a Gmail MX host, normally on port 25.
- Key errors: 421 4.7.29 defers mail and 550 5.7.29 blocks mail sent without TLS.
- Fix: Repair STARTTLS on the exact outbound MTA, relay, or fallback route.
Sending through a Gmail account
- Connection: An app or device connects to smtp.gmail.com or smtp-relay.gmail.com.
- Key errors: 530 5.7.0 with 'Must issue a STARTTLS command first' requires encryption. Other 530 responses and 534 or 535 errors concern authentication; read the full response.
- Fix: Use STARTTLS on port 587 or implicit TLS on 465. For smtp.gmail.com, configure OAuth or an eligible app password. For smtp-relay.gmail.com, check the administrator's IP or SMTP authentication settings.
Do not label every Gmail SMTP error a TLS failure
A device with old firmware can fail TLS negotiation because its protocol or cipher support is obsolete. Update its firmware or TLS library when the handshake fails. An authentication response after TLS succeeds needs an account or authentication fix. App passwords require 2-Step Verification and an account that permits them.
What the Gmail TLS error means
For server-to-server email, the sending MTA connects to a Gmail MX host on SMTP port 25, reads the EHLO capabilities, sees STARTTLS, issues STARTTLS, completes the TLS handshake, then sends EHLO again before continuing the SMTP transaction inside the encrypted session. When Gmail says the message was not sent over TLS, that encrypted session was not present for the transaction Gmail judged. It does not mean the sending host's own certificate must be renewed.
Google requires TLS for every sender delivering to personal Gmail accounts, with additional authentication requirements for bulk senders, about 5,000 or more messages to personal Gmail accounts in 24 hours. Messages sent through subdomains count toward the same primary domain total. Its Gmail TLS guide explains secure transport settings for Google Workspace routes. A sudden start date often means an existing path problem became visible after a route, sending pool, volume level, TLS library, or enforcement condition changed.
Do not stop at a green test
A single successful TLS test proves only that one test path worked. It does not prove every production message to Gmail used TLS. If the error is common or repeatable, capture the exact deferred transaction in outbound logs and confirm STARTTLS happened on that same session.
SMTP STARTTLS flow for delivering email securely to Gmail.
The most common causes
The cause usually sits in outbound SMTP infrastructure, not in your DMARC policy. Gmail TLS errors fit six practical buckets, and each bucket points to a different owner and fix.
- No STARTTLS: The sending MTA connects to Gmail but never upgrades the SMTP session to TLS.
- Broken handshake: STARTTLS begins, then fails because of protocol, cipher, trust-store, firewall, or traffic-inspection behavior.
- Remote certificate validation: The sender cannot validate Gmail's certificate because its CA bundle is stale, its system clock is wrong, or a network device substitutes another certificate.
- Mixed sending pools: Most mail uses TLS, but one IP pool, relay, container, or fallback route still sends in clear text.
- Policy enforcement: A route that previously delivered without TLS now receives Gmail's 4.7.29 or 5.7.29 response.
- Unsafe fallback: A temporary DNS, network, or handshake failure sends the MTA onto a route that retries without TLS.
|
|
|
|---|---|---|
421 4.7.29 or 550 5.7.29 | No TLS | Outbound MTA administrator |
Verify error | Trust store, clock, hostname, or interception | Infrastructure team |
One IP only | Bad pool | Sending provider or infrastructure team |
All domains | Relay config | Platform team |
Fast mapping from symptom to likely owner.
Intermittent errors
- Scope: A small share of Gmail deliveries fail, then later retry and deliver.
- Pattern: Failures cluster around one outbound host, route, IP, or time window.
- Action: Compare successful and deferred transactions for the same Gmail MX.
Systemic errors
- Scope: Most or all Gmail deliveries defer with the same TLS message.
- Pattern: Every sender, campaign, or domain that uses the route is affected.
- Action: Fix outbound TLS configuration before increasing volume again.
How to prove what Gmail saw
The fastest path is evidence from the exact SMTP transaction. A general TLS scan, successful test message, or certificate check can help, but it does not replace the delivery log for the message Gmail deferred or blocked.
- Find the event: Search outbound logs for Gmail responses containing 4.7.29 or 5.7.29 and the affected message ID.
- Record the route: Note the source IP, relay, hostname, container, queue, and Gmail MX host.
- Confirm STARTTLS: Look for EHLO, STARTTLS, TLS protocol, cipher, certificate verification, and post-TLS SMTP lines.
- Compare a pass: Compare one accepted Gmail delivery from the same sending path.
- Retest cleanly: Send a controlled message from the same production pool and capture the SMTP trace.
Manual STARTTLS check to a Gmail MXbash
openssl s_client -starttls smtp \ -connect gmail-smtp-in.l.google.com:25 \ -servername gmail-smtp-in.l.google.com \ -verify_hostname gmail-smtp-in.l.google.com \ -verify_return_error -brief
Run that command on the failing outbound host and substitute the MX hostname recorded in its logs in all three hostname arguments. It checks STARTTLS, certificate-chain trust, and certificate hostname matching. The -servername option sends SNI; -verify_hostname performs the hostname check. A timeout before the SMTP banner points to connectivity or blocked outbound port 25, rather than a TLS handshake failure. If IPv4 and IPv6 use different routes, repeat with -4 and -6. A successful test does not prove that the production MTA requires STARTTLS or that every outbound host uses the same path.
Google Admin console Secure transport (TLS) compliance settings.
Fixes by cause
Once the failing route is known, the fixes are direct. Treat Gmail's TLS response as an infrastructure incident first, then check DNS and authentication after the mail path is stable.
Fix checklist
- Enable STARTTLS: Make TLS mandatory for Gmail-bound mail on every production route.
- Update trust stores: Install a current CA bundle and correct the system clock on every outbound host.
- Validate Gmail's identity: Use the published Gmail MX hostname and investigate any substituted or mismatched certificate.
- Remove weak TLS: Update the MTA or device firmware to support TLS 1.2 or 1.3 with supported ciphers. Gmail stopped accepting 3DES for inbound SMTP in May 2025; a 3DES-only sender cannot deliver.
- Fix routing: Make every fallback relay and warmup pool use the same TLS policy.
- Resume retries carefully: Let messages deferred with 421 4.7.29 retry after the fix, without a manual burst that creates fresh rate limiting. A 550 5.7.29 is a permanent rejection; resend affected messages after fixing TLS and confirming they were not already delivered.
If the sender reports a certificate validation error while connecting directly to Gmail, inspect the certificate received on that route. A stale CA bundle, incorrect system time, TLS-inspecting firewall, or incorrect MX target can break verification. Replacing the outbound host's own web or SMTP certificate does not repair that client-side validation path.
For a Google Workspace custom route, check Apps > Google Workspace > Gmail > Compliance > Secure transport (TLS) compliance. Google's TLS troubleshooting guidance explains that saving a route does not resolve a failed 'Test TLS connection' certificate check; affected messages still bounce. Correct the receiving route's hostname or certificate and keep certificate validation enabled.
When to escalate the issue
Use the scope of the failure to distinguish a single retry from a configuration incident.
Low
One retry
One deferral retries successfully through the same encrypted route.
Watch
One route
Repeated responses map to one outbound host, pool, or relay.
Incident
Many routes
Gmail-bound queues grow across multiple production routes.
Where DNS and authentication fit
TLS and DMARC answer different questions. A DMARC pass does not prove the SMTP connection to Gmail was encrypted, and a TLS pass does not prove the message passed DMARC. Gmail requires all senders to personal accounts to use TLS and pass SPF or DKIM. Bulk senders need both SPF and DKIM plus a DMARC record with at least p=none. For direct mail, the visible From: domain must also match the SPF or DKIM domain under DMARC's domain-matching rules.
Suped's DMARC reporting product helps teams review aggregate authentication results and identify SPF or DKIM domain-matching failures. Use those reports to investigate separate authentication faults while the infrastructure owner checks outbound logs and repairs TLS.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For sender-domain triage, check the domain health checker after collecting the SMTP logs. Transport evidence answers whether Gmail saw TLS, while the domain checks expose separate SPF, DKIM, or DMARC failures.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Publishing an MTA-STS policy for your domain protects inbound mail by telling supporting senders to require validated TLS when the policy is in enforce mode. Publishing that policy does not configure your outbound MTA. Suped's Hosted MTA-STS product hosts and maintains that inbound policy for your domain. Outbound delivery depends on your MTA's STARTTLS settings and any recipient MTA-STS policy it enforces.
How MTA-STS affects delivery to Gmail
Gmail publishes its own MTA-STS policy. If your outbound MTA supports MTA-STS and applies the recipient's policy in enforce mode, RFC 8461 requires it to withhold delivery when the MX host is not permitted, STARTTLS is unavailable, or certificate validation fails. This sender-side failure is distinct from Gmail returning 421 4.7.29 after an unencrypted transaction.
- Inspect the recipient domain's _mta-sts TXT record, HTTPS policy, and the policy cached by the sending MTA.
- Compare the chosen MX hostname with the policy's mx entries and the certificate's subject alternative names.
- Verify certificate expiry and the CA chain using the same trust store as the production MTA.
- Repair the failing route and retain TLS enforcement while queued messages retry. Do not bypass certificate checks or fall back to clear text.
TLS-RPT reports received for your own domain describe inbound delivery attempts. Use outbound MTA logs to investigate messages sent to Gmail.
Gmail TLS troubleshooting sequence
When a Gmail TLS error appears suddenly, use this order to separate transport evidence from unrelated DNS changes.
Do first
- Capture logs: Find one exact Gmail response and the route that sent it.
- Check TLS: Confirm STARTTLS, protocol, cipher, and remote certificate verification for that route.
- Compare paths: Separate working pools from failing pools before changing DNS.
Do after
- Fix route: Apply the TLS fix to every outbound and fallback route.
- Check DNS: Use the domain health checker for related records.
- Watch retries: Confirm deferred Gmail queues recover without a new spike.
If the failure pattern includes reduced send rates as well as STARTTLS errors, the related guide on Google STARTTLS errors helps separate transport failure from throttling behavior.
Views from the trenches
Best practices
Capture the exact deferred Gmail transaction before changing unrelated DNS records.
Check every outbound pool, relay, and fallback route for consistent STARTTLS support.
Retest after trust-store or TLS policy changes and confirm Gmail queues recover.
Common pitfalls
A single successful TLS test does not prove production Gmail traffic used TLS at all.
Teams often fix the primary relay and leave a fallback path sending without TLS.
Teams renew the sending host certificate even when the remote trust path is failing.
Expert tips
Treat 421 4.7.29 as transport evidence, then validate DMARC as a separate layer.
Compare accepted and deferred Gmail sessions from the same IP before escalating.
Use controlled test sends only after the failing production route has been found.
Expert view
Expert from Email Geeks says the error means the sender or its ESP needs outbound TLS configured or repaired.
2024-12-13 - Email Geeks
Expert view
Expert from Email Geeks says Gmail is treating the session as missing STARTTLS, so deferred transaction logs matter most.
2024-12-13 - Email Geeks
Frequently asked questions
No. TLS encrypts the SMTP connection, while DMARC applies domain authentication policy. A message can pass DMARC and still be deferred or blocked if the delivery to Gmail does not use TLS.
A working setup can fail after a certificate expires or the effective path changes, even if the primary MTA settings are unchanged. Check the CA trust store, device firmware, fallback relays, and network inspection. Compare successful and failed transactions before attributing the change to Gmail.
No. For server-to-server delivery to Gmail MX hosts, SMTP normally starts on port 25 and upgrades with STARTTLS. Apps submitting through Gmail commonly use STARTTLS on port 587 or implicit TLS on port 465.
Publishing MTA-STS for your domain does not configure outbound TLS. Your sending MTA can enforce Gmail's own MTA-STS policy, which prevents delivery over a connection that fails its checks. Repair STARTTLS or certificate validation on the outbound route; changing your inbound policy does not fix that failure.
Ask for the source IP, relay hostname, Gmail MX host, STARTTLS result, negotiated protocol and cipher, remote certificate verification result, and SMTP transcript or log excerpt for the exact failed message.
Treat it as SMTP submission. Match STARTTLS to port 587 or implicit TLS to port 465. If the handshake fails, check device firmware and supported ciphers before changing credentials. If TLS succeeds but Gmail returns 534 or 535, check OAuth or an eligible app password. App passwords require 2-Step Verification; Google Workspace account policy also controls their availability.
