Enhanced Status Code 4.7.30: Rate Limited - DKIM Authentication Failed
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.
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
4.7.30 replyWhere 4.7.30 sits: soft vs hard bounce
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| SMTP class | 4xx | 5xx |
| What to do | Let it retry | Suppress the address |
| Recoverable? | Often | No |
| 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.
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