Is 452 4.2.2 a bounce? Do I need to resend the message?

No, and no — resending by hand usually makes it worse. 452 is a 4xx code, which RFC 5321 §4.2.1 defines as a *transient* negative reply: the action didn't happen, but the condition is temporary and the same command may be tried again. Your sending mail server already understands this. It puts the message in its retry queue and re-attempts delivery on a schedule for hours or days without any action from you. If you manually resend on top of that, you don't speed anything up; you just queue a second copy that will land the moment the recipient frees space, so they get the message twice. The correct response to a 452 is to do nothing and let the queue work — unless it's been days, in which case see below.

How long before a 452 4.2.2 turns into a permanent 552 bounce?

It depends on the sending server's retry policy, but the common window is roughly 24 to 72 hours, with many setups defaulting to about four to five days total before giving up. RFC 5321 §4.5.4.1 lays out the retry logic: keep re-attempting a transient failure at increasing intervals until a configured timeout. While the recipient's mailbox stays full, every retry earns another 452. Once the sender's timeout is reached, it stops trying and generates a permanent failure — you'll see the delivery status escalate to a hard bounce, often 552 5.2.2 or 550 5.2.2 for the same 'over quota' condition. So 452 and 552 are the same problem at two stages: 452 is 'full right now, I'll keep trying,' and 552 is 'still full, I've given up.'

452 4.2.2 versus 452 4.3.1 — are they the same error?

Same 452 class, different owner of the fix. The basic code 452 is 'Requested action not taken: insufficient system storage,' and the *enhanced* code after it says whose storage. 4.2.2 is mailbox-scoped: this one recipient's mailbox is over its quota, while everyone else on the domain receives mail fine. 4.3.1 is server-scoped: the receiving mail system as a whole is low on storage — a full disk, a spool partition out of space — and it tends to defer mail for *many* recipients at once, not just one. If you're the sender, both are the recipient side's problem and both mean 'retry later.' If you run the receiving server, 4.2.2 points you at one user's quota and 4.3.1 points you at `df` on the mail spool.

452 4.2.2 Mailbox Over Quota: Temporary, Not a Bounce

Problem

A message doesn’t bounce, exactly — it defers. The log shows 452 4.2.2 with text like “mailbox full,” “over quota,” or “Requested action not taken: insufficient system storage,” and the message sits in your queue instead of failing outright. The instinct is to treat it like a rejection and start auditing your SPF, DKIM, and IP reputation. That’s the wrong instinct. A 452 is not a “no.” It’s a “not right now,” and the leading digit tells you so: 4xx means temporary. The receiving server accepted your connection, recognized the address, and then found the destination mailbox has no room to file the message. That’s a storage problem on their side, and it usually clears itself.

Symptoms

The reply carries 452 4.2.2 (sometimes shown as 452-4.2.2) with wording about a full mailbox or exceeded quota.
The message stays queued and retries rather than bouncing immediately — your mail log shows repeated deferrals to the same recipient.
It affects one recipient or a few, while everyone else on the same domain gets your mail normally.
Your SPF, DKIM, and DMARC all pass, and mail from other senders to that same address is deferring too.
Delivery sometimes just succeeds on a later retry, with no change on your end — because the recipient emptied their mailbox.

What 452 4.2.2 Actually Means

Split the code in two. The basic reply 452 is defined in RFC 5321 as “Requested action not taken: insufficient system storage,” and because it’s a 4yz code, §4.2.1 classifies it as a transient negative completion — the command failed, but “the error condition is temporary” and “the action may be requested again.” The enhanced code 4.2.2 narrows it: class 2 is the mailbox, and X.2.2 is specifically “mailbox full.” Put together, 452 4.2.2 reads as: this recipient’s mailbox is over its storage quota at the moment, try again later.

None of that is about you. A message with flawless authentication defers exactly the same way when the target inbox is full. There is nothing in your DNS, your SPF, or your sending IP that will make a full mailbox accept mail — only time, or the recipient clearing space, does that.

Why Your Server Handling It Is the Whole Point

The reason 452 exists as a separate code from 552 is so that well-behaved senders don’t give up. When your MTA gets a 452, it’s supposed to queue the message and retry on a back-off schedule (RFC 5321 §4.5.4.1) — a few minutes, then longer, then longer still — for a day or more before treating the failure as permanent. This is the system working: transient problems on the receiving end get ridden out automatically, and most 452s resolve before the sender ever gives up.

Which is why the two worst things you can do are both forms of impatience:

Manually resending queues duplicate copies that all deliver at once when space frees up.
Disabling or shortening retries turns a self-healing soft bounce into a lost message.

Leave the queue alone. If the mailbox clears within the retry window — and most do — delivery completes and nobody notices there was ever a problem.

When It Stops Being Temporary

A 452 becomes a real bounce when the sender’s retry timeout runs out while the mailbox is still full. At that point the transient 452 4.2.2 escalates to a permanent 552 5.2.2 (or 550 5.2.2) — same “over quota” meaning, but now the sender has quit and the message is returned. If you’re watching a message that’s been deferring for days, that’s the moment to reach the recipient by another channel and tell them to clear space; see the 552 5.2.2 mailbox full guide for the permanent-failure side of this. And if the deferral text is a 451 rather than 452, you may be looking at greylisting, which resolves on its own in a very different way.

Diagnose with DechoNet

Email Check confirms the part that isn’t the problem: it reads the recipient domain’s MX, SPF, and DMARC so you can rule your own authentication out in one pass and stop chasing a bounce that has nothing to do with you.
Reverse DNS Check is worth a look only if the deferrals persist past the expected window — a sending IP with no valid PTR can turn what should be a brief 452 into a policy deferral that never clears. That’s a different failure wearing the same code.

Resolution Checklist

Confirm the enhanced code is 4.2.2 (recipient mailbox full), not 4.3.1 (receiving server out of disk) — the fix belongs to different people.
Verify the message is queued and retrying, not bounced. A 4xx should still be in your mail queue.
Do not manually resend — you’ll create duplicates when the mailbox clears.
Confirm it’s recipient-specific: mail to other addresses on the same domain still delivers.
Rule yourself out: SPF, DKIM, and DMARC pass, so this isn’t authentication.
If it persists past ~24–72 hours, expect escalation to a permanent 552 5.2.2 and notify the recipient to free space by another channel.

If You Run the Receiving Server

If your own users’ inbound mail is deferring with 452 4.2.2, the quota is set per mailbox on your mail server, never in DNS — Dovecot’s quota plugin, Exchange’s ProhibitSendReceiveQuota, cPanel/Plesk per-account email quotas. Raise the limit for the affected user, or better, set a warning threshold below the hard quota so people are told before mail starts deferring. If df on the mail spool is also near full and every mailbox is deferring at once, you’re looking at a 4.3.1-shaped disk problem instead, and the fix is storage, not a per-user number.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.