550 5.7.30: DKIM failed for a bulk sender (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.30: “REQUIRETLS support required” in the IANA registry (RFC 8689), in the group security or policy status (RFC 3463 §3.8).
• Who uses it: Gmail uses it for DKIM failures of bulk senders; the IANA registry name is REQUIRETLS support required (RFC 8689).

If Gmail sent this bounce, 5.7.30 means you send in bulk and your message failed DKIM. In the official registry the same code means "REQUIRETLS support required", which is about encryption, not signing.

Two meanings for one code

Gmail's use differs from the IANA registry, so the server that sent the bounce matters.

• The registry meaning. The IANA registry lists X.7.30 as "REQUIRETLS support required", from RFC 8689 §7. REQUIRETLS lets a sender demand that every hop delivers the message over TLS. Under RFC 8689 §4.2.1, a server returns 5.7.30 when the message carries that demand and the next server does not support REQUIRETLS.
• Gmail's meaning. Gmail uses 550 5.7.30 when a bulk sender's message fails DKIM, and 421 4.7.30 when it rate limits for the same reason (Google's SMTP error reference).

The text after the code says which one you have.

Common causes

For Gmail:

• The DKIM public key is missing from DNS at the selector named in the signature, or it was mistyped.
• The key in DNS does not match the private key that signed, often after a key rotation.
• Something changed the message after it was signed: a footer, a rewritten link, a subject tag added by a relay.
• A sending service signs with its own domain, while your own domain has no signing set up.

For REQUIRETLS:

• The message was sent with REQUIRETLS, and a server on the path does not offer it.

How to fix it

Gmail DKIM failure:

1. Find the s= (selector) and d= (domain) values in the DKIM-Signature header of a sent copy.
2. Look up that key with the DKIM checker. If it is missing or wrong, publish the key your sending service gives you, or create a key pair with the DKIM generator.
3. Make sure nothing edits the message after signing, or move the signing step to the last server before delivery.
4. When you rotate keys, publish the new key before you start signing with it, and leave the old key up for a while.
5. Sign with your own From: domain so DKIM also lines up for DMARC (see 5.7.32). Google's sender guidelines ask bulk senders for SPF, DKIM and DMARC.

REQUIRETLS:

1. Send without REQUIRETLS, or deliver through a route where every hop supports it.

What to do with the address

Keep it. The recipient is fine; fix your signing and resend.

Related codes

• 550 5.7.26: Unauthenticated: SPF and DKIM failed, or DMARC rejected it
• 550 5.7.27: SPF failed for a bulk sender (Gmail), or the sender has a null MX
• 5.7.32: From: domain not aligned with SPF or DKIM (Gmail)

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.