What causes Gmail delays due to unusual sending rates and suspicious content?
Updated on 8 Oct 2026: We clarified Gmail's rate-limit recovery steps and the difference between delivery delays and account restrictions.
Gmail delays with 421-4.7.28 indicate an unusual sending pattern associated with an IP address, authenticated domain, URL domain, or repeated Message-ID. A sudden volume jump, weak sender reputation, or unwanted mail can contribute to the rate limit. When the delay says DKIM domain, Gmail is pointing at the signing domain. When it says SPF domain, it is pointing at the envelope sender domain used for SPF. Neither wording alone proves that authentication failed.
A second delay that mentions suspicious content or links changes the diagnosis. Treat it as a reason to inspect the message body and URL paths, rather than assuming volume alone explains the delay. The response does not identify the exact element Gmail flagged. The same message can get deferred for more than one reason during retries.
- Rate signal: The volume or complaint pattern looks unusual for that sender identity.
- Reputation signal: The domain, IP, URL, or sender history gives Gmail less confidence in the mailstream.
- Content signal: The HTML, wording, images, links, or redirects look risky enough to delay or block.
- Shared asset signal: One sender's poor behavior can affect other senders that share a domain, IP pool, or link host.
Read the code literally first
Google's Gmail SMTP errors list includes separate 421-4.7.28 variants for IP address, IP netblock, DKIM domain, SPF domain, URL domain, and repeated Message-ID values. That wording matters because it tells you where to start looking.
What the Gmail codes mean
Both unusual-rate and suspicious-content responses can be temporary deferrals. 421 is a temporary SMTP response, so the sending server should retry. The 4.7.x class points at a policy or security decision. These errors do not identify an invalid recipient. Read the complete response to distinguish rate limiting, content concerns, and authentication failures.
Common Gmail delay responsestext
421 4.7.28 Gmail has detected an unusual rate of unsolicited email originating from your DKIM domain domain-name. 421 4.7.28 Gmail has detected an unusual rate of unsolicited email originating from your SPF domain domain-name. 421 4.7.28 Gmail has detected this sender exceeded the quota for sending messages that have the same Message-ID. 421 4.7.0 This message is suspicious due to the nature of the content or the links within.
The visible wording can differ across attempts or recipients because each SMTP transaction gives Gmail another chance to evaluate the message, sending IP, authenticated domain, URLs, recent rate pattern, and Message-ID use. A mailstream can fail a rate check first, then hit a content or URL check later, then return to a rate check on another attempt.
|
|
|
|---|---|---|
IP address | Sending IP | Volume and reputation by IP |
IP netblock | Shared network range | Other senders using that range |
DKIM domain | Signing identity | Volume by signer |
SPF domain | Envelope identity | Bounce domain |
URL domain | Link reputation | Redirect chain |
Same Message-ID | Message generation | Queue duplication |
Content or links | Message risk | HTML and URLs |
How to interpret the wording without over-reading it.
Confirm whether Gmail delayed or rejected the message
Check where the delay occurs before changing sending practices. A Gmail delivery deferral, a sending limit on your own account, and a sign-in restriction require different actions. A message in your Sent folder alone does not prove Gmail accepted it for the recipient.
|
|
|
|---|---|---|
421 4.7.28 or 421 4.7.0 | Temporary SMTP rejection, often reported as a deferral or soft bounce | Keep the original message queued and address the stated cause |
550 5.7.28 | Permanent rejection of this delivery attempt for unusual unsolicited traffic | Fix the cause before a new send; stop automatic retries of the rejected attempt |
Final 250 response after message data | Gmail accepted the message, but acceptance does not guarantee inbox placement | Check recipient folders and, where available, delivery logs or Received timestamps |
Daily sending limit or account lock notice | Restriction on sending through or accessing your Google account | Follow the account notice or administrator instructions instead of treating it as a recipient-side 4.7.28 error |
Use the SMTP result or account notice to choose the correct next step.
Google described additional checks before inbox delivery in its 2017 announcement about delayed delivery. That description does not establish a recovery window for SMTP 4.7.28 deferrals. Use the SMTP acceptance result to distinguish the two situations.
Why DKIM or SPF gets named
Google does not publish the exact internal rule that decides whether a delay names DKIM, SPF, IP, netblock, or URL domain. Use the named identity as the starting point for investigation. Its presence in a rate warning does not establish a broken DNS record or failed authentication.
When DKIM is named
- Signer focus: The DKIM d= domain is the visible authenticated identity.
- Shared signer: Several streams using one signing domain can share rate pressure.
- Replay risk: Inspect unexplained signed-message reuse or forwarding spikes when the observed traffic exceeds your sending logs; missing content warnings alone do not establish replay.
When SPF is named
- Envelope focus: The return-path or bounce domain is carrying the signal.
- ESP setup: A shared bounce domain can connect otherwise separate customers.
- Authentication drift: SPF can pass for a bounce domain that does not match the visible From domain for DMARC.
For an ESP, this distinction matters because customer traffic can share infrastructure in subtle ways. A customer can send through your platform while also sending elsewhere. Gmail sees the total behavior attached to the authenticated domain, not only the slice visible in your own logs.
Gmail delivery delay flowchart showing sender authentication, sending rate, link checks, and retries.
Common causes of Gmail rate limiting
Do not treat Gmail delay codes as a single-cause diagnosis. Start with the exact wording, then map it against recent sending changes and message evidence. Separate a volume issue from a content or shared-domain issue before choosing a fix.
- Volume change: A large campaign, seasonal spike, retry storm, or reactivated list can exceed Gmail's expected rate for the sender.
- Domain reputation: High complaints, stale recipients, repeated sends, and sudden list growth can make normal volume look riskier.
- Link reputation: A shared click domain, URL shortener, redirect chain, expired certificate, or risky landing page can trigger content or link delays.
- Shared assets: Free trials, low-trust customers, and high-risk senders sharing tracking domains can affect better senders on the same asset.
- Authentication gaps: SPF and DKIM can pass without the domain match needed for DMARC. Even a DMARC pass does not prevent rate limiting or content-based deferrals.
- Reputation listings: The Gmail error itself is not proof of a blocklist (blacklist) entry or a reason to request delisting. Listings are supporting evidence when delays appear across providers.
If the problem follows one customer across different campaigns, focus on that customer's list quality, content, URLs, and total sending footprint. If the problem follows many customers using the same shared asset, focus on the ESP-owned domain or IP pool. That split saves time.
Do not warm up blindly
Reducing volume helps when the main issue is rate. It does not fix suspicious links, shared tracking reputation, broken redirects, bad list sources, or weak customer separation. If Gmail says the content or links are suspicious, change the message evidence before scaling back up. Check misleading subjects and whether visible link text matches its destination; Google does not publish a fixed list of words that guarantees a message will pass its spam filters.
How to investigate without guessing
Work through Gmail delays in a fixed order so rate, reputation, content, and infrastructure do not get mixed together. The goal is to prove which identity Gmail is reacting to and whether the failing evidence sits in the SMTP path, authenticated domain, URL chain, or actual message.
- Collect errors: Group bounces and deferrals by exact SMTP text, customer, domain, IP, campaign, retry time, and SMTP stage. Separate temporary deferrals from permanent failures.
- Compare volume: Check Gmail recipient volume against the sender's normal hourly and daily pattern. Track the percentage of attempts deferred and queue age, not just the raw error count.
- Map identities: List the From domain, DKIM d= domain, return-path domain, tracking domain, and sending IP.
- Inspect content: Render the HTML, compare visible link text with its destination, follow every redirect, and confirm HTTPS. Remove suspicious shorteners or link hosts.
- Check transport and authentication: Confirm SPF and DKIM results, the From-domain match through at least one passing method for DMARC, forward and reverse DNS, TLS, and a unique Message-ID for each distinct message.
- Throttle safely: Use progressive retry backoff, reduce the Gmail rate, pause risky segments, and restart with the most engaged recipients first.
For a real sample, send the exact message through Suped's email tester alongside SMTP log review. It exposes authentication results, headers, and message structure. A successful test does not reproduce Gmail's filtering decision or prove the same message will avoid delays.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
After the message test, check the domain itself. Suped's domain health checker reviews DMARC, SPF, DKIM, DNS, and related setup. Use the findings to check the specific domain or sending identity named in the error.
If the message test reveals no setup issues, continue with segmentation. Compare affected and unaffected senders by tracking domain, return-path, DKIM signer, list source, Gmail volume, and customer tier. This comparison helps identify whether the issue follows one sender or a shared asset; a clean test does not rule out reputation or content concerns.
Evidence of shared-domain pressure
If multiple unrelated senders hit delays while using the same tracking domain, return-path domain, or DKIM signer, investigate that shared asset and compare senders with similar volume and consent practices. Customer-owned tracking domains reduce shared reputation exposure, but the correlation alone does not prove the domain caused the delays.
How to handle retries and recovery
A 421 response tells the sending server to retain the message in its normal queue and try again later. Repeated immediate connections add pressure, while launching replacement copies can increase volume and create duplicate delivery after queued mail succeeds.
- Honor the temporary failure: Keep the original message queued under the sending system's normal expiration policy. If that queue expires, the sender can issue a final non-delivery report; the original deferral does not prove the recipient address was invalid.
- Back off progressively: Increase the interval between retries instead of reconnecting at the same rapid rate, and reduce connection concurrency as well as message volume.
- Keep Message-ID values unique: Use a unique Message-ID for each distinct message, but retain the original Message-ID when retrying that same queued message. Do not regenerate IDs to bypass a quota response.
- Resume using evidence: Increase volume only after temporary failures fall, risky mail is removed, and complaint pressure is controlled.
For a 4.7.28 rate-limit response, Google's email sender guidelines recommend stopping sending for at least 10 minutes, then testing with one connection. If that connection fails, wait another 10 minutes; if it succeeds, increase connections one at a time. This is a controlled recovery step, not a promise that reputation or content problems clear in 10 minutes.
There is no fixed clearance window
Gmail does not publish a guaranteed 24-to-72-hour recovery time for 4.7.28. A temporary deferral often clears after the triggering behavior stabilizes, but repeated errors require further review of the cause and retry pressure. Use falling deferral rates, shorter queue age, and successful queued deliveries as recovery evidence.
What to change after finding the cause
The fix depends on the signal. A rate-only issue calls for measured throttling and a clean ramp. A content or link issue calls for changing the message and URL path first. A shared asset issue calls for separation instead of lower volume alone.
Immediate containment
- Throttle Gmail: Cut retry pressure and send smaller batches to engaged users.
- Pause risky mail: Stop cold lists, unverified imports, and high-complaint campaigns.
- Strip bad links: Remove suspicious shorteners, broken redirects, misleading link text, and low-trust landing pages.
- Separate assets: Contain abusive sending and separate customers by risk. Customer-owned domains do not make unwanted mail acceptable.
Permanent fixes
- Warm by identity: Ramp each domain and customer on its own pattern, not only by IP.
- Enforce consent: Block stale imports and require proof for high-volume customer segments.
- Meet Gmail requirements: At 5,000 or more daily messages to personal Gmail accounts, meet bulk sender requirements for authentication, DNS, TLS, message format, and one-click unsubscribe where required.
- Monitor drift: Alert on authentication failures, sender spikes, and blocklist or blacklist changes.
Google's Gmail SMTP guidance lists separate errors for failed SPF or DKIM, missing TLS, DNS problems, and a missing DMARC policy. Bulk senders need both SPF and DKIM, plus a DMARC record with at least p=none. For direct mail, at least one passing SPF or DKIM domain must match the visible From domain under DMARC rules; both do not have to match. Google recommends keeping its reported spam rate below 0.10% and avoiding 0.30% or higher.
Google counts mail from subdomains toward the same primary domain's bulk sender threshold, and bulk sender status remains after it is assigned, even if volume later falls. For bulk senders, marketing and subscribed messages need RFC 8058 one-click unsubscribe through List-Unsubscribe and List-Unsubscribe-Post headers, plus a visible body link. A body link alone does not meet the one-click requirement. Honor unsubscribe requests within 48 hours.
For more depth on rate recovery, the related guide on slow Gmail delivery covers a broader remediation path. If the problem started after a quiet period, the guide on a period of low sending is the closer match.
A practical recovery guide
Use temporary failures, complaints, and message evidence to decide when Gmail volume should return.
Stable
resume in small steps
Temporary failures falling and complaints controlled
Watch
hold the current rate
Some deferrals or uneven recipient response
Hold
reduce or pause
Content warnings or shared asset risk
Reset
pause at least 10 minutes, test one connection
Repeated Gmail delays across campaigns
Use Suped to investigate authentication changes
Suped's DMARC and email authentication platform helps investigate changes in sending sources and authenticated domains. Use DMARC monitoring to review SPF and DKIM results, domain matching, and unfamiliar sending sources. Use Suped's alerts and issue steps to investigate authentication changes alongside your SMTP logs.
Suped turns authentication reports into checks and fixes. When Gmail names a DKIM or SPF domain, review whether the expected sending sources authenticate correctly. DMARC aggregate reports do not show Gmail's SMTP deferral codes or content verdicts, and they arrive on the reporting receiver's schedule, so delivery logs remain the evidence for the delay itself.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The same platform also provides blocklist monitoring when a Gmail issue appears alongside wider reputation problems. A blocklist or blacklist hit does not automatically explain Gmail delays, but it is supporting evidence when domain or IP reputation has slipped.
Views from the trenches
Best practices
Group Gmail delays by exact wording before changing DNS, throttles, or customer routing.
Check customer-owned tracking and bounce domains before blaming only the sending IP.
Reduce Gmail rate while reviewing message content, redirect chains, and engagement signals.
Separate risky senders to limit the reputation exposure of shared authenticated domains.
Common pitfalls
Treating every 421 delay as warm-up failure misses link, content, and reputation issues.
Sharing one click domain across customer tiers can spread reputation damage quickly.
Looking only at your ESP logs misses the sender's traffic through other platforms.
Fixing SPF or DKIM syntax alone will not repair poor engagement or bad URL evidence.
Expert tips
Use DKIM, SPF, URL domain, and IP wording to choose the first branch of investigation.
When content warnings appear, inspect the actual mailstream before assuming replay abuse.
Restart volume with engaged Gmail recipients after removing risky links and stale lists.
Keep customer reputation boundaries clear through owned tracking, bounce, and signing domains.
Marketer view
Marketer from Email Geeks says unusual rate wording should be taken at face value first because Gmail is reacting to a pattern it considers abnormal.
2024-07-24 - Email Geeks
Marketer view
Marketer from Email Geeks says suspicious content and link wording points back to the actual message and URL path, not only the sender's warm-up plan.
2024-07-24 - Email Geeks
Does a DKIM or SPF rate warning mean broken DNS?
A DKIM or SPF rate warning does not by itself mean a DNS record is broken. In these Gmail delays, DKIM and SPF usually tell you which authenticated domain Gmail associated with the abnormal sending pattern. Identify that domain, compare its sending sources and volume, and review the message content before changing DNS.
