What does 552 5.2.2 mailbox over quota mean?

The mailbox exists but has no storage space left, so the server refused the message. The address is real — this is a storage problem on the receiving side, not a bad address — although a mailbox that stays full for weeks is usually one nobody is reading any more.

What does 452 mean in SMTP?

It is the transient counterpart: the requested action was not taken because of insufficient system storage. A 452 4.2.2 is the same full mailbox as a 552 5.2.2, sent as a temporary failure so the sending server queues and retries instead of giving up.

Hard bounce vs soft bounce: what's the difference?

A hard bounce is a 5xx permanent failure, normally a mailbox that does not exist, and the address should be suppressed. A soft bounce is a 4xx transient failure and should be retried. A full mailbox is the awkward case: it appears as both, depending on how the receiving server is configured.

SMTP reply code

552 5.2.2 — mailbox over quota

A 552 5.2.2 reply means the mailbox exists but has no room for the message. The address is real; the storage is full. Sent as a permanent failure, but it is a full mailbox rather than a missing one.

The facts

Reference facts for SMTP 552 5.2.2
Field	Value
Reply code	`552`
Enhanced status code	`5.2.2`
Class	5 — permanent failure
Subject	2 — mailbox status
Detail	2 — mailbox full
Bounce type	Hard
Should the sender retry?	No
Representative wording	`552 5.2.2 Requested mail action aborted: mailbox full`

The representative wording is one real form of this reply. The exact string is set by the receiving server and varies between mail platforms — read the one in your own logs rather than matching on a string.

What VerifyInbox returns

What VerifyInbox returns for SMTP 552 5.2.2
Field	Value
`emailStatus`	`unknown`
`reason`	`mailbox_full`
`mailboxStatus`	`full` — distinct from `valid`, `invalid` and `unknown`
`retryable`	`false`. The probe established that the mailbox exists, and that fact will not change on a retry.
Charged	Yes, 0.5 credits — something definite was established.

A real mailbox that cannot take mail

The three-digit reply code comes from RFC 5321: a 2yz is a success, a 4yz is a transient failure the sender should retry, and a 5yz is a permanent failure the sender should not repeat in the same form. The dotted code beside it comes from RFC 3463 and has three parts — class.subject.detail — where the class repeats 2, 4 or 5, the subject says which part of the system had the problem, and the detail says what it was. The full list is an IANA registry established by RFC 5248, which is the authoritative source and the one nothing else ranking for these queries cites.

Subject 2 is mailbox status and detail 2 is mailbox full. That is a materially different fact from 5.1.1, where subject 1 says the problem is the address itself. Here the address resolved to a real mailbox; the mailbox simply has no room.

The same condition appears as a transient 452 4.2.2 on many servers, and which one you get is a configuration choice at the receiving end rather than a difference in the underlying situation. A server sending 552 has decided not to hold the message.

Gmail’s wording adds one useful word. Its 452 4.2.2 says the inbox "is out of storage space"; its 552 5.2.2 says it is "out of storage space and inactive". An inactive full mailbox is a strong signal that nobody is reading it, which is a different decision for a sender than a full mailbox somebody is still using.

Why a verifier reports this as unknown rather than deliverable

The mailbox exists, so undeliverable would be false. But mail queued to it bounces, so deliverable would be misleading in the only way that matters to someone about to send. unknown with reason: "mailbox_full" and mailboxStatus: "full" is the honest answer: here is exactly what we found, and you decide.

And it is not marked retryable, even though the SMTP code for the same condition can be transient. The reason is precise: retrying would establish the same thing — that the mailbox exists and is over quota. retryable means "we learned nothing, ask again", not "the situation may change".

What each provider actually says

Quoted from each provider's own published documentation, with the date it was read. Not paraphrased into a claim about what a provider "always" returns.

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

Gmail, read 11 September 2026

What to do

If you sent the message

The address is real, so do not suppress it on the first occurrence.
Try again later — many servers will accept once the mailbox is cleared.
If it recurs for weeks, treat it as abandoned. A permanently full mailbox is a hard bounce with a slower fuse.

If you own the receiving domain

Raise the quota, or archive the mailbox’s contents.
Check whether the account is still in use at all — a long-full mailbox usually belongs to someone who has left.
Consider returning the transient 452 4.2.2 instead, so senders queue rather than give up.

If you are a developer

Do not fold this into your hard-bounce suppression on the first hit. Count it separately.
Suppress after a threshold of consecutive full-mailbox responses rather than immediately.
Branch on mailboxStatus: "full" rather than on the verdict — the verdict is unknown, which it shares with several unrelated conditions.

To find out whether an address will return this before you send to it, run it through the free email verifier

Related codes

Related terms

Sources

Primary sources checked 11 September 2026. If something here is out of date, tell us and we will correct it.