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

Gmail's concrete 4.7.28 detail is not confirmed for any class in this catalog's IANA registry mirror: the X.7.28 pattern remains unresolved. Any permanent-class counterpart is banned here and is never published or inferred. Existence and meaning rest solely on the exact corpus-collected Gmail 421 4.7.28 response, not on IANA registry confirmation. It identifies a temporary IP-level rate limit at this attempt, not a permanent block or an addressing error.

Gmail's own extension supplies 4.7.28: a temporary-class rejection stating that the sending IP has sent mail at an unusual rate that Gmail judges unsolicited and is therefore currently rate-limited to protect Gmail users. RFC 3463 Section 3.8 defines the general X.7 Security or Policy Status subject class for security- or policy-caused delivery failures, but does not enumerate detail 28. RFC 5248 provides the registry process for additional detail codes and treats Associated Basic Status Code lists as illustrative, not exhaustive. The catalog nevertheless keeps X.7.28 unresolved for every class because it has no confirmed registry entry.

The leading digit 4 denotes a persistent transient failure: Gmail is rate-limiting the sending IP now, but the condition may clear once volume, authentication, and list hygiene improve and Gmail reassesses IP reputation. It is not an assertion that the domain or IP is permanently blocklisted.

Class

Temporary failure

Retry

Controlled retry

Suppression

Check the full context

Retry with backoff, jitter, and a reduced sending rate; do not continue at the volume that triggered the limit. Use successful delivery at the reduced rate, not a fixed schedule, as the signal to stop escalating, then ramp volume back up gradually. Do not stop sending to the domain outright from a single 4.7.28; it is a rate signal, not a permanent rejection.

Do not suppress or remove a recipient from 4.7.28 alone. The condition is attached to sending-IP behavior and reputation, not a recipient mailbox or address. Base suppression on independent per-recipient signals such as hard bounces or permanent codes.

• The sending IP or domain recently increased volume, changed sending patterns, or sent to a list with many unengaged or invalid addresses, and Gmail classified a portion as unsolicited.
• Authentication is inconsistent (SPF, DKIM, or DMARC alignment), or mail comes from a shared or dynamic IP with mixed reputation.
• The accepted Gmail response points directly to its Bulk Email Senders Guidelines (support answer 81126), guidance for this condition rather than a general definition for every provider.

1. Inspect the raw SMTP response: confirm 4.7.28 is exactly class 4, never its banned class-5 counterpart, and confirm the basic reply is in the 4xx class (421 in the accepted example).
2. Identify the sending IP or domain and correlate it with recent volume, list-source, and authentication changes around the attempt.
3. Review the IP or domain against Gmail's Bulk Email Senders Guidelines and, where available, Postmaster Tools for spam rate and IP/domain reputation.
4. Reduce rate and retry in a bounded, backed-off way; after deliveries succeed, return volume gradually rather than immediately restoring the prior level.