5.2.2 mailbox full: the recipient is over quota

What the bounce means

The enhanced status code 5.2.2 means the recipient's mailbox is over its storage quota, so the receiving server refused to add your message. It usually appears as 552 5.2.2 or 550 5.2.2 with wording like “mailbox full” or “quota exceeded,” though the reply code and text vary by server; the enhanced code is the reliable part.

The address is valid. The account is active. The server would happily deliver if there were room. This is not a deliverability problem on your side, and nothing about your message, domain, or infrastructure caused it: the recipient has let their inbox fill up, and only they can empty it.

The one thing not to do

Because bounces so often point at authentication, the reflex after any 5.x.x is to go audit SPF, DKIM, and DMARC. For 5.2.2, resist it. No DNS or authentication change applies to this code; the message was refused for storage, not distrust. Touching records that already work, in response to a bounce they had nothing to do with, only risks creating the deliverability problem you did not have.

Why senders still care

“Their problem, not yours” does not mean “ignore it.” A mailbox that bounces full once is unremarkable: someone came back from vacation to a flooded inbox, or a free account brushed its quota. A mailbox that has been full for weeks is telling you something different: nobody is reading it. An engaged recipient clears space or upgrades storage; an abandoned inbox just sits there, full forever.

That makes repeated 5.2.2 a list-hygiene signal, the same family as 5.1.1 even though the mechanics differ. Sensible handling:

• Let the first bounce ride. A single full-mailbox bounce needs no action; the next scheduled send may well go through.
• Suppress on a repeated pattern. When an address returns 5.2.2 across several sends over weeks, stop mailing it. You are paying to send messages nobody reads, and steady bounces to an abandoned address add noise to your delivery stats at best.
• Restore on recovery. If the address later accepts mail (a re-subscribe, a reply, a successful confirmation send), it is alive again; lift the suppression.

The transient cousin: 4.2.2

Some servers do not jump straight to a hard failure. They first return the transient form 4.2.2, which tells your server “no room right now, try again later” and triggers quiet retries for a few days. If space frees up in that window, the message delivers and you never see a bounce. If the mailbox stays full past the retry window, the failure hardens into the permanent 5.2.2 and the message comes back to you. Same condition, two stages of giving up: seeing the 5.x.x form means the receiving side has already stopped waiting.

Frequently asked

What does a 5.2.2 bounce mean?

The recipient's mailbox is over its storage quota, so the receiving server refused to add your message. The address is valid and the account is active; there is simply no room. It is the recipient's problem to fix, and nothing on your sending side caused it.

Do I need to change SPF, DKIM, or DMARC after a 5.2.2?

No. 5.2.2 has nothing to do with authentication, reputation, or DNS. The message was refused for storage, not distrust. Changing your records in response to this code fixes nothing and risks breaking things that were working.

Why did I get 5.2.2 sometimes and 4.2.2 other times?

Some servers report an over-quota mailbox as the transient code 4.2.2 first, which tells your server to keep retrying quietly for a few days in case space frees up. If the mailbox stays full, the failure hardens into a permanent 5.2.2 bounce. Same condition, two stages of giving up.

Should I keep sending to an address that returns 5.2.2?

Not indefinitely. One full-mailbox bounce is routine, but an address that stays over quota for weeks is effectively abandoned; nobody is reading that inbox, or they would have made room. Treat repeated 5.2.2 bounces as a suppression signal and restore the address only if it starts accepting mail again.