552 mailbox full

The address exists and has nowhere to put your message

Where you saw it: A soft bounce naming quota or mailbox full, or a verification result flagging the mailbox as over quota where the server volunteers it.

Why it happens

  • The mailbox is abandoned. Nobody is deleting anything and the quota filled up over months or years.
  • A small quota on an old ISP account, some of which are still measured in megabytes.
  • A genuine temporary overflow from a large attachment, which clears when the person notices.
  • A departed employee whose mailbox was left running rather than being closed or forwarded.

The fix, in order

  1. Treat it as temporary at first

    A 552 is a 5xx code that behaves like a soft bounce in practice. One occurrence is not a reason to remove the address.

  2. Count consecutive failures

    The same address returning 552 across four or five sends means the mailbox is abandoned. That is a different conclusion from one failure.

  3. Suppress after a consistent pattern

    Three to five consecutive quota failures is enough. The mailbox exists and nobody is reading it, which makes it worthless to you and mildly harmful to your reputation.

  4. Check whether it correlates with engagement

    A full mailbox that last opened something two years ago is abandoned. A full mailbox that clicked last week is someone on holiday.

How to know it worked

The short version

  • The address either starts accepting mail again or moves to your suppression list.
  • Repeat quota failures stop appearing in every campaign report.
  • Your soft bounce rate drops after suppressing the persistent cases.

The second code tells you which 552 you have

A 552 on its own is ambiguous, because servers use it for more than full mailboxes. Look at the enhanced status code that follows it. Under RFC 3463, 5.2.2 means the mailbox is full, 5.2.3 means the message is longer than the recipient's limit, and 5.3.4 means the message is too big for the receiving system. Only the first is about the recipient. The other two are about your message, and sending a smaller one fixes them.

Gmail spells out the difference. Its published error list pairs 452 4.2.2 with "The recipient's inbox is out of storage space", and 552 5.2.2 with the same sentence plus the words "and inactive". So Gmail itself tells you which full mailboxes it expects to recover. A 452 is worth another try next week. A 552 5.2.2 from Gmail means the account is over quota and unused, which is as close to a closed mailbox as a quota error gets. Gmail's 552 5.3.4 reads "Your message exceeded Google's message size limits" and has nothing to do with the recipient.

Forty-one quota bounces from one send

Say your newsletter goes to 18,000 people and the bounce log shows 41 responses starting with 552. Reading the enhanced codes, 33 are 5.2.2 and 8 are 5.3.4. Those 8 all came from one corporate domain with a 10 MB limit, and your issue carried a large inline image. The addresses are fine. Your message was the problem.

Of the 33 real quota bounces, check each address's history. Suppose 19 have now failed four sends running and haven't opened anything since last year, 9 are first-time failures, and 5 are Gmail addresses marked inactive. Suppress the 19 and the 5. Leave the 9 alone and look again after the next send.

Many sending platforms store only "soft bounce" and drop the server's text, so ask whether the raw SMTP response can be exported. Without it you can't tell a full mailbox from an oversized message.

Questions people ask

Is a full mailbox a hard or soft bounce?

The code is a 5xx, which is technically permanent, and the condition is temporary. Most platforms treat it as a soft bounce, which matches reality better than the code does.

Can verification detect a full mailbox?

Sometimes. A server that reports the quota problem during the SMTP exchange tells us, and many do not mention it until the message body is delivered, which we never reach.

How long before I should give up on one?

Three to five consecutive campaigns. A mailbox full for that long is not being read by anyone.

Bounces from addresses that never existed are a different problem

We check a list before you send and label what nobody can resolve. 100 free checks a month, no card.