SMTP 554 5.2.2: mailbox full, delivery permanently refused at this attempt

554 5.2.2 is a 5xx permanent failure for this specific delivery attempt, with enhanced code 5.2.2 meaning "mailbox full." Most providers treat a full mailbox as a temporary (4.2.2) condition that retries automatically, but some servers — particularly smaller or more strictly configured systems — issue a hard 554 instead, refusing the message outright rather than queuing it.

Who is at fault

Entirely recipient-side: their mailbox has exceeded its storage quota. There is nothing in your sending setup, content, or reputation involved.

The exchange

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250 mx.example.com
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
250 2.1.5 OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
554 5.2.2 Mailbox full, quota exceeded

How the big three word it

Gmail's version of this condition is genuinely a soft 4xx that your MTA will retry automatically; Microsoft 365 and Yahoo more often issue a hard 5xx for the same underlying full-mailbox condition, meaning that specific attempt is not retried even though the cause will likely resolve once the recipient clears space.

Diagnose it

$ grep "5.2.2" /var/log/mail.log | awk '{print $NF}' | sort | uniq -c

Check whether this is isolated to one recipient (their personal mailbox is full) or recurring broadly at one domain (which would suggest a provider-wide quota policy or an issue worth investigating further on their end).

A single isolated 5.2.2 against one recipient needs no action beyond the fix order below. A cluster of 5.2.2s against many different recipients at the same domain in a short window is a different signal worth a closer look - it can mean that domain's mail provider is under unusual load, or that your message itself is unusually large (a big attachment pushes marginal mailboxes over quota that would otherwise have had headroom). Checking the message size of the batch that triggered the cluster is a quick way to rule the second case in or out.

Fix it, in order

1. Confirm nothing is wrong on your side — this condition carries no sender-side cause to fix.
2. Don't manually resend immediately. If the base code was 554, your MTA won't auto-retry it the way it would a 452; resending too soon just repeats the same failure since the recipient's mailbox is still full.
3. Wait and resend later (days, not minutes) if this is a known, important contact — give the recipient time to clear space, which is entirely out of your control.
4. Reach the recipient through another channel if you have one and the message is time-sensitive — a full mailbox often means the person isn't actively checking that account.
5. Log the quota-bounce count per domain over time. A recipient domain that produces an unusually high rate of 5.2.2s relative to how much mail you send there can be a sign of an inactive or poorly maintained mailbox population on their side rather than anything about your sending - worth knowing before you draw conclusions about your own list quality from that domain's bounce rate alone.

What not to do

• Don't treat this as a hard bounce requiring suppression. A full mailbox is not evidence the address is invalid — many people recover from this within days once they clear space or the provider auto-purges old mail.
• Don't retry repeatedly in a short window. Especially with a hard 554, rapid retries against a known-full mailbox look like exactly the kind of persistence pattern that gets flagged by spam filters.
• Don't confuse this with 452 4.2.2 from Gmail specifically, which is a soft condition your MTA retries on its own schedule without any action from you.

Why the base code varies by provider at all

There's no RFC mandate forcing a 4xx or 5xx response to a full mailbox - RFC 5321 leaves the choice to the implementation, and providers have settled on different defaults based on how they want senders to behave. Gmail's 452 choice pushes the retry burden onto the sending MTA's normal backoff schedule, which is cheap for Gmail and transparent to the sender. Microsoft 365 and Yahoo's 554 choice shifts that decision back to the sender explicitly, trading a slightly worse sender experience for not having to manage a retry queue against mailboxes that might stay full for a long time. Neither choice is wrong; they're just different tradeoffs on the same underlying condition.

MailPilot's bounce classification treats quota-based rejections as a distinct category from reputation, authentication, or genuinely invalid addresses, so a run of full-mailbox bounces at one domain doesn't get mixed into your hard-bounce rate incorrectly.