Gmail 421 4.7.0 and 4.7.28 Deferrals: What They Mean and How to Fix

Your queue starts backing up, delivery slows to a crawl, and your logs fill with lines like this:

421 4.7.0 Try again later, closing connection.

Or this one, which senders find more alarming:

421 4.7.28 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been temporarily rate limited.

Here is the single most important thing to understand: a 4xx response from Gmail is not a block. It is a throttle, and it is Google telling you something is wrong before it becomes a block. Across Gmail’s published error table the pattern is consistent: 4.7.x strings say “has been rate limited,” 5.7.x strings say “was blocked.” Google does not state this as a categorical rule, but every documented pair follows it. You are still in the recoverable stage — but knowing when a 4.7.x becomes a 5.7.x is what keeps you there.

Ultimately, what determines whether you stay there is how you respond in the next few hours. Most senders respond by retrying harder, which is precisely the behavior that converts a temporary throttle into a durable reputation problem.

What a Gmail Deferral Actually Is

4xx means temporarily rejected: the message was not delivered, but the receiver is inviting you to try again later. When Gmail issues a 421 it closes the entire connection, not just that recipient’s delivery attempt — every message queued in that SMTP session is affected. In other words, that is what distinguishes 421 from a per-recipient soft bounce like 452. One is a statement about your connection and your IP; the other is about a single mailbox.

Still, the rate limit is not arbitrary load-shedding. It is a reputation-driven decision about how much mail from your IP or domain Gmail is currently willing to absorb, and it tightens as complaint signals rise.

This is why retry behavior matters so much. If you back off, Gmail sees a sender responding correctly to a signal, and the limit relaxes as your metrics recover. If you hammer through the deferral with immediate retries and high concurrency, Gmail sees a sender ignoring a rate limit — behavior statistically characteristic of compromised hosts and spam operations. The throttle tightens, and eventually the 4.7.x responses become 5.7.x responses. You did that, not Gmail.

How to Confirm This Is Your Problem

First, grep your MTA logs for the destination and the response class. You are looking for:

• Responses from gmail-smtp-in.l.google.com or any aspmx.l.google.com host
• Any 421 or 452 status, especially 4.7.0 and 4.7.28
• Deferral counts that are rising day over day rather than spiking once
• Queue age growing on Gmail-bound mail specifically, while other destinations deliver normally

The diagnostic that matters most: is this Gmail-specific? If Microsoft, Yahoo, and your corporate destinations are fine and only Gmail defers, you have a Gmail reputation or rate problem. If everything defers, look at your own infrastructure — DNS, PTR records, TLS, or an IP-level blocklisting — before assuming Gmail singled you out. Then check whether deferrals correlate with a specific campaign, segment, or sending IP. That correlation is usually the root cause.

Gmail 4xx and 5xx Codes, Decoded

In fact, these strings mean genuinely different things. Treating them as one category — “Gmail is bouncing us” — is how senders apply the wrong fix.

The 5 Most Common Reasons Gmail Throttles Senders

1. Complaints from unengaged recipients

The dominant cause, and the one behind every 4.7.28. Mailing people who forgot they subscribed produces spam reports, and spam rate is the metric Gmail now weights most heavily. Old segments reactivated for a big send are the classic trigger.

2. Volume spikes

An IP that normally sends 20,000 a day suddenly pushing 200,000 looks like a compromised host. As a result, Gmail throttles volume anomalies quickly, independent of whether the mail is wanted.

3. Excessive connection concurrency

Opening dozens of simultaneous connections to Gmail’s MX hosts triggers rate limiting on its own. Plenty of senders with clean lists hit 421s purely because their MTA is configured too aggressively.

4. Authentication gaps

Missing SPF, broken DKIM signing, or DMARC misalignment produce their own distinct 421s (4.7.27, 4.7.30, 4.7.32, 4.7.40). From November 2025 Google’s FAQ states Gmail “is ramping up its enforcement on non-compliant traffic,” with “disruptions, including temporary and permanent rejections” — expect these to harden into their 5.7.x equivalents, though Google published no per-code cutover.

5. Retrying through the deferral

The self-inflicted one. A queue that retries every 60 seconds against an active throttle generates exactly the pattern Gmail rate-limits for, keeping you throttled long after the original cause is gone.

How to Fix It: In the Right Order

Order matters more here than in almost any other deliverability incident, because the wrong first move — retrying harder — actively worsens the underlying signal.

Step 1: Read the exact string

First, pull the full response text, not just the numeric code. An authentication 421 and a rate-limit 421 share the same enhanced status code and need completely different fixes.

Step 2: Slow down before anything else

Reduce your Gmail-bound send rate and concurrency immediately, and pause the campaign that triggered it. This costs a few hours of delivery and protects weeks of reputation. Every retry through an active throttle is a data point arguing you should be blocked rather than deferred.

Step 3: Check Postmaster Tools

Now — not first — look at what Google is reporting about you. Details below.

Step 4: Fix the actual cause

When the string mentioned authentication, fix SPF, DKIM, and DMARC. For an unsolicited warning, clean your list instead: suppress unengaged recipients, remove purchased or scraped data, and verify recent imports. If neither applies, you have a pacing problem — and Step 2 is your fix.

Step 5: Ramp back gradually

Of course, deferrals stopping means Gmail accepts your reduced rate — not that you can return to full volume. Re-ramp using the schedule below.

Backoff and Re-Ramp Schedule

Google does not publish retry intervals or concurrency numbers — those are operational choices, not policy. The schedule below is a conservative starting point, and backoff schedules differ by receiver. Note RFC 5321 §4.5.4.1: “the give-up time generally needs to be at least 4-5 days.” Bouncing Gmail-bound mail at 24 hours discards mail Gmail fully intends to accept once the throttle relaxes. Tune it to your volume, but keep the shape: long waits, low concurrency, gradual recovery.

Two rules that matter more than the exact numbers. Add jitter — a small random offset on every retry interval — so a queue full of deferred messages does not synchronize into a retry storm that looks exactly like the burst that got you throttled. And if deferrals reappear during re-ramp, drop back one step and hold for a full day. Do not push through.

What Google Postmaster Tools Tells You Now

Postmaster Tools at postmaster.google.com is the only real visibility Gmail offers, and it is mid-migration: v2 has launched, v1 is slated for deprecation, and the two interfaces do not show the same things.

Domain and IP reputation dashboards are being retired — but are not gone yet. They are absent from the Postmaster Tools v2 interface, and Google states the v2 API “will encompass all existing v1 functionality, except Domain and IP reputation.” The legacy interface that still carries them is slated for deprecation with no announced date (“Stay tuned for more information on timing”). As of July 2026 the High / Medium / Low / Bad grades remain documented and available in the legacy interface and v1 API. Use them while they last, but build your monitoring on spam rate and compliance status — those are the signals that survive the cutover.

What remains, and what each metric actually tells you:

• Spam rate — the percentage of delivered messages recipients manually marked as spam. Above all, this is your primary signal and the one that drives 421 4.7.28. Google’s guidance: keep it below 0.1% and prevent it from ever reaching 0.3%. Google: “Beginning June 2024, bulk senders with a user-reported spam rate greater than 0.3% will be ineligible for mitigation.” Eligibility returns once the rate stays below 0.3% for 7 consecutive days.
• Authentication — how often Gmail sees SPF, DKIM, and DMARC pass. As a result, anything short of full compliance explains authentication-flavored 421s directly.
• Compliance status — whether your sending meets Gmail’s bulk sender requirements, reported as Compliant, Needs work, or No data found. Deliberately deterministic, and the dashboard Google is steering senders toward as reputation grading is wound down.
• Delivery errors — rejection and deferral rates by reason. In short, this is where your 421s show up as a trend rather than individual log lines.
• Feedback loop and encryption — campaign-level spam identification and TLS coverage.

Postmaster Tools reports only on mail to personal Gmail accounts, and dashboards may be sparse on low-volume days for privacy reasons.

Gmail’s Bulk Sender Requirements

If you send 5,000 or more messages per day to personal Gmail accounts, you are a bulk sender and three requirements apply. Gmail and Yahoo document the full bulk sender requirements jointly. They took effect February 2024, and Google began ramping up enforcement on non-compliant traffic in November 2025.

1. Authentication. SPF and DKIM on your sending domain, plus a published DMARC policy. DKIM keys must be 1024 bits or longer, 2048 recommended. All senders must use TLS.
2. One-click unsubscribe. Marketing and subscribed messages must support RFC 8058 one-click unsubscribe and include a visible unsubscribe link. Requests honored within 48 hours. Required since June 1, 2024.
3. Spam rate. Below 0.1%, and never reaching 0.3%.

Non-compliance produces exactly the errors in the table above — which is why an authentication gap and a list quality problem can both surface as a 421.

How to Prevent Gmail Throttling

Treat deferral rate as a monitored metric

Alert on Gmail 4xx rate as a percentage of Gmail-bound attempts. A rising deferral rate is a leading indicator; a 5xx block is a lagging one. The entire value of Gmail’s throttling behavior is the warning time it buys you, and that warning is worthless if nobody is watching for it.

Sunset unengaged recipients on a schedule

Suppress recipients with no engagement in 90–180 days depending on send frequency, before they become complaints. Plan seasonal peaks as a ramp starting weeks ahead, not a cliff on the day.

Watch the spam rate daily during campaigns

The gap between 0.1% and 0.3% is where you still have room to react. Above 0.3%, mitigation options narrow sharply.

Shared IP vs. Dedicated IP: Who Fixes What

On a shared pool, IP-level rate limiting is your provider’s problem to manage and yours to avoid causing. But your list quality still drives the spam rate, and spam rate attaches heavily to your domain — yours alone, regardless of which IP carried the mail. You cannot hide a bad list in a good pool.

On a dedicated IP, the rate limit is purely a function of your own sending history. New or lightly-used dedicated IPs will see 421s during warm-up as a matter of course. That is normal. Warm up gradually and the limit rises with you.

How Mailercloud Handles Gmail Throttling

We deliver over a billion emails a month, so Gmail rate limiting is a daily operational reality rather than an incident. Our platform applies per-destination throttling and exponential backoff automatically, monitors 4xx deferral rates at the pool level so a throttle is caught before it becomes a block, and enforces authentication and list hygiene standards across shared infrastructure.

If Gmail is deferring your mail right now, talk to our deliverability team — or start free with Mailercloud and send on infrastructure that backs off correctly by default.

FAQ: Gmail 421 Deferrals