550 5.7.29: TLS required for bulk senders (Gmail)

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code 550: “Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)” (RFC 5321 §4.2.3).
• Enhanced code 5.7.29: “ARC validation failure” in the IANA registry (RFC 8617), in the group security or policy status (RFC 3463 §3.8).
• Who uses it: Gmail uses it for bulk mail sent without TLS; the IANA registry name is ARC validation failure (RFC 8617).

If Gmail sent this bounce, 5.7.29 means you send in bulk and delivered the message without TLS encryption. In the official registry the code means something else: an ARC validation failure.

Two meanings for one code

Gmail's use differs from the IANA registry, so check which server sent the bounce and read its text.

• The registry meaning. The IANA registry lists X.7.29 as "ARC validation failure", registered by RFC 8617 §10.4. ARC (Authenticated Received Chain) lets servers that pass a message along, such as mailing lists and forwarders, record the authentication results they saw and seal them. RFC 8617 §5.2.2 lets a receiver answer 5.7.29 when that chain does not validate.
• Gmail's meaning. Gmail uses 550 5.7.29 when a bulk sender's message did not arrive over TLS, and 421 4.7.29 when it rate limits for the same reason (Google's SMTP error reference).

Common causes

For Gmail:

• Your outgoing server does not offer or use STARTTLS when it connects.
• TLS is turned off for outgoing mail in the server's configuration, or limited to some destinations.
• The TLS handshake fails (an outdated TLS library or settings), and the server falls back to sending in plain text.

For an ARC failure:

• You run a list or forwarder whose ARC signing is broken (wrong key, or the message changes after sealing).
• The message passed through an intermediary whose ARC seal does not check out.

How to fix it

Gmail TLS requirement:

1. Turn on opportunistic TLS (STARTTLS) for outgoing mail on your server or relay.
2. Check the server's logs for TLS handshake errors toward Gmail, and update the TLS library or settings if the handshake fails.
3. If you send through a relay or sending service, confirm with it that outgoing connections use TLS.
4. Google's sender guidelines require a TLS connection from every sender, not only bulk senders. Bulk senders (around 5,000 or more messages a day to personal Gmail accounts) are the ones Gmail blocks with this code.
5. Resend once TLS works. Retries from your queue will go through once the connection is encrypted.

ARC failure:

1. If you run the intermediary, check its ARC keys in DNS and that it seals after all of its own changes to the message.
2. If not, contact whoever runs the list or forwarder.

What to do with the address

Keep it. Neither meaning says anything about the recipient's mailbox. For related Gmail bulk-sender rules, see 5.7.30 (DKIM) and 530 5.7.0 for servers that require STARTTLS before you send.

Related codes

• 550 5.7.30: DKIM failed for a bulk sender (Gmail)
• 421 4.7.0: Temporarily refused: reputation, DNS or TLS
• 530 5.7.0: Authentication or STARTTLS required

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.