4.7.28Sender IP temporarily rate-limited for unsolicited mail (Gmail)

Nowhere in this catalog's IANA registry mirror is Gmail's own concrete detail code 4.7.28 confirmed for any class under the X.7 (Security or Policy Status) subject; the X.7.28 pattern remains unresolved (null confirmedClasses). Any permanent-class counterpart is banned outright here and is never published or inferred. Existence and meaning rest solely on exact, corpus-collected production evidence (the Gmail 421 4.7.28 response below), not on IANA registry confirmation. The status names a temporary, IP-level rate limit at this attempt, not a permanent block or an addressing error.

Gmail's own extension supplies concrete code 4.7.28: a temporary-class rejection meaning the sending IP has sent mail at an unusual rate that Gmail's systems judge unsolicited, so the IP is currently rate-limited to protect Gmail users; it is published here purely on exact corpus evidence. RFC 3463 Section 3.8 defines the general X.7 "Security or Policy Status" subject class (X.7.0 through X.7.7) for delivery failures caused by security or policy, not by an addressing or mailbox problem; RFC 3463 itself never lists detail code 28. RFC 5248 sets out the IANA registry process that lets providers register further detail codes under an existing subject class beyond RFC 3463's base table, and treats the Associated Basic Status Code list for any entry as illustrative rather than exhaustive. In this catalog the registry mirror keeps X.7.28 unresolved for every class: it has never gained a confirmed registry entry, unlike some other X.7.2x details.

The leading digit 4 denotes a persistent transient failure: at the moment of this attempt, Gmail is rate-limiting the sending IP, but the condition may clear once sending volume, authentication, and list hygiene improve and Gmail's systems reassess the IP's reputation. Do not conflate this with a permanent block; this code does not mean the domain or IP has been blocklisted outright, only that the current rate is being throttled.

Class

Temporary failure

Retry

Controlled retry

Suppression

Check the full context

Retry with backoff, jitter, and a reduced sending rate; do not keep sending at the volume that triggered the limit. Treat the response code, not a fixed schedule, as the signal to resume normal volume: stop escalating once deliveries succeed at a lower rate, then ramp volume back up gradually. Do not treat a single 4.7.28 as grounds to stop sending to this domain outright — it is a rate signal, not a permanent rejection.

Do not suppress or remove any recipient address based on 4.7.28 alone: the condition is attached to the sending IP's behavior and reputation, not to any single recipient's mailbox or address validity. Suppression decisions should follow independent, per-recipient signals (hard bounces, permanent codes) rather than this shared, IP-level rate limit.

• The sending IP or domain recently increased volume, changed sending patterns, or began sending to a list with a high proportion of unengaged or invalid addresses, and Gmail's abuse-detection systems classified a portion of that traffic as unsolicited.
• The sender lacks consistent authentication (SPF, DKIM, DMARC alignment) or is sending from a shared or dynamic IP with mixed reputation, both of which make Gmail more likely to apply this rate limit.
• In the accepted Gmail example, the response links directly to Gmail's Bulk Email Senders Guidelines (support answer 81126) — documented guidance for exactly this condition, not a general definition of code 4.7.28 across providers.

1. Inspect the raw SMTP response and confirm the enhanced code is exactly 4.7.28, class 4 (not its banned class-5 counterpart, which this catalog never publishes), and that the basic reply is in the 4xx class (421 in the accepted example).
2. Identify which sending IP or domain triggered the limit and correlate it with recent volume, list-source, and authentication changes around the time of the attempt.
3. Review the sending IP's or domain's standing against Gmail's Bulk Email Senders Guidelines and, where available, Postmaster Tools (spam rate, IP/domain reputation).
4. Reduce the sending rate and retry in a bounded, backed-off way; stop escalating once deliveries succeed, and only then ramp volume back up gradually.