Is 421 4.7.28 a rejection or a delay?

A delay, and the difference matters. The leading 4 makes it a transient reply (RFC 5321 §4.2.1): Gmail is telling your server 'not now, try again later,' not 'never.' A well-behaved sending server queues the message and retries on a normal schedule, and legitimate mail usually gets through on a later attempt. Compare that to a 550 5.7.x, where the 5 means permanent — retrying the same thing is pointless. So 421 4.7.28 is a yellow light, not a red one. But it's a warning: if the pattern that triggered it continues, Gmail escalates — first routing you to spam, then eventually to hard rejections. Treat a sustained 4.7.28 as reputation damage in progress, not a transient blip.

What does the '4.7.28' part actually decode to?

Read it in pieces. The 4 is the class — a persistent transient failure (RFC 3463): try later. The 7 is the subject — 'Security or Policy Status,' i.e. you were blocked for a policy reason, not a bad address or a full mailbox. The .28 is the detail, and this is where the RFCs stop: RFC 7372 registered .24 through .27 for authentication failures, but .28 is Google's own extension, documented in Gmail's sender guidelines, meaning specifically 'an unusual rate of unsolicited mail.' So the code says: temporary, policy-based, and tied to sending volume and reputation — not to whether a single message was authenticated correctly.

What identity is Gmail actually rate-limiting?

Not necessarily the one you think. Gmail attaches reputation to several identities at once — the sending IP, the wider IP netblock, the SPF domain, the DKIM signing domain, the domains of URLs inside your message, and the message pattern itself. The 4.7.28 fires against whichever of those is showing the unusual rate. That's why sharing an egress IP with other senders can get you throttled for someone else's behavior, and why a message that's authenticated but links to a burned URL domain can still trip it. Before you 'fix your IP,' figure out which identity is carrying the bad reputation — the fix is different for each.

Views: 26

421 4.7.28: Fix Gmail's 'Unusual Rate' Deferral

421 4.7.28: Gmail is deferring your mail over an unusual rate on your IP or domain. Find which identity it's throttling. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your outbound mail to Gmail stops landing. The logs fill with 421-4.7.28 and a line about an “unusual rate of unsolicited mail” from your IP or domain. Messages don’t bounce outright — they sit, retry, and trickle through late or drift into spam. Nothing about a single message looks wrong: SPF passes, DKIM signs, the address is real. Gmail isn’t rejecting the message. It’s throttling the sender because something about your recent sending pattern looks like a spam source, and it wants you to slow down while it decides.

Symptoms

The deferral carries 421-4.7.28 with Gmail text about an “unusual rate of unsolicited mail originating from your IP address” or DKIM domain.
Mail is delayed, not permanently bounced — it retries and some gets through hours later, often into the spam folder.
It started after a change: a volume ramp, a new sending platform, a campaign, or a migration to a new IP.
Individual messages authenticate fine — SPF, DKIM, and DMARC all pass — yet Gmail still defers.
Google Postmaster Tools shows a dip in domain or IP reputation around the same time.
Aggressive retries make it worse, not better; the deferrals get more frequent the harder your server hammers.

What 421 4.7.28 Actually Means

Decode the number before you touch anything. The 421 is an SMTP reply from RFC 5321: a transient negative reply — “service not available right now, try again later.” Crucially, it is not a permanent failure. Retrying on a sane schedule is the correct behavior, and legitimate mail often clears on a later attempt.

The enhanced code 4.7.28 narrows it down. The leading 4 repeats “persistent transient” (RFC 3463): temporary, retry later. The 7 is the subject class “Security or Policy Status” — you were blocked by policy, not because of a bad recipient or a full mailbox. The .28 is where the standards run out: RFC 7372 defined .24 through .27 for authentication-related failures, but .28 is Google’s own extension, documented in Gmail’s sender guidelines, and it means one specific thing — Gmail detected an unusual rate of mail tied to your sending identity.

That’s the whole diagnosis in one sentence: this is a reputation and rate problem, not a per-message authentication problem. It’s the opposite failure mode from 550 5.7.25 (reverse DNS) or 550 5.7.26 (unauthenticated), which are permanent rejections about a single connection or message. 4.7.28 looks past the individual message at your pattern — how much you’re sending, how sudden, to how many people who don’t engage — and it attaches that judgment to whichever identity is carrying the load: your IP, your IP’s netblock, your SPF domain, your DKIM domain, or even the domains of links inside your mail.

The reason it’s a deferral and not a rejection is that Gmail is giving you a chance to correct course. Keep sending the same way, or worse, retry aggressively, and it stops being polite: first your mail goes to spam, then the 4.7.28 hardens into outright refusals.

Top Causes

A sudden volume jump. You went from a few hundred a day to tens of thousands with no ramp. Reputation is built gradually; a vertical spike from an IP or domain with little history reads as exactly what a compromised host does. New IPs and newly-sending domains are the most fragile.
Low engagement and spam complaints. Gmail watches whether recipients open, reply, and don’t mark you as spam. A stale list, purchased addresses, or a campaign to people who forgot they signed up drives complaints up and engagement down — the strongest inputs to “unsolicited.”
Authentication drift splitting your reputation. SPF, DKIM, or DMARC alignment breaks after a platform change, so your good sending history no longer consolidates on one identity. Gmail can’t credit the reputation you built, and treats the traffic as coming from an unknown sender.
A shared or migrated IP carrying someone else’s baggage. On a shared egress IP (a relay, a cloud provider’s default, a shared ESP pool), another tenant’s spam can get you throttled. After migrating to a new IP with no reputation, you start from zero.
Bad retry behavior. When your server responds to a deferral by immediately re-hammering the same messages, it amplifies the exact rate signal that triggered 4.7.28 in the first place. The defer is a request to back off; ignoring it deepens the hole.

Diagnose with DechoNet

Email Check pulls your domain’s SPF, DKIM, and DMARC and shows whether they’re aligned — the single most important thing to verify, because aligned authentication is how Gmail attaches your good reputation to your domain instead of scattering it. If alignment is broken, every message you send is quietly building reputation for the wrong identity (or none), which is a direct driver of 4.7.28.
Reverse DNS Lookup checks the PTR / FCrDNS of your sending IP. Reverse DNS is a separate reputation input Gmail weighs, and a missing or mismatched PTR compounds a rate problem — clean it up so the IP side isn’t adding to the suspicion.

Resolution Checklist

Respect the deferral first. Make sure your MTA retries on a normal, backing-off schedule — not a tight loop. Hammering a 4.7.28 makes the rate signal worse. This alone stabilizes many cases.
Run Email Check and confirm SPF and DKIM pass and align with your From domain, with DMARC at least p=none and reporting on. Aligned auth is what lets Gmail credit your reputation to you.
Slow down and ramp. If you spiked volume, throttle back and increase gradually over days so the identity builds history instead of tripping the rate alarm.
Open Google Postmaster Tools for your domain and read domain reputation, IP reputation, and the spam-complaint rate. Google says to keep reported spam under 0.3%; anything approaching that is the real problem.
Clean the list. Remove non-engagers and hard bounces, stop mailing addresses that never open, and honor unsubscribes fast (one-click, per the 2024 sender rules). Complaints and dead weight drive the “unsolicited” verdict.
If you’re on a shared egress IP, find out who you’re sharing with. Moving to a dedicated IP — and warming it properly — takes you out of a neighbor’s blast radius.
Fix reverse DNS with Reverse DNS Lookup so the sending IP’s PTR forward-confirms; don’t let an IP-layer gap stack on top of the rate problem.

When to Escalate

If authentication is aligned, the list is clean, retries are sane, and Postmaster Tools still shows sinking reputation, you likely have a source you don’t control emitting mail under your identity — a compromised account, an open form, or an app relaying without limits. Hunt the traffic, not the record.
If a shared-pool provider’s IPs are the ones being throttled and you can’t isolate your own sending, the fix isn’t on your side — move to a sender or dedicated IP whose reputation you can actually own and rebuild.