Quick answer
Gmail 5.7.30 means Gmail blocked the message because DKIM authentication did not pass. The related 4.7.30 code is the temporary rate-limit variant. Check whether the sending platform is actually signing the message, which DKIM selector Gmail saw, whether the public key exists in DNS, and whether the signing domain aligns with the visible From domain for DMARC.
Gmail 5.7.30 is a DKIM-specific authentication failure
Google's sender guidelines FAQ maps 5.7.30 to messages blocked because DKIM authentication did not pass. The temporary variant is 4.7.30; the permanent rejection variant is 5.7.30. Both indicate Gmail evaluated DKIM for the message and did not get a passing result.
DKIM is not only a DNS record. It is a signature on the message. DNS publishes the public key, but the sending platform must add the DKIM-Signature header to outgoing mail.
Check whether the message was signed at all
DKIM, defined in RFC 6376, works by signing message headers and body content with a private key. Receivers fetch the matching public key from DNS using the selector and signing domain in the message.
A domain can have a correct DKIM DNS record and still send unsigned mail. This happens when DKIM was added in DNS but not enabled in the ESP or mail platform, when the wrong domain is selected in the provider UI, or when one sending stream uses a different provider.
The first message-specific check is the Gmail header. Look for dkim=pass, dkim=fail, or the DKIM-Signature header that includes d= for signing domain and s= for selector.
Use the selector Gmail saw
Public DKIM lookup requires a selector. A DKIM key is usually published at <selector>._domainkey.<domain>. Without the selector, a checker cannot reliably know every possible key location for every provider.
This is the DKIM selector-scan limitation: some common selectors can be guessed, but there is no universal public directory of all selectors a domain might use. A DNS-only tool should not claim it checked every DKIM key unless the selector was supplied or discovered from a real message header.
For Gmail 5.7.30, the best selector source is the failed message or a controlled test message from the same sending platform. Use the s= value from the DKIM-Signature header.
Check whether the DNS key exists and matches the provider setup
Google's DKIM setup guide describes the two required halves: generating a DKIM key pair, publishing the public key in DNS, and enabling DKIM signing in the mail system. Other ESPs follow the same broad model, even when they use CNAMEs or provider-specific selectors.
Common DNS-side causes include:
- The selector record is missing.
- The record was added under the wrong domain.
- The DNS host has not propagated the change.
- The key was copied with broken quotes, spaces, or truncation.
- The provider rotated selectors, but DNS still has the old key.
- A CNAME target for provider-managed DKIM is missing or broken.
If the DKIM record exists but Gmail still reports failure, inspect the message header. The message may be signed with a different selector or domain than the one you checked.
Check whether forwarding or modification broke the signature
DKIM signs selected headers and the body hash. If a gateway, mailing list, footer injector, security appliance, or forwarding service changes signed content after the sending platform signs it, DKIM can fail even when DNS is correct.
This is more likely when mail passes through outbound gateways that append footers, rewrite links, modify subject lines, or alter MIME structure. Google's DKIM setup guidance warns administrators to verify outbound gateways do not interfere with DKIM.
If DKIM passes for direct mail but fails through one route, compare the paths. The route that modifies the message after signing is the suspect.
Check DMARC alignment after DKIM passes
DKIM passing does not automatically mean DMARC passes. DMARC, defined in RFC 7489, requires the DKIM signing domain to align with the visible From domain unless SPF provides the aligned pass instead.
An ESP can sign with its own domain and produce a valid DKIM pass, but that may not satisfy DMARC for your From domain. For Gmail sender requirements, the safer setup is a provider configuration that signs with an aligned domain you control.
After fixing DKIM, inspect a real Gmail header for both dkim=pass and dmarc=pass.
How to fix Gmail 5.7.30
- Keep the full bounce text and sending platform name.
- Send a controlled test from the same stream if possible.
- Open the Gmail original message headers if a test is delivered.
- Copy the DKIM signing domain
d=and selectors=. - Check
<selector>._domainkey.<domain>in DNS. - Enable DKIM signing in the sending platform if it is disabled.
- Fix missing, stale, truncated, or wrong-domain DKIM records.
- Check whether gateways modify the message after signing.
- Confirm DMARC alignment after DKIM passes.
What this does not prove
Fixing Gmail 5.7.30 proves only that you addressed a DKIM authentication failure path. It does not prove SPF passes, DMARC aligns, Gmail reputation is healthy, or accepted mail will land in the inbox.
Relaymetry can check a DKIM record when given a domain and selector. It cannot reliably discover every possible DKIM selector for a domain, and it cannot prove a specific message was signed correctly unless you inspect that message's headers.