Gmail DKIM domain rate limiting errors are caused by Gmail seeing an unusual rate of unwanted or complained-about mail connected to the DKIM signing domain in the message. It is a reputation and traffic-quality deferral, not proof that the DKIM DNS record is broken. SPF is related because Gmail can apply the same reputation logic to the envelope sender domain used for SPF. When the same bad stream authenticates with SPF and DKIM, the SPF identity often points to the sender causing the DKIM-domain limit.
The direct fix is to isolate the sending source, pause or throttle the source creating the Gmail deferrals, then verify that SPF, DKIM, DMARC, reverse DNS, TLS, and unsubscribe handling meet Google's sender guidelines. I treat the error as a queue and reputation incident first, then I check DNS syntax after I know which authenticated identity is 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], should not send you chasing a nonexistent blank DKIM domain. I read that as a formatting or reporting defect unless the message headers prove that Gmail saw a malformed DKIM signature. The useful part is the SMTP status: 421 4.7.28 means temporary deferral, so retrying is expected, but blindly retrying the same stream keeps pressure on the same Gmail reputation bucket.
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 the visible From domain has a valid match through SPF or DKIM.
|
|
|
|---|---|---|
DKIM | d= | Signer |
SPF | MAIL FROM | Envelope |
DMARC | From | Domain match |
Reputation | 4.7.28 | Traffic quality |
The same Gmail deferral can name different authenticated identities.
Do not treat it as a DKIM syntax failure
A valid DKIM signature can still be rate limited. DNS syntax checks answer a different question: whether the public key, selector, and signature are readable. For that check, use a DKIM checker and confirm the selector resolves before changing keys.
- Status: A 421 response asks your mail server to try again later.
- Cause: The trigger is unwanted-mail rate, complaint rate, or related reputation data.
- Priority: Find the traffic source before rotating DKIM keys or editing stable DNS.
This is different from a hard unauthenticated-sender rejection. If the bounce is a 550 5.7.26 guide case, I shift to authentication failure handling. With 421 4.7.28, I assume Gmail accepted the connection far enough to make a reputation decision and then slowed the stream down.
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 matches one of them for DMARC.
What DKIM tells Gmail
- Signer: The d= value says which domain signed the message.
- Integrity: The signature proves selected headers and body content were not changed.
- Reputation: Gmail can associate traffic quality with that signing domain.
What SPF tells Gmail
- Sender: The envelope sender domain identifies the bounce path.
- Authorization: The SPF record says which IPs can send for that domain.
- Clue: A bad SPF-authenticated source often explains the 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.
Flowchart showing SPF and DKIM identities feeding into Gmail reputation scoring and a 421 deferral.
A second DKIM signature is not the first thing I blame. Many legitimate streams have more than one signature because an email service provider signs with its own domain and the customer domain signs too. I focus on the DKIM signature that passed, the From domain match used for DMARC, and the envelope sender that SPF authenticated.
How I investigate it
My first move is to group the deferrals by authenticated identity, not by recipient count alone. I want to know whether the same MAIL FROM, DKIM d= value, sending IP, campaign, or vendor account appears across the Gmail rejects. Then I run a domain health checker check so DNS and authentication basics do not distract from the incident.
- Confirm: Verify the bounce is 421 4.7.28 and not a permanent authentication rejection.
- Group: Bucket logs by DKIM signing domain, SPF envelope domain, IP, and source.
- Compare: Look for one sender that appears in both SPF-domain and DKIM-domain deferrals.
- Pause: Stop the suspect source, or throttle it sharply, before changing DNS.
- Retry: Let queued mail drain slowly after Gmail accepts new mail at normal rates.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
A real test message helps because it exposes the exact headers Gmail and other receivers will evaluate. I check Authentication-Results, DKIM-Signature, Return-Path, List-Unsubscribe, Message-ID, and the final From header. If the message has valid authentication but still lands in a rate-limit incident, the answer is not to keep editing the TXT records. The answer is to reduce the unwanted stream.
Signals that point to the SPF sender
- Sequence: SPF-domain deferrals appear first, then DKIM-domain deferrals follow.
- Scope: Only mail using one envelope sender or one integration is affected.
- Relief: Pausing that SPF-authenticated source stops new DKIM deferrals.
- Headers: The same visible From domain or signing domain appears across the affected mail.
What to fix first
I fix the traffic source before the DNS record because Gmail is complaining about the rate of unwanted mail, not merely about 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.
Complaint rate targets
Operational targets I use before Gmail starts slowing a stream.
Healthy
under 0.10%
Keep normal campaigns here.
Watch
0.10% to 0.30%
Reduce volume and inspect source quality.
High risk
over 0.30%
Google says keep reported spam rates below 0.30%.
Fix order I use
- Source: Pause the sender, campaign, automation, or integration tied to the deferrals.
- List: Remove stale, unconfirmed, bounced, and complaint-prone recipients.
- Headers: Confirm From, Reply-To, Message-ID, unsubscribe, and branding are clear.
- DNS: Verify SPF includes only approved senders and stays under lookup limits.
- Policy: Keep DMARC reporting active while you tighten enforcement in stages.
Starter DMARC record while investigatingdns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
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.
Where Suped fits
For most teams, Suped is the best overall fit for this workflow because it keeps DMARC, SPF, DKIM, hosted SPF, SPF flattening, hosted DMARC, hosted MTA-STS, real-time alerts, and blocklist (blacklist) monitoring in one operational view. That matters when a Gmail deferral crosses authentication, sender source, and reputation data.
The practical Suped workflow is straightforward: use DMARC monitoring to identify the source, confirm whether SPF and DKIM are passing for that source, inspect failures by provider, and send the fix steps to the team that controls the sender. The value is not another raw XML view. The value is knowing which source to pause and what DNS or sender setting to change.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
|
|
|
|---|---|---|
DKIM deferral | Issues | Pause source |
SPF source | Source table | Verify sender |
DNS drift | Diagnostics | Fix record |
Reputation risk | Alerts | Reduce volume |
Suped turns the Gmail error into an operational workflow.
This is especially useful for MSPs and larger teams because the person who sees the bounce is rarely the same person who owns DNS, marketing automation, or customer sending behavior. Suped's multi-tenant dashboard, client reporting, issue detection, and real-time alerts reduce the handoff time during a Gmail incident.
Views from the trenches
Best practices
Separate bulk streams by domain so one bad sender cannot pressure core Gmail delivery.
Treat 421 4.7.28 as a reputation deferral first, then confirm DNS syntax 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 DKIM keys during a rate limit can remove history without fixing complaints.
Expert tips
Compare deferrals by envelope sender, DKIM d value, IP, campaign, and sending vendor.
Keep DMARC reports active so source changes are visible before Gmail starts deferring.
Use a quarantine or reject policy only after every approved source is passing cleanly.
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 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
The practical answer
Gmail's DKIM-domain rate limit is caused by unwanted-mail reputation tied to an authenticated domain, not by SPF breaking DKIM. SPF is related because the same traffic source often has an SPF identity and a DKIM identity. When Gmail flags the SPF domain and then the DKIM domain, the shared sender is the part to isolate.
- Answer: The root cause is reputation pressure from a sender, campaign, list, or compromised source.
- SPF link: The SPF envelope sender can expose which source Gmail is grouping with the DKIM signer.
- Fix: Pause the bad source, reduce complaints, confirm authentication, and resume slowly.
I only change DKIM selectors after I have proof of a key, selector, or signing failure. In this specific Gmail error, the stronger first move is source isolation. Once the source is clean, the temporary deferrals usually clear as queues retry and Gmail sees better traffic.
