What causes Gmail DKIM domain rate limiting errors and how are they related to SPF?
Updated on 20 Oct 2026: We clarified subdomain authentication and DMARC alignment, and tightened the Gmail retry and source isolation steps.
Gmail DKIM domain rate limiting errors occur when Gmail sees an unusual rate of unsolicited mail tied to the DKIM signing domain in the message. The DKIM-domain version of 421 4.7.28 is a temporary traffic and reputation deferral, not proof that the DKIM DNS record is broken. Gmail also tracks volume, recipient feedback, sending history, and quotas per DKIM and SPF domain, with a separate quota for the sending IP. SPF is related because Gmail can apply the same rate-limit logic to the envelope sender domain used for SPF. When the same stream authenticates with SPF and DKIM, the SPF identity often points to the sender causing the DKIM-domain limit.
The direct fix is to stop sending to Gmail for at least 10 minutes, isolate the source creating the deferrals, then verify that SPF, DKIM, DMARC, reverse DNS, TLS, and unsubscribe handling meet Google's sender guidelines. Treat the error as a queue and reputation incident with a possible quota component. Check DNS syntax after identifying the authenticated identity and traffic source involved.
Gmail 421 4.7.28 DKIM-domain deferraltext
421-4.7.28 Gmail has detected an unusual rate of unsolicited mail 421-4.7.28 originating from your DKIM domain [example.com 15]. 421-4.7.28 Mail sent from your domain has been temporarily rate limited.
The odd version where the bracketed DKIM domain is blank, such as [ 15], does not identify a blank DKIM domain. Check the complete SMTP response in the mail server log and inspect the message's Authentication-Results and DKIM-Signature headers before concluding that the signature was malformed. The useful part is the SMTP status: 421 4.7.28 is a temporary deferral, but blindly retrying the same stream keeps pressure on the affected Gmail quota.
What the Gmail error means
Gmail names DKIM or SPF in this error because those authentication identities tell Gmail which domain is responsible for the message stream. DKIM points to the signing domain in the d= tag. SPF points to the envelope sender domain, and in some cases the HELO domain. DMARC then checks whether a passing SPF or DKIM identity meets the domain matching rule for the visible From domain.
|
|
|
|---|---|---|
DKIM domain deferral | DKIM-Signature d= | Which signing domain and sending source the response names |
SPF domain deferral | MAIL FROM | The actual envelope sender domain in the SMTP logs |
DMARC alignment | From: | Whether a passing SPF or DKIM identity meets the required domain match |
Other 421 4.7.28 variants | IP, netblock, URL domain, or repeated Message-ID | The specific scope named in the complete SMTP response |
Identify the limited identity separately from the DMARC domain matching check.
Do not treat it as a DKIM syntax failure
A valid DKIM signature can still be rate limited. A DNS lookup checks public key publication; it does not verify a message signature. Use Suped's DKIM checker to confirm the selector resolves, then check the DKIM result on a delivered test message before changing keys.
- A 421 response asks your mail server to try again later.
- The DKIM-domain wording points to unusual unsolicited-mail volume or related reputation and quota data.
- Find the traffic source before rotating DKIM keys or editing stable DNS.
Compare the complete response with Google's SMTP error reference before changing authentication. 421 4.7.27 explicitly says SPF did not pass, and 421 4.7.30 explicitly says DKIM did not pass. Those codes require authentication repair. Gmail uses 421 4.7.32 for a From-domain alignment failure, which is a separate diagnosis. A 550 5.7.26 guide covers a permanent unauthenticated-sender rejection. By contrast, the DKIM-domain form of 421 4.7.28 names the signing domain being limited; it does not establish that every authentication check passed.
How SPF is connected
SPF does not validate DKIM. The two checks are separate. The connection is that both checks create authenticated domain identities that Gmail can use when it scores a stream. A sender can have SPF passing for one envelope domain, DKIM passing for another signing domain, and a visible From domain that meets DMARC alignment through one of them.
What DKIM tells Gmail
- The d= value says which domain signed the message.
- A passing signature verifies the signed message content under the signer's canonicalization rules.
- Gmail can associate traffic quality with that signing domain.
What SPF tells Gmail
- The envelope sender domain identifies the bounce path.
- The SPF record says which IPs can send for that domain.
- A poor SPF-authenticated source can explain a related DKIM deferral.
This is why an SPF-domain warning can appear before a DKIM-domain warning for the same incident. If a campaign, platform account, or compromised integration sends unwanted mail with both SPF and DKIM passing, Gmail has more than one domain identity tied to the same behavior. Pausing the SPF-authenticated sender can stop the DKIM-domain deferrals because the underlying traffic source has stopped.
SPF envelope sender and DKIM signing domains connected to Gmail reputation checks and a 421 4.7.28 deferral.
A second DKIM signature is not an automatic fault. Many legitimate streams have more than one signature because an email service provider signs with its own domain and the customer domain signs too. Focus on which signature passed, which passing authenticated domain meets the DMARC alignment rule for the From domain, and which envelope sender SPF authenticated.
A shared sending IP has a quota shared by its senders, even when their DKIM and SPF domains differ. Separating streams by subdomain does not guarantee isolation from Gmail throttling. Correlate the sending IP with the named domain using Google's sender guidelines.
Check subdomain authentication and DMARC alignment
A subdomain can pass SPF and DKIM but fail DMARC alignment. Check the identities in the actual message before publishing records at every subdomain or changing the From address.
Example identities, with an abbreviated DKIM signaturetext
MAIL FROM:<bounce@bounce.example.com> From: News <news@news.example.com> DKIM-Signature: v=1; ...; d=example.com; s=mail2026; ...
- SPF checks the sending IP against the record at bounce.example.com, the MAIL FROM domain. The address local part and visible From domain do not determine this lookup, and a parent SPF record is not inherited automatically. See the SPF lookup rules.
- DKIM looks up mail2026._domainkey.example.com using the signature's s= and d= values, even though From uses a subdomain. Reusing a selector name under different signing domains does not itself cause a collision because the DNS names differ. See the DKIM key lookup rules.
Assuming example.com is the organizational domain and both checks pass, these identities meet relaxed DMARC alignment. With strict aspf=s and adkim=s, neither identity matches news.example.com exactly. DMARC needs one passing method with the required domain match, as specified in RFC 9989. Passing DMARC does not exempt traffic from Gmail rate limiting.
How forwarding changes the diagnosis
Forwarding creates a different SPF pattern. A simple forward sends the message through a new IP that the original envelope sender's SPF record does not authorize, so SPF often fails even though the original sender configured SPF correctly. Do not add a forwarding service's IP addresses to the original sender's SPF record unless that service is authorized to originate mail for the domain.
- Sender Rewriting Scheme (SRS) changes the envelope sender so SPF can pass for the forwarder's domain, but that domain usually does not meet DMARC alignment with the original visible From domain.
- An intact signature can survive forwarding and preserve DMARC through DKIM with the required domain match. Changes to signed headers or the body can break it.
- Authenticated Received Chain (ARC) lets a forwarder preserve prior authentication results, but the receiving system decides how much trust to give that chain.
- A 4.7.28 response on forwarded traffic can point to the forwarder's shared domain or IP quota, not the original sender's DNS configuration.
Trace the Received, Return-Path, Authentication-Results, and ARC headers to determine whether Gmail evaluated the original sender, the forwarder, or both. If only forwarded copies fail, investigate the forwarding path before editing the original domain's SPF record or rotating its DKIM key.
How to troubleshoot Gmail 421 4.7.28
Start by grouping deferrals by authenticated identity, not by recipient count alone. Check whether the same MAIL FROM, DKIM d= value, sending IP, campaign, or sending account appears across the Gmail responses. Then use Suped's domain health checker to identify any separate DNS or authentication fault.
- Verify the response is 421 4.7.28 and save the complete SMTP text that identifies the affected DKIM domain, SPF domain, or IP. If no quota is named, investigate DKIM, SPF, and IP limits together.
- Bucket logs by DKIM signing domain, SPF envelope domain, IP, and source.
- Look for one sender that appears in both SPF-domain and DKIM-domain deferrals.
- Stop sending to Gmail for at least 10 minutes and disable the suspect campaign or integration.
- After 10 minutes, retry through one connection. If it fails, wait another 10 minutes. If it succeeds, add connections one at a time while monitoring responses.
Keep deferred messages queued and let the sending server retry them with backoff, consistent with SMTP retry guidance. Do not resubmit a deferred campaign as new mail. The 10-minute pause is a recovery starting point, not a guaranteed reset; monitor queue age and expiry so persistent deferrals do not become final delivery failures.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A delivered test message exposes receiver-generated Authentication-Results and the DKIM-Signature, Return-Path, List-Unsubscribe, List-Unsubscribe-Post, Message-ID, and From headers. A deferred SMTP transaction does not provide Gmail's received-message headers, so use sender logs for the actual MAIL FROM and a delivered copy from the same stream for authentication results. If authentication passes but the stream is rate limited, reduce that stream.
Signals that point to the SPF sender
- SPF-domain deferrals appear first, then DKIM-domain deferrals follow.
- Only mail using one envelope sender or one integration is affected.
- Pausing that SPF-authenticated source stops new DKIM deferrals.
- The same visible From domain or signing domain appears across the affected mail.
What to fix first
Fix the traffic source before the DNS record because the DKIM-domain form of 4.7.28 reports unusual unsolicited-mail volume, not missing authentication. DNS still matters, especially for bulk senders, but a clean SPF record does not rescue a list with high complaints, stale recipients, misleading headers, or a shared IP with poor reputation.
For personal Gmail delivery, all senders need SPF or DKIM. Bulk senders need both, plus DMARC with at least p=none. Their marketing and subscribed messages also need one-click unsubscribe and a visible body link. Google counts roughly 5,000 messages within 24 hours under the same primary domain, including subdomains, when classifying bulk senders. That classification persists after volume drops. These are sender requirements, not a promise that Gmail will accept a given sending rate.
Gmail spam rate guidance
Google's user-reported spam rate guidance. The warning band is an operational action range, not a published Gmail rate-limit cutoff.
Target
under 0.10%
Keep the Gmail-reported user spam rate below this level.
Investigate
0.10% to under 0.30%
Inspect recipient quality and reduce unwanted mail. This is not an automatic throttling threshold.
Avoid
0.30% or higher
Google says to avoid ever reaching this level.
Fix order
- Pause the sender, campaign, automation, or integration tied to the deferrals.
- Remove stale, unconfirmed, bounced, and complaint-prone recipients.
- Confirm From, Reply-To, Message-ID, unsubscribe, and branding are clear.
- Verify SPF includes only approved senders and uses no more than 10 terms that trigger DNS lookups during evaluation, including nested include mechanisms.
- Keep DMARC reporting active while tightening enforcement in stages.
Example DMARC monitoring record for a new setupdns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Use this monitoring example only for a domain without an existing DMARC policy. Keep an established p=quarantine or p=reject policy; lowering enforcement to p=none does not clear Gmail throttling. Replace the example reporting address with a monitored destination.
If the SPF sender is unauthorized, remove it from the SPF record and block the account or API key that generated the mail. If the sender is authorized but the mail is unwanted, keep the SPF record intact and fix the audience, cadence, or content. SPF tells Gmail who was allowed to send, not whether the message was wanted.
Use Suped to investigate authentication results
Suped is our DMARC reporting and email authentication platform. For this workflow, it puts source-level DMARC results, authentication diagnostics, alerts, and blocklist (blacklist) monitoring in one operational view. Correlate those results with the Gmail deferrals in your sending server logs.
Use Suped's DMARC monitoring to identify reported sources, check their SPF and DKIM results, and route authentication fixes to the team that controls the sender. DMARC aggregate reports are not Gmail SMTP deferral logs and do not show every queued attempt; use sender logs to confirm which stream Gmail is limiting.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
|
|
|
|---|---|---|
Gmail DKIM-domain deferral | SMTP logs plus Suped source results | Identify the affected stream before pausing it |
Unrecognized SPF source | Suped source table and sender inventory | Confirm authorization and disable unauthorized access |
DNS configuration issue | Suped authentication diagnostics | Repair the specific record or signing setup |
Continued 421 4.7.28 responses | Sender retry logs and queue age | Keep volume low and escalate with complete SMTP evidence |
Combine Suped authentication findings with sender logs during a Gmail incident.
For MSPs and larger teams, Suped's multi-tenant view and client reporting help route authentication findings to the account owner. Give that owner the complete SMTP response and affected sending source so the DNS and sending-system teams can coordinate the fix.
Views from the trenches
Best practices
Separate bulk and transactional streams, then monitor shared IPs for Gmail quota pressure.
Treat 421 4.7.28 as a traffic or reputation deferral, then verify authentication separately.
Pause the suspect SPF-authenticated source before changing stable DKIM selectors in DNS.
Common pitfalls
Chasing an empty bracket value as a real DKIM domain wastes time in Gmail incident logs.
Assuming SPF and DKIM are unrelated hides shared sender reputation problems on mixed traffic.
Rotating a DKIM selector keeps the same d= domain and does not fix unwanted sending patterns.
Expert tips
Compare deferrals by envelope sender, DKIM d= domain, sending IP, campaign, and source account.
Compare DMARC source reports with SMTP logs; reports do not show every deferred attempt.
Enforce DMARC only after approved sources pass with the required SPF or DKIM domain matching.
Marketer view
Marketer from Email Geeks says the empty DKIM domain brackets look like a Gmail formatting defect, not proof that a blank domain is being rated.
2023-11-23 - Email Geeks
Marketer view
Marketer from Email Geeks says the first incidents looked mild and affected a narrow sender set, which made a source-level reputation issue more likely.
2023-11-23 - Email Geeks
Frequently asked questions
No. The DKIM-domain form of 421 4.7.28 means Gmail is temporarily limiting mail associated with that signing domain. It does not prove DKIM is broken or that every authentication check passed. Investigate the affected traffic and verify authentication separately.
A 4.7.28 response reports unusual traffic or a quota condition. A 4.7.30 response explicitly says DKIM authentication did not pass, so it requires a DKIM configuration or signing fix.
The same message stream can authenticate through both SPF and DKIM. Gmail can name either identity when it rate limits traffic connected to that stream.
Key rotation does not clear a domain rate limit: changing s= leaves the d= signing domain unchanged. Repair a key, selector, or signing fault when one is found, and rotate keys for routine security or a compromised key. For 421 4.7.28, isolate the source and reduce unwanted mail first.
Yes. If that sender is the source Gmail is scoring, pausing or blocking it can stop new DKIM-domain deferrals because the affected stream has ended.
The empty field does not prove that Gmail evaluated a blank domain. Check the complete SMTP response and the affected message headers to identify the signing domain and authentication result.
