4.7.29

Enhanced Status Code 4.7.29: Rate Limited - Connection Not Encrypted

Temporary failure High severity Security RFC 8617
What it means

Enhanced Status Code 4.7.29 means “Rate Limited - Connection Not Encrypted.” Google is throttling your mail because the connection did not use TLS. Opportunistic encryption is no longer optional at volume, and cleartext delivery now costs you throughput.

At a glance
Code4.7.29
Bounce typeSoft (temporary)
SeverityHigh
CategorySecurity
What to doQueued and retried automatically
StandardRFC 8617
What it looks like in your mail logs 
421 4.7.29 Email rate limited. The message was not sent over a TLS connection

What does 4.7.29 mean?

Google returns 4.7.29 with a 421 reply and text saying the message is rate limited because a TLS connection was not used. The registry assigns X.7.29 to ARC validation failure, which is the meaning that applies to the permanent 5.7.29 in specification terms, but the temporary form as senders encounter it is Google's TLS throttle.

The cause is usually not a decision to send in cleartext. It is a server that offers STARTTLS but fails to negotiate, or one where STARTTLS was never configured because it was not required when the server was built. Some older MTAs also fall back to cleartext silently when a TLS handshake fails, converting a certificate problem into an encryption problem without logging either clearly. If you are seeing this code, the first question is whether your outbound MTA is attempting STARTTLS at all.

This is a direction of travel rather than a one-off rule. Receivers have moved from tolerating cleartext, to preferring TLS, to penalising its absence, and MTA-STS makes the requirement explicit and enforceable. A sender still delivering in cleartext in 2026 is accumulating friction across multiple providers, not just Google.

How 4.7.29 plays out

Your server attempts delivery
The recipient defers with a temporary 4.7.29 reply
Your server queues the message and retries on a back-off schedule
It delivers on a later attempt, or becomes a hard bounce if it keeps failing

Where 4.7.29 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
4.7.29 is✓ this code

What each provider means by 4.7.29

A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.

Gmail Email rate limited because a TLS connection was not used Reference
IANA registry The registry assigns 4.7.29 to ARC validation failure Reference

Common causes of 4.7.29

  • STARTTLS is not enabled on the outbound mail server
  • The TLS handshake fails and the MTA silently falls back to cleartext
  • The server offers only TLS versions the receiver has retired, such as 1.0 or 1.1
  • No certificate is configured, so the server cannot complete a handshake
  • A firewall or proxy is stripping the STARTTLS capability from the conversation
  • An old MTA build has opportunistic TLS disabled by default

How to fix 4.7.29

  • Enable STARTTLS on the outbound server and confirm it is offered on the connection
  • Test with openssl s_client -starttls smtp against the destination and read the negotiated version
  • Enable TLS 1.2 and 1.3 and remove TLS 1.0 and 1.1
  • Check the MTA logs for silent cleartext fallback after a failed handshake
  • Verify no middlebox is stripping the STARTTLS advertisement
  • Publish MTA-STS for your own domain once outbound TLS is reliable

Frequently asked questions

What does 421 4.7.29 mean from Google?
It means your message was rate limited because the connection did not use TLS. Google is not refusing cleartext outright, it is giving unencrypted mail a smaller share of capacity. The usual cause is not a deliberate choice but an outbound server that never had STARTTLS configured, or one that attempts it, fails, and falls back to cleartext without saying so.
How do I check whether my server is actually using TLS?
Run openssl s_client -starttls smtp -connect the-destination-mx:25 from the sending host and read the negotiated protocol and cipher. Then check your own MTA logs for the outbound connection and confirm it records a TLS version. Silent fallback after a failed handshake is common and is the reason many operators believe they are encrypting when they are not.
Why does the registry say 4.7.29 is about ARC?
IANA assigns X.7.29 to ARC validation failure, which is the correct reading of the permanent form. Google occupied the temporary form for its TLS throttle. Both meanings are real, which is why this page carries the provider usage alongside the registry definition rather than choosing one and hiding the other.
Is TLS actually required now, or just preferred?
Both, depending on the destination. Google throttles rather than rejects, so cleartext still delivers slowly. But MTA-STS lets a receiving domain declare TLS mandatory and enforceable, and a growing number do. The practical answer is that cleartext delivery is now a liability at every provider, and the cost is rising.
Could a certificate problem cause this rather than missing TLS?
Yes, and it is a common confusion. If the handshake fails because of an expired or mismatched certificate and your MTA falls back to cleartext, the receiver reports missing encryption while the real fault is the certificate. Check 5.7.5 for cryptographic failures if the handshake is being attempted and refused rather than never offered.

Related bounce codes

5.7.30 REQUIRETLS Support Required 5.7.5 Cryptographic Failure 4.7.5 Cryptographic Failure - Temporary 4.7.28 Mail Flood Detected - Temporary Rate Limit 5.7.4 Security Features Not Supported

Sources & further reading

RFC 8617 · The standard that defines this reply code Gmail SMTP errors and codes · Google Workspace reference for every code Gmail returns IANA registry · The authoritative list of enhanced status codes and their meanings
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes