4.2.1Recipient mailbox temporarily not accepting messages (receiving-rate limit)

On registry pattern X.2.1 ("Mailbox disabled, not accepting messages"), code 4.2.1 carries a transient class: the recipient mailbox exists, but on this attempt it is not accepting new messages. This catalog's IANA mirror lists no Associated Basic Status Code confirmation for X.2.1 at all, so neither class 4 nor class 5 is mechanically confirmed here; the concrete code's existence and meaning rest solely on exact, corpus-collected production evidence (the Gmail 450 4.2.1 response below). Evidenced behavior is narrower than the registry's generic wording: production systems chiefly return this code to report a temporary receiving-rate limit on one recipient, not a mailbox that has been switched off.

RFC 3463 frames X.2.1 as covering a destination mailbox that exists yet will not accept messages at this attempt, whether because it has been switched off or because some other condition blocks delivery. The same detail may describe either a permanent condition (the mailbox will never be re-enabled) or a persistent transient condition (the mailbox is only temporarily disabled), without settling the class itself. In this catalog's IANA mirror, the registry lists no Associated Basic Status Code for X.2.1 at all, so no class is mechanically confirmed here, unlike X.2.2, where the registry confirms class 5. Concrete code 4.2.1 (class 4) is published purely on exact corpus evidence: production mail systems return 450/452 4.2.1 predominantly to report that a specific recipient is currently receiving mail at a rate the system will not accept. That condition is narrower and more specific than the registry's generic "disabled" wording; it is not a registry-confirmed reading of this pattern.

The leading digit 4 denotes a persistent transient failure: at the moment of this attempt the mailbox is not accepting messages, but the condition is expected to clear once the receiving rate or other transient condition subsides. Do not conflate this with a permanent mailbox-status failure, where the same general X.2.x family of detail codes describes a condition unlikely to resolve on retry.

Class

Temporary failure

Retry

Controlled retry

Suppression

Check the full context

Retry with backoff, jitter, idempotency, and an attempt or time limit. Stop retrying after success, after a permanent code appears, or once the limit is exhausted; do not treat a single 4.2.1 as grounds to stop retrying immediately.

Do not add the address to a suppression list based on code 4.2.1 alone. Inspect the full response and the history of bounded retries within the relevant window; suppress only after an independent permanent signal in the same mailbox-status family (see Related codes) or when the applicable list policy justifies it.

• The recipient is currently receiving messages at a rate that exceeds a per-mailbox threshold (documented Gmail "ReceivingRate" behavior in the accepted example below): the account is not disabled, only temporarily throttled against a burst of incoming mail.
• A domain or mailbox administrator has placed a temporary hold on inbound delivery to a specific mailbox — for example while migrating, re-provisioning, or investigating a compromised account — which the same "mailbox disabled" registry wording also covers.
• The sending pattern itself looks like a spike (a bulk resend, a list explosion, a retried batch) and the receiving system is using this code as an anti-abuse throttle rather than a statement about the mailbox's long-term status.

1. Inspect the raw SMTP response or delivery report and confirm that the enhanced code is exactly 4.2.1 (not 5.2.1), and that the basic reply is in the 4xx class (450 in the accepted example).
2. Correlate the response with the specific message, attempt time, and recipient address; retain the full response text, including any provider link such as a receiving-rate support article.
3. Check whether the same recipient keeps returning 4.2.1 across many messages and senders (suggesting an account-wide throttle or hold) or only for this one burst (suggesting an ordinary transient rate limit).
4. Compare the results of bounded retries over time and stop them after success, after a permanent code appears, or once the configured attempt limit is reached.