421 4.7.28 "Our system has detected an unusual rate of unsolicited mail originating from your IP address" — Gmail Fix Guide

If Gmail is deferring your mail with something like this, you've hit a Gmail IP-reputation throttle:

421-4.7.28 [203.0.113.42 15] Our system has detected an unusual rate of
421-4.7.28 unsolicited mail originating from your IP address. To protect our
421-4.7.28 users from spam, mail sent from your IP address has been temporarily
421-4.7.28 rate limited. Please visit
421 4.7.28 https://support.google.com/mail/?p=UnsolicitedRateLimitError to
review our Bulk Email Senders Guidelines. - gsmtp

This is not a hard block, not a blocklist listing, and not an authentication failure. 421 4.7.28 is Gmail's per-IP reputation throttle: when the volume or spam-signal rate from your sending IP crosses Gmail's rolling threshold, Gmail soft-bounces (4xx) new mail from that IP until the signal drops.

The critical detail almost everyone misses on the first read: this code is keyed to the IP address, not the sending domain. Two senders sharing the same outbound IP can take each other down, and a clean domain on a noisy shared IP will hit 421 4.7.28 even with perfect authentication.

What 421 4.7.28 Actually Means

Break the response down piece by piece:

• 421 — SMTP "service not available, closing transmission channel." A 4xx code is a transient failure. Your MTA will keep the message in the queue and retry on its normal schedule.
• 4.7.28 — the enhanced status code. The leading 4 confirms transient. 7 is the policy/security subject. 28 is Gmail's specific subcode for "sending IP rate limit due to unsolicited mail signal."
• [203.0.113.42 15] — the exact IP Gmail is throttling, plus an internal counter. The IP is the one you must investigate; the domain is secondary.
• unsolicited mail originating from your IP address — Gmail's wording is deliberate: complaints, spam-folder placement, and engagement-weighted signals from that IP over Gmail's rolling window crossed the threshold.
• temporarily rate limited — emphasis on temporary. There is no removal form. The throttle releases automatically once the rolling signal drops.

The key distinction from the more generic 421 4.7.0 Gmail rate limit: 4.7.0 is volume-based and triggers on raw rate-per-second / rate-per-recipient. 4.7.28 is reputation-based and triggers on the quality signal aggregated against the IP. Slowing down alone fixes 4.7.0; it does not necessarily fix 4.7.28.

Most Common Root Causes

In real-world incidents, 421 4.7.28 traces back to one of these:

• Shared sending IP with a noisy neighbor. If you're on a shared pool at an ESP (SendGrid, Mailgun, Amazon SES, Postmark, etc.), another tenant's bad send can poison the IP for everyone. This is the single most common cause for SaaS senders.
• Rising spam-complaint rate on the IP. Anything over 0.10% sustained is a problem at Gmail; 0.30% is the red line. Even a single bad campaign can spike the rolling rate.
• Sudden volume ramp from a cold IP. Going from 1,000/day to 100,000/day overnight, even with clean content, looks indistinguishable from a compromised relay to Gmail's reputation system.
• Missing or weak DMARC on the sending domain. 4.7.28 is IP-keyed, but Gmail still factors domain-level DMARC pass rate into the IP score. A flood of p=none traffic with low alignment hurts the IP it was sent from.
• Compromised account or open relay on the IP. If a customer or internal account starts blasting through your relay, the IP can hit 4.7.28 before you notice.
• Bad bounce / list-hygiene profile. High hard-bounce rates and pings to spam traps weigh against the IP just like complaints do.

Step-by-Step Fix

Work this list in order. Skipping steps usually means the throttle comes back within hours.

1. Confirm which IP is throttled. Pull the exact IP from the bounce string (the bracketed value). Don't assume — if you have multiple outbound IPs, only one may be affected.
2. Check the IP against major DNSBLs. A 4.7.28 deferral and a fresh DNSBL listing usually share a root cause. Run the IP through the free Blacklist Checker and the Spamhaus ZEN wiki page to see what's listed and why.
3. Pull Postmaster Tools data for the IP and domain. Gmail Postmaster Tools shows IP reputation (Bad / Low / Medium / High), domain reputation, spam-complaint rate, and authentication pass rate. If you don't have it set up, follow the Google Postmaster Tools guide — this is non-optional going forward.
4. Pause sending from the affected IP. Continuing to push volume into a 4.7.28 throttle makes the rolling signal worse, not better. Stop the offending campaign or, if you can, drain traffic to a different known-good IP.
5. Identify the offending segment or tenant. Cross-reference Postmaster Tools complaint spikes with your campaign log. If you operate a multi-tenant platform, isolate which customer's send triggered it.
6. Suppress hard bounces and unengaged Gmail recipients. Drop anyone who has hard-bounced, complained, or hasn't opened in 90+ days from the Gmail segment specifically before resuming.
7. Verify authentication still aligns. 4.7.28 isn't an auth failure, but a 4.7.28 throttle layered on top of broken DMARC means Gmail will give you no goodwill. Re-check SPF, DKIM, and DMARC alignment for every sending domain on that IP.
8. Ramp back up gradually. Don't resume at the volume that caused the problem. Restart at roughly 25% of pre-incident volume to the cleaned segment, monitor Postmaster Tools for 48 hours, then step up.

If you're on shared infrastructure and can't isolate the bad neighbor, the realistic options are: ask your ESP to migrate you to a different pool, move to a dedicated IP, or hire a deliverability expert to triage and negotiate the move on your behalf.

How Long Until 421 4.7.28 Clears

4.7.28 is rolling, not absolute. The throttle lifts as soon as the IP's reputation signal over Gmail's measurement window drops below threshold. In practice:

• A few hours — if you stopped sending immediately and the spike was small and isolated.
• 24 to 72 hours — for a typical mid-size incident where you've paused, cleaned the segment, and resumed at lower volume.
• A week or more — if you kept sending into the throttle, or if a shared IP keeps getting re-poisoned by another tenant.

Because it's rolling and not a listing, there is no Gmail "removal request" form for 4.7.28. Gmail's own documentation explicitly tells senders to remediate, not contact them. The throttle clears on its own once the signal drops.

FAQ

Is 421 4.7.28 the same as being blacklisted by Gmail? No. 4.7.28 is a temporary, reputation-driven IP throttle applied by Gmail's own systems — it is not a third-party DNSBL listing and won't appear on Spamhaus, SORBS, or SpamCop directly. It clears automatically once the rolling signal falls back under threshold.

Will fixing SPF, DKIM, and DMARC clear 4.7.28? Not directly. 4.7.28 is keyed to the IP's spam signal, not authentication state. But broken authentication makes Gmail less willing to extend you the benefit of the doubt on engagement, so fixing it in parallel is still worth doing.

Will retrying the send immediately help? No — it usually makes it worse. Retrying floods Gmail with the same volume that triggered the throttle, which keeps the rolling signal elevated. Pause, clean, then resume at lower volume.

Do I need to contact Google to remove 4.7.28? No. Google does not offer a 4.7.28 delisting form because there is nothing to delist. The throttle is computed in real time from your IP's reputation signal and clears on its own. Continuous IP and DMARC monitoring is the closest thing to a preventive fix.

Can I just switch to a different sending IP to bypass it? Sometimes, yes — but only if the new IP has its own clean warm-up history. Cycling to a fresh, cold IP usually transfers the problem rather than solving it, because the underlying cause (segment quality, list hygiene, content) is still in place.

Bottom Line

421 4.7.28 is Gmail telling you, in real time, that your sending IP is producing more spam signal than Gmail's rolling threshold tolerates. It's reversible, it's not a blocklist, and there is no support ticket to file. Pause the offending traffic, identify the source via Postmaster Tools, clean the segment, verify authentication, and ramp back up gradually — and the throttle lifts itself within hours to a couple of days.

If you want continuous visibility into the signals that drive these throttles — IP blocklist status, DMARC pass rate, Postmaster-style reputation drift — MailVitals monitors all of it 24/7 so the next 4.7.28 is something you avoid, not something you discover from a stuck queue. And if you're stuck on a shared IP you can't move off, our team can take the remediation off your plate — book a deliverability expert here.

👉 Continue: 421 4.7.0 Gmail Rate Limit · Google Postmaster Tools Guide · SMTP Error Codes Explained