What does 452 mean in SMTP?

The requested action was not taken because of insufficient system storage. With the enhanced code 4.2.2 it means specifically that the recipient mailbox is full. It is transient, so the sending server should queue the message and retry.

What does 552 5.2.2 mailbox over quota mean?

The same full mailbox, returned as a permanent failure instead of a temporary one. Which of the two you get is a configuration decision at the receiving end. Gmail adds one useful distinction: its 552 wording says the inbox is out of space and inactive.

How to handle email addresses that bounce

Split on the class first. Suppress 5xx mailbox failures permanently. Retry 4xx deferrals on a schedule. A full mailbox is the awkward middle: real today, usually abandoned if it stays full for weeks — so count consecutive occurrences and suppress at a threshold rather than on the first one.

SMTP reply code

452 4.2.2 — mailbox full, try again later

A 452 4.2.2 reply means the mailbox exists but has no storage space left, sent as a temporary failure so the sending server queues and retries. The address is real; only the storage is the problem.

The facts

Reference facts for SMTP 452 4.2.2
Field	Value
Reply code	`452`
Enhanced status code	`4.2.2`
Class	4 — transient failure
Subject	2 — mailbox status
Detail	2 — mailbox full
Bounce type	Soft
Should the sender retry?	Yes
Representative wording	`452 4.2.2 The email account that you tried to reach is over quota`

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 452 4.2.2
Field	Value
`emailStatus`	`unknown`
`reason`	`mailbox_full`
`mailboxStatus`	`full`
`retryable`	`false`, despite the transient SMTP code. The probe established that the mailbox exists and is over quota, and asking again would establish the same thing.
Charged	Yes, 0.5 credits — something definite was established.

The one place the SMTP class and our retryable flag disagree

This is worth understanding, because it looks like an inconsistency and is not. 452 is transient for a sender — the message should be queued and retried, because the mailbox may have room later.

But the verification result is not marked retryable, because retryable answers a different question. It means "we learned nothing about this mailbox, so ask again". Here we learned a great deal: the mailbox exists, and right now it is over quota. Re-running the check would produce the same two facts.

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.

The signal underneath it

A full mailbox is a real mailbox, which is why it is never reported as undeliverable. But it is also the most reliable early indicator of an abandoned account: mailboxes fill up when nobody is deleting anything, and nobody deletes anything in a mailbox they have stopped opening.

Gmail says as much in the wording of its permanent counterpart. Its 452 4.2.2 reports that the inbox "is out of storage space"; its 552 5.2.2 reports that it is out of space "and inactive". The second is the same mailbox, later.

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. 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

Let your mail server retry. The address is real and the message may well be delivered later.
Do not suppress on the first occurrence.
If the same address is full across several sends over weeks, treat it as abandoned and stop mailing it.

If you own the receiving domain

Increase the quota or archive the mailbox’s contents.
Check whether the account belongs to somebody who has left, and close it properly if so — a permanently full mailbox is worse for senders than a clean rejection.

If you are a developer

Count consecutive full-mailbox responses per address and suppress at a threshold, not on the first one.
Branch on mailboxStatus: "full" rather than on emailStatus, which is unknown for several unrelated reasons.
Treat it as a list-hygiene signal, not only as a delivery failure.

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.