SMTP error code · permanent failure (5xx)

SMTP error 552 5.2.2: the recipient's mailbox is full

Samuel Chenard

By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 16, 2026

552 5.2.2 is a permanent rejection meaning the recipient's mailbox is full: the account is over its storage quota, so the receiving server refused your message. It's a recipient-side problem: you can only re-send after the recipient frees space or their admin raises the quota. The bounced message will not retry on its own.

552 5.2.2 at a glance
Code552 5.2.2
ClassPermanent (5xx): the message was refused and will not retry
CategoryRecipient
Side at faultRecipient
Auth-relatedNo

What the bounce actually says

The exact wording varies by provider. These are the documented strings, verbatim. Match yours to pin down which variant you hit.

Gmail (Google Workspace) — mailbox over quota and inactive

552 5.2.2 The recipient's inbox is out of storage space and inactive. Please direct the recipient to Manage files in your Google Drive storage.

Source: knowledge.workspace.google.com

Microsoft 365 (Exchange Online) — NDR body; the diagnostic line reads 554 5.2.2 mailbox full

552 5.2.2 The recipient's mailbox is full and can't accept messages now. Please try resending this message later or contact the recipient directly.

Source: learn.microsoft.com

Dovecot (cPanel and many shared mail hosts)

552 5.2.2 Quota exceeded (mailbox for user is full)

Source: doc.dovecot.org

Generic MTA — RFC 5321 base wording for code 552

552 5.2.2 Requested mail action aborted: exceeded storage allocation

Source: www.rfc-editor.org

Why you're seeing 552 5.2.2

The enhanced status 5.2.2 is RFC 3463's mailbox-full code: the account has exceeded its per-mailbox quota or the server's storage capacity. The receiving server found the address, tried to deliver, and refused because storing your message would push the mailbox past its limit. And because the class is 5 (permanent), your server bounced the message instead of queuing it. The wording tells you more than the number. Gmail only issues 552 5.2.2 when the account is over quota *and* inactive: an active-but-full Gmail inbox defers with the temporary sibling 452 4.2.2, which retries on its own. Microsoft 365 wraps the same condition in an NDR whose diagnostic line reads 554 5.2.2 mailbox full. Either way, this is one of the few bounce codes where nothing about the sender (DNS, authentication, reputation) is involved.

Likely causes, ranked

Likely causeWhat's happening
The recipient's mailbox is over its storage quotaThe plain case, and the most common. The account hit the storage cap set by its plan or admin, so the server refuses every inbound message until space is freed or the quota is raised. Smaller messages sent earlier may have squeezed in; quota is checked per delivery.
The account is abandoned or inactiveGmail's `552 5.2.2` wording says it outright: out of storage *and inactive*. Nobody is reading the mailbox, so it filled up and stayed full. If the same address bounces for weeks, treat it as dead and find another channel: this variant does not fix itself.
A shared mailbox or mail-enabled public folder hit its quotaIn Microsoft 365, mail sent to a mail-enabled public folder or shared mailbox bounces with the same NDR when its post quota (`ProhibitPostQuota`) or the hosting mailbox's quota is reached; the diagnostic shows `STOREDRV.Deliver.Exception:QuotaExceededException`. Individual mailboxes on the domain keep working, which makes this one confusing to spot.
Pooled storage filled up, not the inbox itselfGoogle accounts share one storage pool across Gmail, Drive, and Photos. A recipient whose Drive is stuffed with video files can have a nearly-empty inbox that still refuses mail. That's why Google's bounce text points at Drive storage management rather than deleting email.
Your message tipped a nearly-full mailbox overQuota is checked against the incoming message's size, so a 20 MB attachment can bounce while a plain-text note gets through minutes later. If only your large messages fail, the mailbox is hovering at its limit; send the file as a link instead.

How to fix 552 5.2.2

  1. Rule out a routing problem before blaming quota

    Run the recipient's domain through the free MX checker below. If the MX records resolve and point somewhere sane, your message reached the real server and the 5.2.2 verdict is genuine: the problem is on their side, not in your setup. Broken or missing MX produces different errors entirely.

    Run the check now

    Enter the sending domain and the check runs instantly on the next page. Free, no signup.

  2. Match the bounce text to the variant

    The wording picks your next move. Generic exceeded storage allocation or Dovecot's Quota exceeded is an ordinary full mailbox that may clear. Gmail's "and inactive" means nobody is minding the account. Microsoft's NDR can mean a personal mailbox, a shared mailbox, or a mail-enabled public folder hit its quota.

  3. Reach the recipient another way

    There's no sender-side fix, so tell them: phone, an alternate address, a colleague. Ask them to empty trash and delete large attachments, and on Gmail, to clear Drive and Photos too, since storage is pooled across all three.

  4. Re-send manually once there's space

    552 is a permanent (5xx) failure: your server already gave up when it handed you the bounce, and nothing is queued. Once the recipient confirms space is free, send the message again yourself.

  5. If it's your domain bouncing, fix the quota, not the senders

    Microsoft 365 admins: compare the mailbox's TotalItemSize against its ProhibitSendReceiveQuota in Exchange PowerShell, raise the quota or enable archiving, and check ProhibitPostQuota for mail-enabled public folders. Google Workspace admins: assign more storage or have the user clear the pooled Gmail/Drive/Photos usage.

  6. Suppress addresses that keep returning 552 5.2.2

    For lists and CRMs, treat repeated 552 5.2.2 as a hard bounce. An over-quota-and-inactive mailbox is abandoned; continuing to send wastes volume and drags down your sender reputation with mailbox providers that are watching your bounce rate.

Related free tools: DNS lookup · Email security score

Frequently asked questions

No. It's a recipient-side condition: the mailbox is out of storage. Your SPF, DKIM, DMARC, IP reputation, and content had nothing to do with it. The one thing you control: if only your large attachments bounce, the mailbox is hovering at its limit, and sending a link instead of a file may get through.

No. 552 is a permanent (5xx) failure, which means the sending server already stopped retrying when it generated the bounce. Nothing is queued anywhere. Once the recipient clears space, you have to send the message again yourself.

Same condition, different severity. 452 4.2.2 is the temporary version: the server defers your message and your side retries automatically for a day or two; Gmail uses it for an active account that's merely full. 552 5.2.2 is permanent: no retries. Gmail reserves it for accounts that are over quota and inactive.

Entirely up to the recipient or their admin; nothing on the sending side changes it. An active user who gets a storage warning often clears space within days. If the same address still bounces after a couple of weeks, assume the account is abandoned, contact the person another way, and remove the address from automated sends.

Check the mailbox's usage against its quota. In Microsoft 365, compare TotalItemSize with ProhibitSendReceiveQuota, and remember mail-enabled public folders and shared mailboxes have their own quotas that bounce with the same NDR. In Google Workspace, check the user's pooled storage across Gmail, Drive, and Photos. Raise the quota, enable archiving, or clear the store.

Related error codes

550 5.1.1550 5.4.1451 4.3.0
Email deliverability, fixed: the full guide

Not sure this code is your only problem?

Run a free email security score: every authentication and deliverability gap for your domain, in one pass.