SMTP Error 422

Is "SMTP Error 422" a real SMTP code?

No. RFC 5321 defines the transient (4yz) reply codes 421, 450, 451, 452, and 455 — there is no 422. Separately, RFC 4954 (the SMTP Authentication extension) defines two more AUTH-specific transient codes, 432 and 454, which are unrelated to mailbox delivery. None of these RFCs — nor RFC 3463 — define a 422. So "SMTP Error 422" is almost always one of two things:

• A misread of the enhanced status code 4.2.2 ("mailbox full"), defined in RFC 3463 §3.3. In a real bounce this travels inside a reply line, e.g. 452 4.2.2 The email account that you tried to reach is over quota. The 452 is the reply code; the 4.2.2 is the detail — and dropping the dots turns it into a fictional "422."
• A vendor-specific label that some ESP dashboards (e.g. SendLayer's "Error 422: Storage Limit Exceeded") use as a friendly name for the same over-quota condition.

The earlier version of this page called 422 a permanent error where "the connection drops during transmission." That's inaccurate on both counts — the underlying 4.2.2 is a transient failure and the SMTP session completes normally; the server just refuses that one message with a 4yz response.

What does the 4.2.2 "mailbox full" condition actually mean?

Per RFC 3463, X.2.2 means "the mailbox is full because the user has exceeded a per-mailbox administrative quota or physical capacity. The general semantics implies that the recipient can delete messages to make more space available." The leading 4 marks it as a persistent transient failure: the message is not lost, the address is not invalid, and delivery should succeed once space is freed.

Note the contrast with the permanent variant 5.2.2 (often paired with a 552 reply), which signals a mailbox that won't accept the message even on retry. Don't confuse "mailbox full" (recipient-side quota) with 452 "insufficient system storage" without an enhanced code, which is a problem on the receiving server, not the recipient's inbox.

How do I fix SMTP Error 422 / 4.2.2?

Because this is recipient-side and temporary, the sender usually can't resolve it directly — the goal is to retry sensibly without burning your reputation:

1. Treat it as a soft bounce, not a hard bounce. Do not immediately suppress or delete the address — it's valid.
2. Retry with exponential backoff over hours and days. In practice, virtually all production MTAs queue and retry 4xx responses automatically (RFC 5321 §4.5.4 permits the sending client to either requeue the message or return it to the user) — check your provider's or your own MTA's retry policy rather than re-sending in a tight loop.
3. Suppress only after persistence. If you see repeated 4.2.2 failures for the same address over several days (or it later returns a 5.x.x permanent bounce), pause sending to it.
4. Reach the recipient another way (SMS, push, a different inbox) if the message is time-sensitive, and ask them to clear space — empty Trash/Deleted Items and remove large attachments.
5. If you are over-sending, confirm the bounce is recipient quota and not your own outbound rate limit; the enhanced code disambiguates this.