InboxGrade

SMTP 552 — recipient mailbox exceeded storage quota

The remote MTA rejected delivery with a `552` response because the recipient's mailbox is at or above its storage quota.

Impact — Low impact

Messages to this recipient fail with a hard-bounce-like 552 5.2.2 or soft 452 4.2.2 until they clear space, so time-sensitive mail (receipts, password resets, calendar invites) never lands. Repeated bounces to the same address inflate your bounce rate on shared sending infrastructure, which some ESPs weight into reputation and sender scoring. If your list hygiene auto-suppresses on any 5xx, you may also silently stop mailing a valid user who simply has a full inbox.

What causes it

  1. Recipient hit a hard per-mailbox storage cap (common on legacy Exchange, cPanel/Dovecot, and free ISP accounts like orange.fr, t-online.de, web.de).
  2. Abandoned or rarely-checked mailbox accumulating years of mail with no retention policy or auto-archive.
  3. Shared/distribution mailbox (e.g. support@, info@) used as a dumping ground without a cleanup job or Exchange retention tag.
  4. Attachment-heavy inbound mail (invoices, scans, CI build artifacts) pushing the account over quota faster than the user prunes.
  5. Administrator-imposed quota reduction after a migration or storage-tier change that the user hasn't noticed yet.

How to fix it

Confirm it is a quota bounce, not a disguised block

Read the full DSN. A real quota bounce returns enhanced status 5.2.2 (permanent) or 4.2.2 (temporary) with text like Mailbox full, over quota, or insufficient system storage. Some providers return 552 for policy rejections too, so verify the enhanced code before treating the address as deliverable.

grep -iE '5\.2\.2|4\.2\.2|mailbox full|over quota|insufficient storage' /var/log/mail.log

Retry on a schedule instead of hard-suppressing

Treat 4.2.2 as transient and 5.2.2 as retryable-with-backoff, not as a permanent address failure. In Postfix, keep the message queued and let the retry schedule handle it; for application-level sending, back off for 24-72 hours before marking the recipient inactive.

# /etc/postfix/main.cf
maximal_queue_lifetime = 3d
bounce_queue_lifetime = 3d
minimal_backoff_time = 1h
maximal_backoff_time = 12h

Notify the recipient through an alternate channel

For business-critical mail (billing, auth, legal), surface the bounce to the sending application so it can prompt the user via SMS, in-app notification, or a secondary address on file. Do not keep silently retrying a quota-locked mailbox for days without telling anyone.

Separate 552 from reputation-driven blocks in your metrics

Tag 5.2.2 bounces as mailbox_full in your bounce classifier so they do not count against sender-reputation dashboards or trigger list-hygiene suppression. ESPs like Postmark, SES, and SparkPost expose a dedicated bounce type for this — use it instead of lumping all 5xx together.

Fixed it? Run a fresh test to confirm.

Test my inbox →

Related errors