Recipient mailbox full: what the bounce means and what to do
A 'mailbox full' or 'over quota' bounce is not a bad address. How to read it, how long to keep retrying, when to stop, and what to tell the sender or customer.
On this page(9 sections)
You send an important message and a few minutes later a bounce arrives that says the recipient's mailbox is full, or over quota. Nothing is wrong with your domain, your content or the address. The person on the other end has simply run out of room.
This post explains how to recognize that bounce, why it behaves differently from other failures, and what to do about it as a sender, as an operator of a sending system and as someone whose own mailbox is the full one.
What a "mailbox full" bounce looks like
Receiving servers describe the problem in a few ways. You may see text such as:
- "Mailbox full"
- "Over quota" or "quota exceeded"
- "User is over the storage limit"
- "Insufficient system storage"
Behind the words there is a status code. Two families matter:
| Code | Meaning | How to treat it |
|---|---|---|
| 452 / 4.2.2 | Mailbox full, temporary | Retry for a while |
| 552 / 5.2.2 | Mailbox full, reported as permanent | Retry a few times, then stop |
The enhanced code 5.2.2 is the one that causes confusion. It starts with a 5, which normally means "do not try again", yet the address itself is fine. For the full list of codes and how to read them, see SMTP enhanced status codes.
Why it is not the same as a bad address
A hard bounce for an address that does not exist is final: that mailbox will never accept mail. A full mailbox is a condition that can change. The owner may delete old messages, buy more storage or have an administrator raise the limit. The next message might be accepted tomorrow.
That is why a good sending system does not treat all permanent-looking failures the same. Hard versus soft bounces explains the general split. Mailbox-full sits in the middle. Receiving servers disagree about which code to use, so you have to read the text and the enhanced code, not only the first digit.
What a sending system should do
If you run an application that sends mail, build a small rule for this case instead of leaving it to chance.
- Detect it. Match the enhanced code 4.2.2 or 5.2.2, and keywords such as "quota" and "mailbox full", on the bounce.
- Retry on a slower schedule. A full mailbox rarely empties within minutes. Spacing attempts over a day or two works better than hammering. The ideas in outbound retry and backoff policy apply directly.
- Give up after a fixed window. Two to three days is common for ordinary mail. After that, record the message as failed and tell your user.
- Do not suppress the address immediately. Putting an address on a permanent suppression list after one full-mailbox bounce throws away a working contact. A better rule is to count how many times in a row it happened. If every send over a couple of weeks reports a full mailbox, mark it as inactive for now and review it later.
- Keep it out of your complaint and reputation numbers. A full mailbox is a recipient problem, not an engagement problem. Log it with its own reason so reports do not blend it with address errors.
If you handle suppression for many customers, keep these counts per customer, as described in per-customer suppression and bounces in a multi-tenant app.
What to tell the sender
When a person, not a system, sent the message, the raw bounce is confusing. A short plain explanation helps. Something like:
Your message to Dana did not arrive. Her mailbox is full, so her mail server refused it. The address is correct. You can try again later, or contact her another way, such as a phone call or a message in another app.
The wording matters. Do not say the address is invalid, because the sender may delete a good contact. For more on turning technical failures into readable language, see explaining a bounced email to a customer in plain words.
What to do when it is a customer or colleague
If the full mailbox belongs to someone you work with, the fastest fix is a different channel. Send a short message elsewhere: "Your mailbox seems to be full, so my email bounced. Could you clear some space?" Many people have no idea, because their mail app does not warn them until it is already a problem.
If it is a business customer, ask whoever manages their email to raise the limit. In most hosted mail services an administrator can add storage or clear old data.
What to do when your own mailbox is full
Running out of space is easy to cause and easy to miss. It usually happens through large attachments, years of newsletters and automated notifications. A few habits keep it under control:
- Find the big messages first. Search for messages with attachments and sort by size. A handful of files often take most of the space.
- Remove notification noise. Automated alerts, receipts and newsletters you never open can go. A filter that archives or deletes them on arrival prevents the build-up.
- Empty the spam and trash folders. On many services they still count against your quota.
- Export before you delete. If you need a long-term copy, follow the steps in exporting and backing up a mailbox, then remove the originals.
- Watch for the warning. Some services email you at 90 percent or warn in the interface. Treat that as a task for the week, not something to ignore.
For a shared mailbox, make one person responsible for checking usage. Mail to a full shared address bounces for everyone who writes to it, which means customers can hit an error without your team ever seeing it. Retention habits such as those in team mailbox archive and retention habits keep a shared inbox from filling up in the first place.
How to tell it apart from other failures
A few quick checks separate a full mailbox from a different problem:
- Other messages to the same address succeed. If a small message went through yesterday and a large one bounces, the limit may be a per-message size limit rather than a full mailbox. The article on why attachments over 25 MB fail covers that case.
- Every message to that domain bounces. That points to a server or reputation problem on the receiving side, not one person's quota.
- The bounce mentions policy, authentication or a blocklist. Those are about you. See email not received: debugging for a step-by-step way to find out.
A short checklist
- Read the code and the text, not only the first digit.
- Treat 4.2.2 and 5.2.2 as "recipient problem", not "bad address".
- Retry slowly for two to three days, then stop and report.
- Do not suppress after a single occurrence; review repeated cases.
- Tell the sender in plain words that the address is fine.
- Suggest another channel to reach the recipient.
- Keep your own mailbox below its limit with filters and regular clean-ups.
Key takeaways
A "mailbox full" bounce says the person is unreachable by email right now, not that the address is wrong. Handle it with slow retries, a clear message to the sender and a rule that stops short of permanent suppression. Then keep your own inbox, and any shared one, comfortably under its limit so your customers never see the same bounce when they write to you.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
