SMTP Error 522

Quick answer: "522" is not an official SMTP reply code. In practice it's used as a label for a recipient mailbox that is full or over its storage quota. The standardized code for this condition is 552 ("Requested mail action aborted: exceeded storage allocation", RFC 5321) carrying the enhanced status code 5.2.2 "Mailbox full" (RFC 3463). The fix is on the recipient's side: they must free space or raise their quota.

Is SMTP Error 522 a real SMTP code?

Not as a standalone reply code. RFC 5321 — the SMTP standard — lists its permanent 5yz reply codes in section 4.2.3: 500, 501, 502, 503, 504, 550, 551, 552, 553, 554, and 555. There is no 522 in that list. (A couple of other 5yz codes you may encounter, such as 521 and 556, were added later by RFC 7504, and 530 comes from the STARTTLS/AUTH extensions in RFC 3207/4954 — none of them mean "mailbox full" either.)

Where you do see "522," it is almost always one of two things:

• SendLayer documents this condition under the vendor label "Error 522" (their page cites no RFC code). Prolateral documents the same mailbox-quota condition under the standard enhanced-status label 5.2.2, not "522."
• An occasional mislabeling of a connection-level problem. If the "522" you're seeing came from a connection attempt rather than a delivery response, it is not an SMTP reply at all — investigate the socket/TLS layer instead.

So before you troubleshoot, read the full bounce string. If it contains 552 and/or 5.2.2 with text like "exceeded storage allocation", "mailbox full", or "over quota", treat it as the quota problem described below.

What causes a 522 / 552 (5.2.2) mailbox-full error?

Per RFC 3463, enhanced status X.2.2 means: "The mailbox is full because the user has exceeded a per-mailbox administrative quota or physical capacity." Common triggers:

• Recipient's inbox is at its storage limit — the most common cause. The receiving server refuses new mail until space is freed.
• A large message or attachment pushes an otherwise-near-full mailbox over the limit. (Note: a per-message size limit is a different condition — RFC 3463 status 5.2.3 "message length exceeds administrative limit" / a 552 with "message too large" — so check the text.)
• Server- or domain-wide storage exhaustion on the receiving side, which can surface as the same class of error.

This is the recipient's problem to resolve, not a misconfiguration on your sending infrastructure. (Contrast this with a true blocklist rejection, which returns a 5.7.x policy code, not 5.2.2.)

How do I fix SMTP Error 522?

If you are the recipient (or can reach them):

1. Free up space — delete large or old messages, empty Trash/Spam, and clear the Sent folder. Per-message storage often counts toward the quota.
2. Increase the mailbox quota with your email provider or administrator if you legitimately need more storage.
3. Confirm delivery resumes by having the sender retry after space is freed.

If you are the sender:

1. Do not hammer-retry. A 552/5.2.2 is a final response for that attempt; immediate resends won't help and excessive retries can hurt your sender reputation. Let your MTA's normal retry schedule run, or wait and resend once the recipient has cleared space.
2. Verify the recipient address is current and active. A chronically "full" mailbox can be an abandoned account — consider suppressing it to protect your bounce rate.
3. Reduce message weight if large attachments are involved — link to files instead of attaching them.
4. Use a different channel to reach an important recipient whose mailbox is full.