4.2.2Recipient mailbox temporarily over its storage quota

When the recipient mailbox exists but exceeds its storage limit on this attempt, code 4.2.2 assigns registry pattern X.2.2 ("Mailbox full") a transient class rather than a permanent one. This catalog's mechanical IANA confirmation for X.2.2 covers only the class-5 variant (5.2.2, Associated Basic Status Code 552). This concrete class-4 code carries no such mechanical registry confirmation here; its existence and meaning rest solely on exact, corpus-collected production evidence (the Gmail 452 4.2.2 response below). The status names a mailbox-capacity condition at this attempt, not a permanently invalid address or an addressing error.

A destination mailbox that has exceeded an administrative storage quota or physical capacity, and that is not accepting messages, matches pattern X.2.2. RFC 3463 describes this pattern generically, without settling the class for every possible use. In this catalog the IANA registry mechanically confirms only the class-5 variant (5.2.2, basic SMTP code 552), which is a permanent rejection. The concrete code 4.2.2 (class 4) applies that same pattern as a transient failure and is published here on exact corpus evidence, not on an IANA registry confirmation for this class.

The leading digit 4 denotes a persistent transient failure: at the moment of this attempt the mailbox is over quota, but the condition may clear once the recipient frees space. Do not conflate this with 5.2.2, where the same X.2.2 pattern appears as a permanent failure.

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 (e.g. 5.2.2, 5.2.3), or once the limit is exhausted; do not treat a single 4.2.2 as grounds to stop retrying immediately.

Do not add the address to a suppression list based on code 4.2.2 alone. Inspect the full response and the history of bounded retries within the relevant window; suppress only after an independent permanent signal (an actual 5.2.2/5.2.3) or when the applicable list policy justifies it.

• The recipient has exceeded their personal mailbox storage quota (consumer Gmail account) and has not yet deleted messages to free space.
• A domain administrator (Google Workspace) has set a storage quota for the account that has been exceeded, and the organization has not yet increased the allocation.
• In the accepted Gmail example, the response links directly to Google's support page for a temporary over-quota condition (OverQuotaTemp) — documented behavior of this specific provider, not a general definition of code 4.2.2.

1. Inspect the raw SMTP response or delivery report and confirm that the enhanced code is exactly 4.2.2 (not 5.2.2), and that the basic reply is in the 4xx class (452 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 an over-quota support page).
3. Ask the recipient to check mailbox usage and delete unneeded messages (including trash and spam); in a business setting, ask the administrator to check the account's allocated quota.
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.