Why is Gmail deferring mail with '421 4.7.28 unusual rate of mail' and sending it to spam?
Published 24 Apr 2025
Updated 17 Oct 2026
14 min read
Summarize with
Updated on 17 Oct 2026: We clarified Gmail's deferral recovery steps and added checks for small mailing lists, forwarded mail and sender authentication.
Gmail is deferring mail with 421 4.7.28 because it sees an unusual rate of mail tied to your sending identity. That identity can be the sending IP, IP netblock, SPF domain, DKIM domain, URL domain, or repeated Message-ID. Deferral and spam placement are separate decisions, but the same reputation or traffic problems can affect both.
Treat this error as a sending-pattern warning. Slow Gmail traffic, cut the audience to people who recently engaged, check authentication and reputation signals, then rebuild volume in controlled steps. Retrying the same queue at the same speed usually makes the pattern look worse.
- Meaning: Gmail has temporarily rate limited mail because the current pattern looks unusual or unwanted.
- Main causes: Sudden volume jumps, infrequent sending, platform moves, bad retries, unauthorized traffic, repeated Message-IDs, or weak sender reputation.
- Immediate fix: Pause broad Gmail sends, segment recent engagers, pace retries, and inspect the exact sender scope.
- Spam link: Deferrals and spam placement can share underlying causes; a 421 response does not mean the deferred message was delivered to spam.
What Gmail 421 4.7.28 means
Google's Gmail SMTP errors list shows several 421 4.7.28 variants. They point to a temporary Gmail rate limit, but the response text identifies whether Gmail associated the pattern with a sender, IP address, IP netblock, SPF domain, DKIM domain, URL domain, or repeated Message-ID.
Illustrative Gmail 421 4.7.28 diagnostic summary
SMTP response: 421 4.7.28 unusual rate of email Affected scope: DKIM domain example.com Meaning: temporary Gmail rate limit
The wording matters. If the response names an IP address, start with IP reputation, reverse DNS, queue pacing, and other senders using that IP. If it names a DKIM domain or SPF domain, check whether a new stream or envelope domain changed the sender history. A new DKIM selector alone does not change the signing domain. Naming one of those domains identifies the rate-limit scope, not proof that its authentication check failed. If it names a URL domain, inspect the linked domain and the traffic carrying it.
Gmail also uses 421 4.7.28 when a sender exceeds the quota for messages carrying the same Message-ID. Check duplicate submissions and mailing-list expansion. Distinct newly generated messages need unique Message-ID values; an SMTP retry of the same queued message should retain its original Message-ID.
|
|
|
|---|---|---|
Unusual rate | Sender | Recent volume changes |
IP address | Sending IP | Queue pacing and shared-IP traffic |
IP netblock | Sending network | Other traffic in the netblock |
SPF domain | Envelope sender domain | Envelope identity and associated volume |
DKIM domain | DKIM signing domain | Signing identity and associated volume |
URL domain | Domain in message links | Shared tracking domains and linked traffic |
Same Message-ID | Message distribution | Duplicate submissions, loops and list expansion |
Common 421 4.7.28 scopes and the first check for each.
Do not treat this as ordinary greylisting
A temporary SMTP failure asks your mail server to try again later. 421 4.7.28 is more specific. Gmail is telling you that the sending rate or pattern is the issue. Retrying without changing volume, connections, audience, or the named scope keeps the same signal alive.
How deferrals relate to spam placement
Deferrals and spam placement can occur together or at different times. Gmail does not document a fixed sequence in which 421 4.7.28 automatically becomes spam placement, or a one-week timer. Continuing unwanted traffic can sustain the reputation problem behind both symptoms.
An infrequent sender can hit this because Gmail has little recent sending history for the identity and audience. If you email a large customer list after months of silence, complaints or unexpected volume can create problems. Use recent clicks, purchases, replies, or account activity to choose a recovery audience. Google says it does not track open rates, so tracking-pixel opens are not proof of a Gmail filtering signal. Google's sender guidelines explain the limits of open-rate data.
Gmail 421 4.7.28 troubleshooting flowchart showing unusual volume, deferrals and spam placement.
What Gmail is warning about
- Rate: Gmail sees more mail than it trusts for the current sender identity.
- Audience: The list includes recipients who did not expect the mail or have stopped responding.
- Identity: The domain, IP, signing domain, or link domain has changed or has weak history.
- Feedback: Recipient spam complaints can damage sender reputation.
What senders often do wrong
- Retry: They replay every deferred Gmail message as soon as the queue opens.
- Ignore: They keep sending to unengaged recipients because the campaign calendar says so.
- Move: They switch infrastructure and send full volume before Gmail has new history.
- Guess: They change DNS records without checking the exact failing sender scope.
A deferred message has not been accepted for delivery on that attempt. A message accepted later can still land in spam. SMTP acceptance therefore does not prove inbox placement. For a deeper look at the placement side, the page on Gmail spam placement covers the filtering signals in more detail.
Triage before you retry
The first job is to stop creating the same signal. Review Gmail separately from the rest of the list because Gmail can be healthy or unhealthy on its own. Aggregate delivery and engagement rates hide the problem when non-Gmail domains are still accepting and placing mail normally.
- Freeze: Stop broad Gmail campaigns and pause automatic retries that create large bursts.
- Scope: Save the full SMTP response, timestamps and queue IDs, then group deferrals by IP, envelope domain, DKIM domain, link domain, Message-ID, and mail stream.
- Segment: Send only to consenting Gmail recipients with recent clicks, purchases, replies, or account activity. Use opens as a supporting signal.
- Inspect: Run a real seed or mailbox sample through the email tester and review headers, authentication, and content clues.
- Check: Use a domain health check to review domain authentication, then verify the actual sending IP and its forward-confirmed reverse DNS with your mail host.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Suped's DMARC reporting and email authentication platform helps identify sending sources and authentication changes during triage. Review SPF and DKIM results by source, investigate unexpected traffic, and use issue-level remediation steps to correct configuration problems. DMARC reports do not show Gmail queue deferrals or prove inbox placement; keep SMTP logs and recipient evidence beside them.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The metrics to check first
Start with Gmail-only deferred count and percentage, queue age, recipient-confirmed placement, complaint signals, and authentication results by stream. Keep Gmail-reported spam rates below 0.1% and avoid 0.3% or higher. Google's sender guidelines specify these complaint-rate targets. Sparse or missing data is not proof of healthy delivery.
Follow Gmail's restart sequence
Google's sender guidelines give a specific connection recovery procedure for 421 4.7.28. Use it after stopping broad sends and identifying the affected scope. A successful SMTP connection is a reason to increase cautiously, not permission to release the full deferred queue.
- Stop for at least 10 minutes: Prevent campaign sends and automated retries from feeding the same Gmail rate limit.
- Identify the cause: Check the named Gmail scope, recent volume changes, shared-IP traffic, unauthorized jobs, compromised credentials, and repeated Message-ID values.
- Test one connection: After the pause, send through a single SMTP connection. If it fails, wait another 10 minutes before testing again.
- Increase one at a time: If the test succeeds, add connections individually while watching the Gmail-only 4.7.28 rate.
- Stop on recurrence: If deferrals rise again, reduce connections and volume instead of pushing the queue through.
If the response does not specify an IP, SPF domain, or DKIM domain quota, Google's guidance says to assume all three scopes are affected. Keep each scope stable while testing so the result tells you whether the restart is working.
Check whether the traffic is yours
An unusual rate can expose a compromised account, leaked SMTP credential, faulty automation, or another tenant on a shared IP. Compare the queue with expected applications and authenticated users before treating the event as a campaign pacing problem. Revoke exposed credentials and stop the unexpected source before restarting.
Check small mailing lists and forwarded mail
A small distribution list can encounter the same-Message-ID variant too. A single message delivered to several recipients normally shares one Message-ID; that alone is not a generation error. When direct delivery works but list delivery fails, compare the two routes before treating the problem as a large-campaign issue.
- Compare paths: Send a controlled test directly and through the list. Compare the sending IP, envelope sender, DKIM results and full Gmail response.
- Trace duplicates: Check overlapping list membership, aliases, forwarding loops and application jobs that submit the same message repeatedly.
- Preserve identity: Generate unique Message-IDs for distinct messages. Keep the original ID on retries and ordinary redistribution of the same message; rotating IDs to bypass a quota risks duplicate delivery and can break a DKIM signature.
- Check forwarding authentication: SRS (Sender Rewriting Scheme) changes the envelope sender for SPF, but does not by itself make that domain match the original visible From domain for DMARC. Preserve the original DKIM signature and review ARC (Authenticated Received Chain) handling where supported.
Google's sender guidelines include guidance for forwarding services and mailing lists. Check the relevant authentication headers and list identification. ARC carries earlier authentication results, but Gmail still evaluates the forwarded message. Pace the affected route while fixing duplicate delivery or authentication problems.
Fix the sending pattern
The fastest recovery usually comes from changing who gets mail and how fast Gmail receives it. Do not start by editing every DNS record. If authentication is broken, fix it. If authentication is passing, the bigger issue is usually volume, audience quality, recent history, content, or an unexpected source.
|
|
|
|
|---|---|---|---|
Pause | All Gmail | Stop | Stabilize |
Restart | Recent active | Low | Feedback |
Expand | Warm cohorts | Moderate | Trust |
Hold | Cold Gmail | None | Protect |
A conservative recovery plan for Gmail traffic.
For infrequent senders, the answer is pacing. If the list has not heard from you in months, send over several days and start with recipients who have a recent relationship with the brand or service. Gmail needs current positive feedback. A large one-day blast to quiet Gmail contacts creates the opposite signal.
Gmail restart guardrails
Operational guardrails for recovery. These are not published Gmail thresholds.
Stable
Continue
Small sends to recent active users
Watch
Hold pace
Deferrals appear but fall quickly
High risk
Reduce
Deferrals rise across streams
Stop
Pause bulk
Widespread spam placement is confirmed
Retry settings matter. If your MTA retries thousands of Gmail messages at the same time, Gmail sees another burst. Use progressive retry backoff and spread retry times so messages do not all return at once. Retain deferred mail in the queue until it is accepted or expires under your normal queue policy. Separate marketing, transactional, lifecycle, and account-security mail where possible; shared IP or domain reputation can still affect several streams.
A better first recovery send
- Audience: Consenting Gmail recipients active in a recent period, such as the last 30 days, with hard bounces, complaints and unsubscribe suppressions excluded. This window is an example, not a Google requirement.
- Cadence: Small batches with enough time between sends to read deferral and placement movement.
- Content: Plain value, expected sender identity, familiar link domain, and a working unsubscribe path.
- Stop rule: If deferrals rise again, pause the next batch instead of trying to push through.
Fix authentication and reputation signals
Authentication alone does not guarantee inbox placement, but broken authentication makes recovery much harder. Check SPF for the envelope domain and DKIM for the signing domain. DMARC needs at least one passing method whose domain matches the visible From domain under the published policy. Check each stream; a passing signature from an unrelated domain is not enough.
Check Gmail's sender requirements
All senders to personal Gmail accounts need SPF or DKIM, TLS, and valid forward and reverse DNS. Bulk senders, roughly 5,000 messages in 24 hours across the same primary domain and its subdomains, need both SPF and DKIM plus DMARC; p=none is sufficient for this requirement. Marketing and subscribed bulk mail also need one-click unsubscribe headers and a visible unsubscribe link in the body. A body link alone is insufficient. Google's sender guidelines explain the requirements.
Example monitoring-first DMARC recorddns
_dmarc.example.com TXT v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the example domain and reporting address with your own configured values. Omitting adkim and aspf uses the relaxed defaults, which allow qualifying subdomains within the same organizational domain. Do not weaken an existing quarantine or reject policy to troubleshoot 421 4.7.28; changing DMARC enforcement is not a Gmail rate-limit reset.
If you do not already review aggregate reports, DMARC monitoring helps identify sending sources and their authentication results. Suped's product groups this evidence so teams can check a newly added sender or a changed DKIM domain before adjusting DNS. Aggregate reports do not reveal the exact cause of a Gmail rate limit.
Reputation checks belong beside authentication checks. A listing on a major blocklist (blacklist) can expose abuse, compromise, or poor list practices that also need investigation, but it does not prove why Gmail issued the deferral. Blocklist monitoring helps catch those changes while you are still in the deferral stage. A clean result does not rule out a Gmail-specific reputation problem.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For senders hitting the error after a platform move, compare old and new identifiers. Did the DKIM domain change? Did the envelope domain change? Did a new link tracking domain appear? Did the IP pool change? Gmail does not judge only the visible From address. It evaluates the full message and traffic pattern.
The broader page on Gmail rate limits is useful when you need to separate sender reputation, bulk sender requirements, and volume pacing.
What to do if mail already lands in spam
If Gmail has already moved the stream to spam, keep the recovery narrower than feels comfortable. Send wanted mail to people with a recent relationship with the sender. Avoid sending apology blasts to the entire list.
- Clean: Suppress hard bounces, recent complainers and unsubscribed addresses. Keep existing suppressions in place and exclude inactive Gmail contacts from recovery campaigns.
- Separate: Keep essential transactional mail away from broad campaigns in routing, headers, and domains, while recognizing that shared reputation still connects the streams.
- Simplify: Reduce link count, remove surprise domains, and make the sender identity obvious.
- Measure: Track Gmail deferrals, recipient-confirmed placement, clicks, complaints, and unsubscribes. Treat opens as supporting evidence, not proof of inbox delivery.
Do not increase volume to compensate for lower opens. Low open rates alone do not prove spam placement; confirm the problem through recipient reports or mailbox samples. Once placement problems are confirmed, sending more to the same weak audience increases risk.
The mistake that extends recovery
A damaging response is to release the full deferred queue, send the delayed campaign again, and keep the next scheduled campaign unchanged. That creates another burst and risks duplicate mail. Recovery starts when the sending pattern changes.
Views from the trenches
Best practices
Reduce Gmail volume first, then restore it only after temporary deferrals drop for several sends.
Segment recent clickers and buyers separately before sending to quiet or older Gmail contacts.
Keep each retry queue paced so one warning does not become repeated bursts at Gmail hosts.
Common pitfalls
Replaying the full queue immediately teaches Gmail that the same pattern remains active today.
Treating 421 4.7.28 as a server outage delays investigation of the actual affected sender scope.
Switching platforms without a gradual restart can trigger deferrals even for expected customer mail.
Expert tips
Compare Gmail-only clicks, complaints, queue age and deferrals before changing DNS records.
Move low-engagement Gmail cohorts to a slower cadence until user feedback improves again.
Compare authentication reports with SMTP logs to check whether the sending identity changed.
Marketer view
Marketer from Email Geeks says senders who focus on engaged subscribers and handle deferrals early usually avoid the later spam-folder slide.
2025-04-24 - Email Geeks
Marketer view
Marketer from Email Geeks says 421 4.7.28 is not new, but it becomes more visible when senders ignore Gmail engagement signals.
2025-04-24 - Email Geeks
Keep Gmail recovery measurable
Track recovery with Gmail SMTP logs and confirmed placement. Suped's DMARC reports help check that legitimate sending sources continue to authenticate while you adjust the audience and pace. Neither a clean authentication report nor a cleared queue guarantees inbox placement.
