SMTP 421 4.7.28: your IP is temporarily rate-limited

421 4.7.28 is a 4xx temporary deferral. The receiving server is refusing the connection or transaction right now, specifically because of a policy decision tied to your sending reputation — not a permanent rejection. The fault sits with the sender in the sense that something about recent sending (volume, complaint rate, authentication, or blacklist status) triggered it, but the correct response is to slow down and fix the cause, not to treat it as a dead end.

Who is at fault

This is a sender-reputation deferral, not a recipient-side outage and not a true rate limit in the "too many requests per second" sense — the enhanced code 4.7.28 specifically ties the refusal to policy/security concerns (reputation, complaints, suspected abuse) rather than raw throughput.

The exchange

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250-mx.example.com
250 SIZE 35882577
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
421 4.7.28 Our system has detected an unusual rate of unsolicited mail originating from your IP. Please try again later.

The connection is refused mid-transaction, before any DATA is accepted — the message is never delivered on this attempt and will be retried automatically by your outbound MTA.

How the big three word it

Each provider encodes the same underlying concept — "we're declining you right now based on reputation" — with its own enhanced status code. Treat the exact code as provider-specific; the condition it describes is consistent.

Diagnose it

$ grep "421" /var/log/mail.log | tail -20
$ dig +short <your-ip>.zen.spamhaus.org

The grep line surfaces every 421 your MTA logged recently; if the hits cluster inside the same ten-minute window as one large campaign send, that campaign is the cause. The reversed dig lookup only returns an answer (something like 127.0.0.4) if the IP is currently listed on Spamhaus ZEN — no answer means it is not listed there, which is normal for this deferral, because 4.7.28 is frequently an internal policy decision by the receiving provider rather than a third-party blocklist hit. Don't stop at Spamhaus; repeat the lookup against bl.spamcop.net, and if you send through a shared host, ask the provider whether the IP is shared with other senders whose volume could be dragging your reputation down with it.

Check your recent send volume against your historical baseline, your complaint-rate data in Google Postmaster Tools, and whether your IP is on any actively-consulted DNSBL.

Fix it, in order

1. Reduce sending volume immediately to the affected domain or provider — stop the batch causing the spike rather than letting it retry at full rate.
2. Check Google Postmaster Tools spam-rate data (for Gmail) and confirm you're under the roughly 0.3% threshold Google treats as a problem.
3. Confirm SPF, DKIM and DMARC are aligned — authentication gaps compound reputation-based throttling.
4. Resume sending gradually, not at the volume that triggered the deferral.
5. Let your MTA's normal retry queue handle the deferred messages — they are not lost, they will retry automatically per your queue's backoff schedule.

How long the deferral typically lasts

Most 4.7.28 deferrals clear within a few hours to a couple of days once your sending volume and complaint rate drop back under the threshold that triggered it — this is not a fixed blacklist period with a published expiry, unlike a DNSBL listing that often states a TTL. Your MTA's own retry backoff (commonly starting around 15–30 minutes and stretching toward 4–24 hour intervals) keeps attempting delivery during this window without any action from you, and a message deferred this way is not lost unless it exceeds your queue's overall expiration window, commonly 3–5 days.

What not to do

• Don't treat this as a blacklist and go hunting for a delisting form. It's often not a published DNSBL listing at all, just an internal policy throttle.
• Don't retry the same batch immediately at the same volume. That reinforces exactly the pattern that triggered the deferral.
• Don't switch sending IPs as a first response. A fresh IP has no reputation at all and starts the whole problem over with less history to reason from.
• Don't leave the retry queue running at full concurrency while you investigate. Most MTAs will keep redialing the same mailbox provider every few minutes at the configured concurrency, which looks to the receiver exactly like the behavior that triggered the throttle and can extend the deferral window instead of shortening it.
• Don't assume one deferred domain means your whole IP is in trouble. 4.7.28 is usually scoped to the receiving provider that issued it; check whether other major providers are still accepting your mail normally before escalating to an IP-wide response.

MailPilot's warm-up ramps volume gradually and tracks per-provider inbox placement and complaint signals daily, so a deferral like this is visible before it escalates and the ramp-back after one is paced rather than guessed at.