Two different Gmail codes can both mean "the inbox is full," and only one of them means the address is actually dead.
452 4.2.2 The recipient's inbox is out of storage space.
552 5.2.2 The recipient's inbox is out of storage space and inactive.
A hard bounce is any 5xx code: the address or the domain rejected the message for good, so remove it now.
A soft bounce is a 4xx code: the problem is temporary, and most sending platforms retry it on their own.
A block is neither one. The address is fine. Something on your side, usually authentication, tripped a filter, and purging the contact fixes nothing.
Which one did you actually get?
Your platform's dashboard reduces every failure to one word: bounced. The SMTP response behind that word carries two pieces of information the dashboard usually throws away, the class digit (4 or 5) and the enhanced status code (the three numbers after it, like 5.1.1 or 4.2.2).
Read those two together before you decide what to do.
What you see | What it means | Read this |
|---|---|---|
5xx, address or domain rejected | Permanent. Remove the address. | Hard bounce codes |
5xx, mailbox full and inactive (552) | Permanent, even though it started as "full." | Hard bounce codes |
4xx, mailbox full (452) | Temporary. Leave it queued. | Soft bounce codes |
4xx, rate limited, throttled, or greylisted | Temporary. It usually clears on its own. | Soft bounce codes |
5xx or 4xx with policy, filter, or block wording, address otherwise valid | Not a bounce. Fix the sender side. | Why a block is not a bounce |
What the receiving server actually sent back
Every bounce you get is built from the same three fields, whatever your platform's summary screen shows you instead: the status code, the enhanced code, and a line of free text the receiving server wrote itself.
The status code is the class digit. The enhanced code is the part that actually distinguishes a dead address from a full inbox from a policy block.
The free text is written by whichever mail system rejected the message, and it is worth reading in full at least once, because a platform's own bounce label is a summary of that text, not a replacement for it.
Here is every code covered in this piece, side by side, as a quick lookup:
Code | What it means | Outcome |
|---|---|---|
| Mailbox does not exist | Hard, remove now |
| Domain has no mail server | Hard, remove now |
| Mailbox full and inactive | Hard, remove now |
| Mailbox full, still active | Soft, leave queued |
| Unauthenticated, rate limited | Soft, fix authentication |
| Domain fails a high volume sender's authentication bar | Block, fix DNS |
What a hard bounce code actually means
Invalid or nonexistent address (550 5.1.1)
What it means: the mailbox portion of the address, everything to the left of the at sign, does not exist on the receiving server.
Confirm it: the exact text 550 5.1.1 or a close variant appears in the bounce, and it names the address, not the domain.
Fix it: remove the address. There is no configuration change on your end that revives a mailbox that was never there.
Takes effect: immediately. There is nothing to wait on.
The domain itself refuses mail (550 5.1.2)
What it means: the domain after the at sign has no mail server willing to accept the message, which is a different failure from a bad mailbox name.
Confirm it: a mail exchange lookup against the domain returns nothing. Tested against a domain built specifically not to exist, that lookup returned no mail server in 0.02 seconds. A real domain with mail service, checked the same way, answered in under 0.01 seconds with a list of mail servers ranked by priority.
Fix it: remove the address. A domain with no mail exchange records is not a temporary outage.
Takes effect: immediately.
A full inbox that has gone inactive (552 5.2.2)
What it means: the mailbox filled up and nobody has emptied it since, so the receiving server stopped treating the account as active.
Confirm it: the code reads552, not 452. That single digit is the entire difference between temporary and permanent for an identical symptom: a full inbox, a mix up senders keep asking about in the Gmail Community itself.
Fix it: remove the address once you see 552. Retrying does not help, because the receiving server has already decided the account is not coming back.
Takes effect: immediately, and it will not revert on its own the way a 452 eventually clears.
What a soft bounce code actually means
A full inbox, still active (452 4.2.2)
What it means: the mailbox exists and is being used; it is over its storage limit at this exact moment.
Confirm it: the code reads452, not 552.
Fix it: nothing on your end. Leave the address in the send. Most platforms queue a 452 and retry automatically for a set number of days.
Takes effect: as soon as the recipient frees up space or their provider expands their quota, which is entirely out of your control and can take anywhere from hours to weeks.
Rate limited or throttled
What it means: the receiving server accepted your connection but is telling you to slow down, either because you sent unauthenticated mail or because you are sending faster than your sending reputation supports.
Confirm it: a 4xx code paired with wording about rate, volume, or authentication, not about the mailbox itself. Gmail's own reference gives the unauthenticated case as This email has been rate limited because it is unauthenticated.
Fix it: authenticate with SPF or DKIM if you have not already, and slow your sending volume if the domain is new. A related deferral, 421, gets its own full breakdown in a separate reference if the code you are looking at is a bare 421 rather than a 4.2.2 or 4.7.x variant.
Takes effect: the next connection attempt, once authentication is in place.
Greylisted or temporarily deferred
What it means: some receiving servers reject a first attempt from an unfamiliar sending server on purpose, specifically to see whether a real mail server retries, since spam senders often do not.
Confirm it: a 4xx code on the first attempt to a given recipient, followed by a successful delivery on a later attempt with no change on your side at all.
Fix it: nothing. A real sending server is supposed to retry, and greylisting exists to filter out the ones that do not.
Takes effect: on the next retry, usually within minutes to a few hours.
Why a block is not a bounce at all
A block looks identical to a bounce in most dashboards, and it is the one outcome most likely to get a good address deleted for no reason. The address exists. The mailbox is not full. Nothing about the recipient is wrong.
What tripped the rejection is something about the message or the sending domain that the receiving server's policy does not allow through, and Gmail's own wording states this plainly: the account or domain you are sending to, or from, has a policy that prohibits the message you sent.
Several distinct policy checks sit behind that one generic notice, and a full breakdown of which one you actually hit lives in a separate decoder for anyone staring at Gmail's "message blocked" wrapper instead of a raw SMTP code.
The RFC that defines these enhanced codes draws the same line directly: a delivery that is not authorized is not the same failure as a mailbox that does not exist. Its wording for that category is short.
The sender is not authorized to send to the destination.
Treat a block the way you would treat a locked door, not a demolished building. Fix whatever the policy is checking for. Do not touch the contact record.
Why authentication failures now show up as bounces
A growing share of what lands in your bounce report is not about the recipient's mailbox at all. It is a policy rejection wearing a bounce shaped notice, and two changes from the major providers are why.
Microsoft's 550 5.7.515
Since Microsoft tightened its rules for high volume senders, a domain sending 5,000 or more messages a day to Outlook.com and related consumer addresses under one From domain gets rejected outright unless all three of the following are true:
SPF is published for the sending domain, and it passes.
DKIM is published for the sending domain, and it passes.
DMARC is published for the sending domain, with alignment.
Microsoft's own support text for the resulting code is direct: access denied, sending domain does not meet the required authentication level. That is not a mailbox problem.
It is a missing DNS record problem, and no amount of list cleaning touches it.
Gmail's requirement to authenticate
Gmail pairs the same idea with a softer first step. Unauthenticated mail gets rate limited, at code 421 4.7.26, before it gets blocked outright.
A domain that never fixes authentication eventually crosses from a temporary deferral into the same 550 5.7.1 or 550 5.7.26 territory as an outright policy block, which is exactly the drift a five cause breakdown of 550 5.7.1 walks through if that is the specific code sitting in front of you.
The threshold that is actually enforced
A good bounce rate is not a round benchmark number. Amazon's own SES documentation states an enforced one instead: an account crosses into review at a 5 percent bounce rate and may have its ability to send paused at 10 percent, dated to the version of its enforcement FAQ current as of this writing.
What counts toward that number matters more than the number itself. Mailbox full bounces and bounces caused by a blocked sending IP are excluded.
Only permanent, hard failures to domains you have not verified count against you.
That single exclusion is the reason two senders with identical dashboards, one showing mostly 452s and one showing mostly 550 5.1.1s, are not in the same position at all, even if their platform reports the same overall bounce percentage.
How to confirm you got it right
[ ] The code changed, not only the word in your dashboard. A 452 clearing into a successful delivery is confirmation. A 452 changing to "bounced (hard)" in your platform's summary, with no code shown, is not.
[ ] For an authentication fix, the next send to the same recipient carries the code, not the platform's cached label from the last attempt.
[ ] Your domain's own outbound reputation, visible in a free postmaster dashboard where the provider offers one, is trending down and not up over the days after the fix.
[ ] You have not added back a removed hard bounce address without independent confirmation the mailbox is active again, since a hard bounce contact staying flagged after a genuine fix is a known, separate problem on its own.
When to stop guessing and escalate
If a domain keeps producing 550 5.7.1 or 550 5.7.26 after SPF, DKIM, and DMARC all pass in a header check, the cause has moved past list hygiene or authentication setup.
That is a reputation or policy dispute with the receiving provider, not a code to read your way out of.
Escalate to that provider directly rather than repeating the same DNS check a fourth time.
What already handles the authentication side of these bounces
Two of the causes above, Microsoft's 550 5.7.515 and Gmail's 421 4.7.26, both trace back to the same missing piece: SPF, DKIM, and DMARC not published, or not aligned, for the sending domain.
TrueEmailer configures all three together at setup for every domain it sends from, so a domain sending through it starts authenticated instead of picking up that DNS work later, under pressure from a rejection notice already sitting in the outbox.
That setup does not reach every cause in this piece. A full inbox, active or inactive, is decided by the recipient's own provider, not by anything in the sending domain's DNS records.
An address that does not exist, or a domain with no mail server at all, stays that way regardless of authentication status. Greylisting is a first attempt check that a properly authenticated sender still meets and clears on retry.
And the threshold covered above counts hard failures to unverified addresses, a list hygiene question that authentication alone does not settle.
Related error codes
The class digit and enhanced code system here sits inside a wider reference covering every SMTP status from a plain 250 acknowledgment through the full 5xx range.
If your code is not one of the ones broken down above, the complete decoder is the place to check next.
A bare 421 with no enhanced code attached, separate from the 4.7.26 variant covered here, gets its own breakdown of who sent the deferral and whether it retries.
Hard bounce vs soft bounce FAQs
Is mailbox full a hard bounce or a soft bounce?
Both exist. Gmail returns 452 4.2.2 for a full inbox that is still active, which is temporary. It returns 552 5.2.2 once that inbox has been full and unused long enough to be marked inactive, which is permanent.
Read the three digit code, not only the words "mailbox full."
How many soft bounces before it becomes a hard bounce?
Most sending platforms convert a repeatedly soft bouncing address to hard bounced status after somewhere around a week to two weeks of consecutive failures, but the exact count and the time window are set by your own platform, not by the SMTP code itself.
Check your platform's own bounce or suppression settings for its specific number rather than assuming one figure applies everywhere.
Is a blocked email the same as a bounce?
No. A block means the address is valid and the mailbox is fine, but a policy, filter, or missing authentication record stopped the message.
Removing the contact fixes nothing, since the problem is on the sending side.
Does a soft bounce mean the email was eventually delivered?
Not automatically. A soft bounce means the receiving server accepted responsibility for retrying, not that a later attempt succeeded.
Confirm delivery from a successful send record, not from the absence of a further bounce notice.
Should I remove soft bounces from my list?
A single 452 or a single greylist deferral is normal and often clears within hours, so leave it after the first one.
Watch for the same address soft bouncing on every send over several weeks before treating it as a real problem, and check whether your platform has already converted it to hard bounced status on its own.
What counts as a good bounce rate?
Lower than whatever number is actually enforced against you, which is not the same as a round benchmark figure.
Amazon's SES enforcement documentation sets 5 percent as the point an account is reviewed and 10 percent as the point sending may be paused, and that count excludes mailbox full and blocked IP bounces entirely.
A rate under 2 percent, made up mostly of addresses that are actually dead rather than temporary states, is a reasonable target regardless of which platform enforces which number.
What actually changes once you know the code
The word your dashboard shows you, hard or soft, is a summary written for a screen with limited space. The three digit code underneath it is what a receiving server actually decided, and it is the only part that tells you whether to delete an address, wait, or fix something on your own domain.
Read that part first from now on.
Error strings and fixes verified 25 September 2026