Short answer
A 552 5.2.2 bounce means the recipient's mailbox is full. The receiving server accepted the connection, looked at the mailbox and refused the message because there was no room for it. This bounce is not about your domain or your IPs. You can only be sure of that if you can read the full reply the receiver sent. That is why this guide starts with the bounce text. A provider dashboard that shows only "bounced" leaves you guessing about who has to act.
What 552 5.2.2 means
A bounce like this carries two codes and a sentence. Here is how to read them, and the SMTP error code reference has the full list:
- 552 is the basic reply code from SMTP (RFC 5321). The first digit, 5, means permanent failure. The second digit, 5, means the problem is in the mail system or the mailbox.
- 5.2.2 is the enhanced status code from RFC 3463, read as class.subject.detail. Class 5 repeats "permanent". Subject 2 means the problem is with the mailbox. Detail 2 is the specific reason, mailbox full.
- The text is written by the receiving server. It is often the most useful part.
The cause is plain. Every account has a fixed storage quota, and once it is full no new messages are accepted until the recipient frees space. It comes up often with iCloud addresses, where mail shares storage with photos and files. Gmail also uses this code for a full mailbox that has gone inactive.
Why this bounce is the recipient's mailbox, not your reputation
The enhanced code tells you which side the problem is on. Subject 2 is the mailbox. Subject 7 is security and policy, and that is where reputation, blocklist and authentication refusals live. A 5.2.2 says the receiver has nothing against you. It had nowhere to put the message.
Some guides say 552 5.2.2 means your sending provider's quota ran out, or that it comes from sending too much to an old list. That is not what the code says. Your provider's daily or monthly limit is enforced by your provider, and it is reported by your provider's API. A remote server does not report it in a bounce. A 5.2.2 comes from the recipient's server, about one recipient's mailbox.
Do not change your DNS, rotate IPs or open a deliverability ticket over a single 5.2.2. The fix sits with whoever owns that mailbox.
Read the bounce message line by line
Here is an example. Each receiver writes its own text, so the wording varies:
552 5.2.2 Quota exceeded (mailbox for user is full)Read it in this order:
552: permanent. Your server will not keep retrying this exact delivery on its own.5.2.2: the mailbox subject, the full detail. This is the part to branch on in code.- The text: confirms the reason in the receiver's own words. "Over quota", "mailbox full" and "quota exceeded" all mean the same thing.
Sometimes the text starts with LMTP error. LMTP is the protocol many mail systems use for the last step, handing the message from the receiving server to the mailbox store. An LMTP prefix tells you the message got all the way inside the recipient's system and was refused at the mailbox itself. That is one more sign it was not refused at the front door because of who sent it.
If you are reading a bounce you received as a person, the codes are usually in the body of the "Delivery Status Notification" or "Undeliverable" message. The email header analyzer is useful when you need to trace where it came from.
If it's your own mailbox: free up space or raise the quota
If other people's mail to you is bouncing with 552 5.2.2, your mailbox is the full one.
- Delete large attachments first. A few messages with big files take up more space than thousands of plain ones. Daily reports with large spreadsheets are a typical example of mail that fills a mailbox without anyone noticing.
- Empty trash and spam. On most services, deleted mail still counts against the quota until the trash is emptied.
- Check shared storage. On iCloud and Gmail, mail shares one quota with files and photos. Gmail's free storage is 15 GB, shared across the account. Clearing a large backup can fix mail delivery.
- Check forwarding. Forwarding without deleting the original keeps two copies, and forwarding a work account into a personal one can fill both.
- Check IMAP retention. A client that downloads mail but never removes it from the server leaves the server copy counting against the quota.
- If you are the admin, raise the quota. On a company mail server, the per-user limit is a setting. Raise it or set an archive policy rather than asking every user to clean up by hand.
Once there is space, new mail is accepted. Anything that already bounced with a 5xx does not come back on its own. Ask the sender to send it again.
If you're the sender: what your app should do next
You cannot clear someone else's mailbox. You can decide what your system does, and that decision matters most for mail a user is waiting on.
- Do not resend in a loop. The mailbox is still full a minute later. Each resend is another bounce in your logs.
- Stop sending, then send again once it clears. People do clear their mailboxes, so one full-mailbox bounce is not a reason to drop a real customer forever. Hold mail to that address until the user tells you there is space.
- Tell the user in your product, not by email. If a password reset or sign-in code bounced with 5.2.2, the user is probably looking at your sign-in screen. Show a message there: "We couldn't deliver to this address because the mailbox is full. Free up space or use a different address." An email saying the mailbox is full cannot be delivered either.
- Offer another way in. For sign-in codes, let the user change the address on file or use a second factor they already set up.
- Keep the address for receipts and billing. Store the bounce against the address so support can see why a receipt never arrived, and send it again once the user has made space.
On Groundmail, a 552 5.2.2 puts the address on your suppression list automatically, so a retry is refused with a 422 and an email.suppressed event until you take it off. Once the user has made space, remove it in the dashboard or with DELETE /suppressions?email=… using a full-access key, then send again.
Our guide to soft and hard bounces explains why a full mailbox sits between the two. The code is permanent, but the condition usually clears.
Handle the bounce with webhooks
On Groundmail, a server that refuses the message during delivery reaches your code as an email.failed event with data.bounce_type set to hard. A bounce report that arrives after delivery comes as email.bounced. Subscribe your webhook endpoint to both, because a 5.2.2 can arrive either way. Each event is signed with your endpoint's secret in a Groundmail-Signature header, and the Node SDK checks the signature for you. The other events you will want next to them are email.delivered, email.delivery_delayed, email.suppressed and email.complained.
Your handler should not treat every bounce the same way. The enhanced code has no field of its own, so read it from data.bounce_reason, which holds the receiver's reply when there is one:
const enhanced = event.data.bounce_reason?.match(/\b[245]\.\d{1,3}\.\d{1,3}\b/)?.[0]| Enhanced code | What it means | What the handler does |
|---|---|---|
| 5.1.x | The address doesn't exist | Stop using the address; it is already suppressed |
| 5.2.2 | Mailbox full | Mark the address, show an in-app notice, and remove the suppression once the user has made space |
| 5.3.4 | Message too big | Fix the message, not the address |
| 5.7.x | Receiver refused the sender | Keep the address and investigate your sending |
Deferrals such as a temporary mailbox-full reply arrive before the final outcome. Watch email.delivery_delayed for those rather than email.failed. Our developer features page lists every event and explains how to fire a test event at an endpoint with POST /emails/test.
Test it before it happens in production
Do not wait for a real user with a full iCloud account to find out what your handler does. A Groundmail test key (gm_test_…) runs the whole sending pipeline, fires the same webhooks a real delivery would and delivers nothing. Test sends do not count toward your plan, your stats or your bill.
Addresses at simulator.groundmail.dev return a specific outcome with real webhook payloads and signatures. bounce@ returns a hard bounce for a mailbox that doesn't exist. delayed@ returns a deferral from the receiving server. Plus addressing works, so you can tell test cases apart:
import { Groundmail, simulatorAddress } from 'groundmail'
// A gm_test_ key runs the whole pipeline but delivers nothing
const groundmail = new Groundmail(process.env.GROUNDMAIL_TEST_KEY!)
await groundmail.emails.send({
from: 'you@yourdomain.com',
to: simulatorAddress('bounce', 'signup-42'),
subject: 'Bounce handling test',
html: '<p>Simulated.</p>',
})
// → your webhook gets email.bounced with "test": trueUse bounce@ to prove your endpoint receives email.bounced, verifies the signature and stores the result, then fire email.failed at it with POST /emails/test so both paths are covered. Use delayed@ to prove deferrals do not trigger the user-facing "couldn't deliver" path too early. Then add a unit test that feeds your branching logic a 5.2.2 code, so the mailbox-full path is covered separately from the user-unknown path.
How 552 5.2.2 differs from 552 5.3.4, 5.2.3 and the temporary 4.2.2
These codes look alike, and the wrong reading leads to the wrong fix. The 5.2.3 definition comes from RFC 3463.
| Code | Means | About | Retry? | Suppress? |
|---|---|---|---|---|
| 552 5.2.2 | Mailbox full | The recipient's mailbox | Later, after the user frees space | Yes, until the user frees space |
| 452 4.2.2 | Mailbox full, reported as temporary | The recipient's mailbox | Yes, your server queues and retries on its own | No |
| 552 5.3.4 | Message too big for the receiving server | Your message | Not the same message | No, the address is fine |
| 5.2.3 | Message larger than that mailbox's own size limit (RFC 3463: message length exceeds administrative limit) | Your message, measured against this mailbox | Not the same message | No |
The practical difference is easy to remember. If the second part of the code is 2.2, the mailbox has no room. If it is 3.4 or 2.3, the message is too large. Shrinking or linking attachments fixes the second group and does nothing for the first. Our attachment size limits guide lists what Gmail, Outlook, Yahoo and iCloud accept.
A 452 4.2.2 is the same full mailbox reported as a soft failure. The sending server keeps the message and retries for hours or days. If the recipient frees space in time, it is delivered and no one sees a bounce. A 552 5.2.2 means the receiver chose to refuse outright.
When a bounce points at you: check your domain health and blocklists
A single 552 5.2.2 is about one mailbox. Look at your own sending if any of these are true:
- The enhanced code is 5.7.x, or the text mentions policy, reputation, spam, SPF, DKIM or DMARC.
- Bounces you thought were "mailbox full" are spread across many unrelated addresses at once, and the text on them says something other than full or over quota.
- The text names a blocklist or says the sending IP was refused.
In those cases, run your domain through a domain health check for SPF, DKIM, DMARC and MX. Then check your sending IPs and domain with the email blacklist checker. Those problems are yours to fix, and fixing them means reading the full receiver text rather than a one-word status.
More SMTP error codes
The SMTP error codes reference has one page per common code. It covers 550 5.1.1 user unknown, 550 5.7.1 and 554 5.7.1 refusals, 550 5.7.26 authentication failures and SPF PermError. Each page says whether the code is about the address, the message or the sender.
Send your first test email free
Groundmail sends transactional email (resets, sign-in codes, receipts, alerts) from mail servers and IP space we operate ourselves. Bounces carry the receiver's reply when there is one, so you can see which side has to act. The Free plan covers 3,000 emails a month, and test keys with the simulator addresses let you wire up bounce handling before a single real message goes out. Create your free account and send a test bounce to your own webhook.
Sources
Facts on this page about other companies' products, prices and policies come from these public pages. They change, so check them before you decide.