4.7.30

Enhanced Status Code 4.7.30: Rate Limited - DKIM Authentication Failed

Temporary failure High severity Authentication RFC 8689
What it means

Enhanced Status Code 4.7.30 means “Rate Limited - DKIM Authentication Failed.” Google is throttling your mail specifically because DKIM did not pass. Unlike a general reputation deferral, this one names a single mechanism, so the fix is unambiguous.

At a glance
Code4.7.30
Bounce typeSoft (temporary)
SeverityHigh
CategoryAuthentication
What to doQueued and retried automatically
StandardRFC 8689
What it looks like in your mail logs
421 4.7.30 Email rate limited. DKIM authentication failed for the sending domain

What does 4.7.30 mean?

Google returns 4.7.30 with a 421 reply and text saying the message is rate limited because DKIM authentication failed. The registry assigns X.7.30 to REQUIRETLS support being required, which is the meaning that applies to the permanent 5.7.30 in specification terms. The temporary form as senders meet it is Google's DKIM throttle.

DKIM can fail in ways that are invisible from the sending side, which is what makes this code valuable. The signature may be absent because one of several sending paths was never configured to sign. The public key may not resolve at the selector named in the header. The body may be modified in transit by a list or forwarder, invalidating the hash. Or a key rotation may have replaced the private key while the DNS record still carries the old public one. Google is telling you which mechanism to look at, which narrows a diagnosis that is otherwise slow.

Since the February 2024 sender requirements, DKIM is not optional for anyone sending at volume, and it is the mechanism that survives forwarding where SPF cannot. A sender being throttled on DKIM today is a sender who will be rejected on DMARC tomorrow, because a domain that cannot produce a passing signature cannot satisfy an enforcing policy either.

How 4.7.30 plays out

Your server attempts delivery
The recipient defers with a temporary 4.7.30 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.30 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.30 is✓ this code

What each provider means by 4.7.30

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 DKIM authentication failed Reference
IANA registry The registry assigns 4.7.30 to REQUIRETLS support required Reference

Common causes of 4.7.30

  • DKIM signing is not enabled on the sending platform producing this traffic
  • The public key does not resolve at selector._domainkey for the signing domain
  • The signing key was rotated without the DNS record being updated
  • The message body was modified in transit, invalidating the body hash
  • The DNS TXT record is malformed or split incorrectly across strings
  • One sending path signs correctly while another does not, so failures look intermittent

How to fix 4.7.30

  • Verify the public key resolves for the selector with DKIM Record Checker
  • Send a test message and read dkim= in the Authentication-Results header
  • Enable signing on every platform that sends as your domain, not just the main one
  • Re-publish DNS after any key rotation and respect TTL before retiring the old key
  • Confirm the signing domain aligns with the From header so DMARC passes too
  • Where mail traverses lists or forwarders, check that ARC is preserving the original result

Frequently asked questions

What does 421 4.7.30 mean from Google?
It means your mail is being rate limited because DKIM authentication failed. It is a temporary deferral rather than a rejection, so messages retry and usually arrive, but at reduced throughput until a passing signature is in place. The code names DKIM specifically, so SPF and content are not the issue here.
Why does the registry say 4.7.30 is about REQUIRETLS?
IANA assigns X.7.30 to REQUIRETLS support being required, which is the correct reading for the permanent 5.7.30. Google occupied the temporary form for DKIM rate limiting. Both meanings are genuine, so this page documents the provider usage alongside the registry definition instead of pretending only one exists.
DKIM passes on my test messages, so why am I still throttled?
Almost always because more than one system sends as your domain and only the one you tested is signing. Invoicing, ticketing, CRM and notification platforms each need signing configured separately. Send a test through every path that uses your domain, not just the marketing platform, and check dkim= in the headers of each.
How is this different from 4.7.26?
Precision. 4.7.26 means multiple authentication checks failed, leaving both SPF and DKIM in scope. 4.7.30 names DKIM alone, which usually means SPF is passing. That narrows the work considerably, so it is worth reading the exact code rather than treating all authentication deferrals as one problem.
Will this become a permanent failure?
It will if the domain publishes a DMARC policy of quarantine or reject, because a message with no passing DKIM signature and no aligned SPF pass cannot satisfy DMARC. At that point the deferral becomes a 5.7.26 rejection. Fixing the signature now avoids that transition entirely.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes