SMTP error 452 4.2.2: recipient mailbox full

452 4.2.2 combines the 4yz temporary-failure class with 4.2.2, which RFC 3463 defines

specifically as "mailbox full". This is one of the most unambiguous SMTP codes: the recipient's

storage quota has been exceeded, and the receiving server will not accept new mail into that

mailbox until space is freed or the quota is raised.

A real transcript

RCPT TO:<recipient@example.com>
250 2.1.5 Recipient OK
DATA
354 Start mail input
...
452 4.2.2 The email account that you tried to reach is over quota

How the big three word a full mailbox

This is worth noting carefully: Microsoft and Yahoo both commonly report a full mailbox as a

permanent 550/552 rather than the temporary 452 Gmail uses for the identical real-world

condition. Treat the leading digit from the actual reply you received as authoritative, not the

assumption that "mailbox full" is always temporary.

Who is at fault

Neither party in the usual sense — this is purely a recipient-side storage condition. It says

nothing about your sending reputation, your authentication setup, or your content. When reported

as a 4xx, it is explicitly temporary: once the recipient clears space, mail flows normally. When

reported as a 5xx by a provider that escalates it, treat it as you would any hard bounce.

Diagnose it yourself

1. Confirm the leading digit on the actual reply you received, not just the free text —

452, 550, and 552 all carry the same human-readable story but require different handling.

1. Check whether this is a one-off or a pattern for the specific address: `grep

"recipient@example.com" /var/log/mail.log | grep -c "4.2.2\|5.2.2"` — a mailbox that has been

full across multiple separate send attempts over days is functionally abandoned even if the

code is nominally temporary.

1. If you administer the recipient's mail system (relevant for internal senders), check actual

quota usage directly rather than inferring it from the bounce: most admin consoles report

mailbox size as a percentage of quota.

How to diagnose SMTP error 452 4.2.2

Understanding bounce messages

Read the full NDR text, not just the summary line your client shows — the enhanced status code

4.2.2 is the authoritative part, and it will appear in the embedded Diagnostic-Code field even

when the visible subject line is vague.

Checking server logs

If you run your own outbound mail server, your logs will show the exact reply string the

destination returned, which tells you definitively whether you are dealing with Gmail's 452 or

a provider that escalates to 550/552.

Verifying mailbox storage limits and usage

For addresses you administer, check the quota directly rather than waiting for another bounce to

confirm the condition has cleared.

Engaging with recipient's IT support (if applicable)

For an internal or known external contact whose mailbox keeps bouncing full, a message through

another channel is often faster than waiting out retries, especially once the pattern has repeated

across more than a few sends.

Resolving SMTP error 452 4.2.2

For email senders

Let your retry queue run; this clears itself the moment the recipient's mailbox has room again, in

the vast majority of cases with no action needed on your side. Watch for repetition from the same

address over your full retry window (typically 3-5 days) — a mailbox still over quota after that

means the message is dropped as undelivered.

For server administrators/recipients

Raise the user's quota, or have them delete or archive old mail and large attachments. If your

provider escalates full-mailbox conditions to a permanent code, treat repeated full-mailbox

bounces from the same user as an account health issue worth proactively fixing rather than waiting

for complaints.

What not to do

• Do not suppress the address after one 452 4.2.2 — this is a storage condition that resolves on

its own far more often than it persists, and premature suppression discards a real, reachable

recipient.

• Do not treat repeated occurrences as a sign your sending reputation is degrading; a full mailbox

rejects every sender equally, and chasing a reputation fix for a storage problem wastes time

without changing the outcome.

• Do not resend manually in a tight loop hoping to catch a gap in the quota — this just adds load

without improving the odds, and your MTA's scheduled retry already covers this.

• Do not assume every "mailbox full" bounce is temporary just because the condition sounds

temporary — some providers report it as a permanent 5xx, and treating that as a 4xx deferral

means you never clean up an address that is, in practice, dead.

MailPilot's delivery tracking distinguishes recipient-side deferrals like a full mailbox from

sender-side reputation drops, so a run of 452 4.2.2 replies does not get mixed into your

per-mailbox reputation score the way an authentication failure or rate limit would.