What A 421 4.7.28 From Gmail Is Really Telling You

A 421 4.7.28 from Gmail means your sending IP address (or a related identity like your SPF or DKIM domain) has been temporarily rate limited because Gmail's systems detected an unusual volume of mail it judges to be unsolicited. It is a deferral, not a rejection. The 4 at the front of the enhanced status code tells you the condition is transient and the message should be retried, so your job is to back off, fix the underlying reputation problem, and let the queue drain rather than hammering the connection.

The exact string Gmail returns is documented and stable, and reading it literally saves a lot of guesswork. Senders who treat every Gmail failure the same way burn their reputation further by retrying aggressively against a server that is explicitly asking them to slow down.

The exact response, decoded

This is the full SMTP reply Gmail's MX hosts emit for this case:

421-4.7.28 [203.0.113.42] 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
421 4.7.28 review our Bulk Email Senders Guidelines. - gsmtp

Three parts carry the meaning:

• 421 is the SMTP basic reply code for "Service not available, closing transmission channel." Gmail is hanging up on this connection. It is not refusing the recipient or the content outright.
• 4.7.28 is the RFC 3463 enhanced status code. The leading 4 is class "persistent transient failure," meaning the message is valid and a future attempt may succeed. The .7. subject is "security or policy," and .28 is Gmail's specific subcode for reputation-driven rate limiting.
• The bracketed [203.0.113.42] is the IP Gmail flagged. That identity is the unit being throttled, though the same 4.7.28 subcode also appears scoped to a DKIM domain or SPF domain rather than the bare IP.

The phrase "unsolicited mail" is the tell. Gmail is not saying your individual message tripped a content filter. It is saying the aggregate stream from this identity looks like mail recipients did not ask for, so it is metering how fast you can deliver until the signal improves.

Why a 4xx is a retryable signal, and how to honor it

SMTP splits failures by the first digit. A 5xx is a permanent failure; the message will not be accepted in its current form and a well-behaved MTA stops trying and bounces it back to the sender. A 4xx is a temporary failure; the correct behavior is to keep the message queued and retry later with backoff. 421 specifically also closes the connection, so the retry has to be a fresh connection, not a pipelined continuation.

A sane retry schedule for a 4.7.28 defer looks like increasing intervals, not a tight loop:

attempt 1   t+0
attempt 2   t+15m
attempt 3   t+1h
attempt 4   t+4h
attempt 5   t+12h
give up     t+48h to 72h, then DSN to the original sender

The 48 to 72 hour ceiling matches the long-standing convention for how long an MTA holds a deferred message before generating a delayed-delivery and then a failure notice. Retrying every 30 seconds does the opposite of what the server asked and reinforces the "unusual rate" pattern that triggered the defer in the first place. If your MTA logs show the same 4.7.28 across thousands of recipients, do not turn retry intervals down. Turn sending volume down.

Fixing the reputation, not the symptom

The defer clears on its own once Gmail sees a cleaner stream, so the work is upstream of the queue. Concretely:

• Authenticate everything. SPF must pass for the return-path domain, DKIM must sign with a key published at selector._domainkey, and the From domain should carry a DMARC record. Authentication drift, like a rotated DKIM key whose public record was never published, makes an established sender suddenly look unfamiliar and invites throttling.
• Watch the complaint signal. Gmail asks bulk senders to keep the spam complaint rate below 0.1 percent and warns that crossing 0.3 percent puts delivery at risk. The Postmaster Tools dashboard shows this rate directly. A 4.7.28 that arrives alongside a rising complaint curve is the same story told twice.
• Warm volume gradually. A flat sender that suddenly emits a large batch, or a sender that just moved to a new IP, reads as anomalous. Ramp daily volume over days, not in one jump.
• Prune the list. Sending to addresses that never open, or that hard-bounced previously, drags the unsolicited signal up. Suppress them.

A useful diagnostic is to check whether the subcode is scoped to the IP, the DKIM domain, or the SPF domain by varying which identity is constant across the deferred messages. If every message from one DKIM d= domain is throttled regardless of IP, the reputation problem travels with the domain, and changing IPs will not help.

Saying it out loud

In an email-infrastructure interview, the cleanest way to explain this is to anchor on the code itself: "421 4.7.28 is a transient defer, class 4 so it is retryable, subject .7 so it is policy or reputation, and Gmail is throttling a specific identity, usually the IP, because the aggregate stream looks unsolicited. I would back the retry schedule off rather than tighten it, then go fix the actual reputation inputs: authentication, complaint rate, and volume ramp." That answer shows you read the code, you understand why a 4xx is not a 5xx, and you know the defer is a symptom of a sending-practice problem rather than a server bug to route around.