552 5.2.2 Mailbox Full / Over Quota: Fix

Problem

A message bounces with 552 5.2.2 and a line like “The email account that you tried to reach is over quota” or simply “Mailbox full.” The reflex is to go audit your SPF and DKIM — and it’s the wrong reflex. This code isn’t about who you are or whether you’re authenticated. It’s about the recipient having no room left. The receiving server accepted your connection, recognized the address, checked your credentials, and then discovered the mailbox it was supposed to file the message in is at its storage limit. That’s a problem on their side of the wire, not yours.

Symptoms

• The bounce carries 552 5.2.2 (sometimes 550 5.2.2 or the transient 452 4.2.2) with text about a full mailbox or exceeded quota.
• It hits one specific recipient or a handful, while everyone else on the same domain receives your mail fine.
• Your SPF, DKIM, and DMARC all pass — and mail from other senders to that same address is bouncing too.
• With Gmail recipients the exact string is 552-5.2.2 The email account that you tried to reach is over quota.
• The address sometimes starts accepting mail again with no change from you, because the recipient freed up space.

What 552 5.2.2 Actually Means

Read it as two separate claims. The 552 is the SMTP reply code, and RFC 5321 §4.2.3 defines it as “Requested mail action aborted: exceeded storage allocation.” The 5.2.2 is the enhanced status code from RFC 3463, and X.2.2 is defined precisely as “Mailbox full”: “the mailbox is full because the user has exceeded a per-mailbox administrative quota or physical capacity,” with the note that the recipient can delete messages to make room.

There’s a small standards oddity worth knowing, because it explains why you see two different codes for the same condition. RFC 3463 originally described X.2.2 as a persistent transient failure — meaning the RFC-correct pairing is the class-4 reply 452 4.2.2 (“full now, try later”). But most big receivers pair the same 5.2.2 detail with a permanent 5xx reply once retries stop helping. So the number after the dot tells you the cause (full mailbox), and the number before it tells you whether the server is still willing to retry:

• 452 4.2.2 — transient. The mailbox is full right now; your sending server should keep the message queued and retry. Don’t panic.
• 552 5.2.2 (or 550 5.2.2) — permanent. The server gave up. The message is dead and won’t be retried; you’d have to resend once the recipient clears space.

Either way, the fix lives with whoever controls that mailbox. This is the rare bounce where “there’s nothing you can do” is the technically correct answer — with two caveats below.

The Two Things Worth Checking on Your Side

You can’t add storage to someone else’s inbox, but you can make sure you’re diagnosing the right error:

1. It might be 5.3.4, not 5.2.2. A 552 5.3.4 (“message exceeds fixed maximum message size”) shares the leading 552 but is a completely different problem — your message is too big for the recipient’s size cap, and shrinking the attachment or using a link fixes it. If the enhanced code is 5.3.4, stop reading; this is your side. Only 5.2.2 is a quota problem.
2. Confirm it’s a real quota bounce, not a filter hiding behind quota wording. Some receivers and spam filters return quota-flavored rejections as a soft brush-off. If a whole domain suddenly bounces 5.2.2 — not one heavy user — treat it as suspicious and verify your own authentication and reputation before assuming everyone’s inbox filled up at once.

Diagnose with DechoNet

• Email Check pulls your domain’s SPF, DKIM, DMARC, and MTA-STS in one pass. It won’t see the recipient’s quota — nothing can from outside — but it proves the sender side is clean, so you can tell the recipient with confidence that the bounce is their storage, not your setup.
• Reverse DNS Lookup confirms your sending IP’s PTR/FCrDNS is healthy, ruling out the other family of 5.7.x rejections that people often confuse with a full mailbox.

Resolution Checklist

• Read the enhanced code, not just the 552. 5.2.2 = recipient mailbox full. 5.3.4 = message too large (your fix). 5.7.x = authentication/policy (a different guide entirely).
• Check whether it’s 452 4.2.2 (transient — leave it queued, it may still deliver) or 552/550 5.2.2 (permanent — resend later).
• If it’s one recipient: tell them to clear space (empty trash, delete large mail/files, or raise their storage). There is no sender-side fix.
• Run Email Check to confirm your SPF/DKIM/DMARC pass, so the conversation with the recipient stays on their storage, not your domain.
• If it hits a whole domain at once, don’t assume mass over-quota — verify your authentication and IP reputation first; a filter may be borrowing the quota code.
• If the bouncing users are on your server, raise the per-mailbox quota (Dovecot/Exchange/cPanel/Zimbra) and check disk space on the mail spool.

When to Escalate

• If the recipient is on a mail platform you don’t control and they insist their mailbox isn’t full, ask them to check total account storage — on Gmail and Microsoft 365 the quota is shared across mail, drive, and photos, and a full Drive silently blocks mail.
• If your own domain’s mailboxes bounce 5.2.2 across the board, escalate to whoever runs the mail server: it’s almost always a disk-full spool or a global quota set too low, and it needs a storage fix, not a per-user tweak.
• If authentication is clean, the recipient confirms free space, and 5.2.2 still fires, capture the full bounce with headers and take it to the receiving postmaster — at that point the quota accounting on their side is broken, and only they can see it.