Gmail 421 4.7.29 and 550 5.7.29: Mail Not Sent Over TLS, and How to Fix It

421 4.7.29 and 550 5.7.29 are Gmail refusing to take mail over an unencrypted connection. The 421 says your email "has been rate limited because the connection doesn't use TLS"; the 550 says the message was blocked because it "was not sent over a TLS connection." Google has required TLS for all senders since its sender rules came in, so this isn't a bulk-sender problem. It almost always means one thing: the server, app or script that connects to Gmail has TLS turned off or doesn't know how to use it. Turning it on is usually a one-line change.

Paste the bounce into the bounce message analyzer to confirm the code.

What Google says

Code	Google's message, shortened	Type
421 4.7.29	Rate limited because the connection doesn't use TLS	Temporary
550 5.7.29	The message was not sent over a TLS connection	Permanent

Source: Google's Gmail SMTP errors and codes (last updated 26 October 2026, read 2 November 2026). Google's email sender guidelines (read 2 November 2026) list TLS among the requirements for all senders: "Use a TLS connection for transmitting email." The same list includes SPF or DKIM, a PTR record and RFC 5322 formatting; our bulk sender requirements guide covers them all.

How TLS works for mail between servers

When one mail server delivers to another, it connects on port 25 in plain text. If the receiving server offers TLS (it lists STARTTLS in its reply to EHLO), the sender can issue STARTTLS, and the rest of the conversation is encrypted. This is called opportunistic TLS: use encryption when the other side offers it.

Gmail offers STARTTLS. So any sending server that supports it and has it switched on will use it. These codes mean your sender either doesn't support it or has been told not to use it.

Who still sends without TLS

Sender	Why
A self-hosted Postfix or Exim server with outbound TLS off	The setting was never turned on, or was turned off while debugging
An old mail server or appliance	Its TLS library is too old to complete a handshake with a modern server
A script that talks SMTP directly to Gmail's MX	It connects and sends without calling STARTTLS
A printer, scanner or alarm panel set to deliver directly	Many devices only support plain SMTP
A relay in the middle that strips TLS	A filter or gateway between your server and the internet

Mainstream email platforms, Google Workspace, Microsoft 365 and sending services use TLS to Gmail by default. If you send through one of them and still see these codes, check whether something in your own network handles outbound mail before it reaches them.

How to fix it

Postfix

In main.cf, set:

smtp_tls_security_level = may

may is opportunistic TLS: use it when the receiving server offers it, which Gmail does. Reload Postfix afterwards. If the log shows TLS handshake failures instead, the system's OpenSSL is usually too old; update it.

Don't confuse it with smtpd_tls_security_level, the setting for mail coming in to your server.

Exim

Exim's smtp transport decides when to try TLS with the hosts_try_tls and hosts_avoid_tls options. Check that hosts_avoid_tls doesn't match Gmail's servers and that hosts_try_tls covers them, and confirm your Exim build has TLS support (exim -bV lists it).

Scripts and apps

If your code connects to Gmail's MX servers directly, call STARTTLS after EHLO and before sending. In Python's smtplib, that's server.ehlo(), server.starttls(), then server.ehlo() again. Most other languages' SMTP libraries have an equivalent option, often called secure, requireTLS or startTLS.

Better still, don't deliver directly from an app at all. Send through an authenticated relay on port 587, which uses TLS and also avoids the direct-send block for end-user IPs. The SMTP settings lookup has host, port and security settings for common providers.

Devices

For printers, scanners and alarm systems, check for a firmware update that adds TLS, or point the device at an internal relay that accepts plain mail locally and delivers onward over TLS. Your mail provider may offer a relay option designed for devices.

How to test

From the sending host, with openssl

openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -crlf

Run this from the server that sends the mail. If it prints a certificate chain and ends with a 250 reply, that host can set up TLS with Gmail. If it fails, the problem is on that host: an outdated OpenSSL, a firewall that blocks port 25, or something in between that interferes. If port 25 is blocked outright, read cloud providers block port 25.

With a real message

Send a message from the same server to a Gmail address you control. Open it, choose Show original, and look at the Received: line added by Google. A TLS connection shows a TLS version and cipher, such as version=TLS1_3. Gmail also shows a red padlock on messages it received without encryption. The email header analyzer shows each hop and how it was received.

The codes it gets confused with

Code	What it means	What to do
421 4.7.29 / 550 5.7.29	Delivery to Gmail without TLS	Turn on outbound STARTTLS
530 5.7.0 "Must issue a STARTTLS command first"	Your app tried to log in to Google's submission server (smtp.gmail.com) without TLS	Use port 587 with STARTTLS or port 465 with TLS. See /smtp/530-5-7-0
550 5.7.25	No PTR record for the sending IP	Set reverse DNS. See reverse DNS and PTR records
421 4.7.27 / 4.7.30	SPF or DKIM didn't pass	See Gmail authentication rate limits

What about MTA-STS and TLS-RPT?

These are often mentioned alongside TLS errors, but they work in the other direction. MTA-STS is a policy you publish to tell other servers they must use TLS, with a valid certificate, when they send mail to your domain. TLS-RPT asks those servers to send you reports when TLS fails on the way in. Both are good practice for receiving mail securely, and the MTA-STS checker and TLS-RPT checker test them. Neither changes how your server sends to Gmail.

A short checklist for self-hosted senders

• Outbound TLS is on (smtp_tls_security_level = may in Postfix).
• openssl s_client -starttls smtp to Gmail works from the sending host.
• The sending IP has a PTR record that resolves back to it.
• SPF covers the IP, DKIM signs with your domain, and a DMARC record exists.
• The IP isn't on a policy blocklist for end-user ranges.

The deliverability audit checks the DNS side of a domain in one pass.

Where SimpleVerifier fits

TLS is about your connection to Gmail, so verification doesn't touch it. Once your server delivers over TLS, the list decides the rest. SimpleVerifier runs a live mailbox check on each address and returns safe to send, send with care, check again later or do not send, with the reason. Catch-alls stay risky, never guessed valid.

The first 100 checks are free with a Google sign-in on the verify page. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.