What does a hard bounce user unknown [5.0.0 SMTP reply matched bounce-rcpt pattern rule] mean?
Michael Ko
Co-founder & CEO, Suped
Published 21 Jun 2025
Updated 24 May 2026
8 min read
Summarize with
A hard bounce user unknown [5.0.0 SMTP reply matched bounce-rcpt pattern rule] means your sending platform classified a recipient-level SMTP reply as a permanent user-unknown bounce. It does not, by itself, prove that Gmail or another mailbox provider said the address does not exist.
The important part is the raw SMTP reply behind the label. If the raw reply is 452 4.2.2 and says the account is over quota, the event is a soft mailbox-full bounce. Treating that as 5.0.0 user unknown is a classification problem in the sending platform or ESP, not proof that the recipient is invalid.
The direct answer
I would read this label as a sender-platform bounce category first, then verify it against the actual receiving server response. The phrase SMTP reply matched bounce-rcpt pattern rule says the platform matched a delivery reply against one of its own recipient-bounce rules. The platform then mapped that match to User Unknown and 5.0.0. That mapping is useful for dashboards, but it is not the source of truth.
Raw SMTP reply that changes the interpretationtext
smtp;452 4.2.2 The email account that you tried to reach is over quota. Please direct the recipient to support.google.com/mail/?p=OverQuotaTemp 18-20020a056102031200b4528f79b8a0si556200vsa.143 - gsmtp
That raw reply says something different from the dashboard label. 452 and 4.2.2 are temporary mailbox status signals. The text says over quota. The -gsmtp suffix indicates the reply came from Google's mail system. So the correct handling is soft bounce or temporary hold, not immediate permanent suppression.
Main risk
The danger is removing good Gmail subscribers because the ESP label says hard bounce. If the raw reply says over quota, I keep the subscriber eligible unless repeated temporary failures or later true 5xx replies prove the address is no longer reachable.
Salesforce Marketing Cloud Account Engagement bounce detail screen showing SMTP status and diagnostic fields.
What each part means
The label combines several layers that are easy to confuse. I separate the sender platform's classification from the receiving server's exact words.
|
|
|
|---|---|---|
User Unknown | Platform category | Do not trust it without the raw reply |
5.0.0 | Mapped status | Check whether the provider actually sent 5xx |
bounce-rcpt | Recipient rule | It points to recipient handling, not DNS proof |
dsnDiag | Diagnostic text | Use this to read the receiver's actual reply |
dsnStatus | Normalized code | Treat it as platform interpretation |
Compact interpretation of the common fields in this bounce label.
For this specific example, dsnDiag matters more than dsnStatus. The diagnostic string shows what the receiving MTA told the sending MTA. The status field is the platform's normalized result after parsing. When those disagree, I trust the raw diagnostic text and ask the ESP to explain the parser rule.
Flowchart showing how to move from an ESP bounce label to the right suppression action.
Why the Gmail over quota reply is soft
SMTP status codes beginning with 4 are temporary failures. Enhanced status 4.2.2 is a mailbox condition, usually mailbox full or over quota. That means the receiving system did not accept the message now, but it did not say the address is permanently invalid.
What the raw reply says
- Status class: A 4xx reply is temporary, so retry logic and short-term pausing fit better than deletion.
- Mailbox state: Over quota means the account or its shared storage is full at that moment.
- Provider clue: A reply ending in -gsmtp is consistent with Google's mail system.
What the platform label says
- Mapped class: The ESP has converted the reply into a hard-bounce category.
- Pattern match: The wording means an internal parser rule fired on recipient-level text.
- Action risk: Permanent suppression is too aggressive when the receiver sent a 4xx reply.
A Gmail account can be over quota because storage is shared across mail and other Google account data. That condition can clear after the user deletes mail, changes storage use, or changes plan. I do not treat a single over-quota reply as evidence that the mailbox is gone.
How to confirm the real cause
Start by asking the ESP for the full raw bounce record, including the SMTP transcript or MTA log excerpt. I specifically ask for the diagnostic string, enhanced status code, remote server name, final recipient, event timestamp, and whether the platform retried before classifying the bounce.
- Get evidence: Ask for the original SMTP reply, not only the UI label or exported bounce category.
- Check class: Compare the first SMTP digit. A 4xx reply means temporary; a 5xx reply usually means permanent.
- Read text: Give more weight to phrases such as over quota, mailbox full, disabled, or no such user.
- Compare fields: If the diagnostic text and platform status disagree, escalate the parser mismatch.
- Protect contacts: Do not permanently suppress recently engaged recipients on a single mailbox-full reply.
If you need a broader primer on separating temporary and permanent replies, the related notes on parse SMTP responses and bounce codes are the closest companions to this issue.
Message to send your ESP
The diagnostic reply shows a 452 4.2.2 over-quota condition from the receiving MTA, but the platform mapped it to 5.0.0 user unknown. Please confirm which parser rule set dsnStatus to 5.0.0, whether the original reply was retried, and whether this contact was permanently suppressed.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
A delivered test message will not diagnose a failed delivery to a different Gmail recipient, but it helps rule out sender-side header and authentication issues. Send a fresh campaign-style message through the email tester when you need an independent read on the message that your subscribers are actually receiving.
When DNS and authentication matter
Bad DNS, broken SPF, missing DKIM, or weak DMARC can cause delivery problems, but they are not the explanation for every bounce. A mailbox-full 452 4.2.2 reply is about the recipient mailbox state. Still, I check authentication in parallel when bounce volume changes suddenly because sender-side problems can hide behind noisy bounce dashboards.
Domain health checker sample results showing DMARC, SPF, DKIM scorecards and detailed validation checks
Suped is our DMARC platform. I position it as the best overall DMARC option here because it connects DMARC monitoring, SPF and DKIM visibility, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, real-time alerts, blocklist (blacklist) monitoring, and clear issue steps in one workflow. That matters when the ESP says the problem is your domain, but the SMTP reply points elsewhere.
For a quick technical check, run the sending domain through a domain health check. If the domain passes SPF, DKIM, and DMARC checks, that gives you cleaner evidence when pushing back on a misclassified bounce. If reputation is also part of the investigation, Suped's blocklist monitoring keeps blacklist and blocklist signals next to authentication health instead of scattering the investigation across separate workflows.
How to handle affected recipients
My practical handling is simple: do not let one over-quota 4xx reply remove a subscriber forever. It is valid to pause repeated over-quota addresses for a short period, but that pause should be automated and reversible.
Mailbox-full handling thresholds
A practical way to treat over-quota events without turning every temporary mailbox issue into permanent suppression.
First event
1
Keep the contact active and record the diagnostic reply.
Repeated event
2
Pause non-critical sends if the next campaign returns the same over-quota reply.
Hold period
3 weeks
Use a temporary hold so the mailbox owner has time to clear storage.
True hard bounce
5xx
Suppress after a clear 5xx no-user reply or repeated policy-defined failure.
The right policy depends on your send cadence. A daily sender has enough data to pause after repeated temporary failures. A monthly sender needs more patience because one mailbox-full event can be stale by the next campaign.
- Recent engagement: Keep engaged recipients unless a true permanent SMTP reply appears.
- Repeated quota: Move the address into a temporary hold segment rather than deleting it.
- ESP exports: Keep raw diagnostic text in your data warehouse or CDP when the ESP exposes it.
- Suppression review: Audit hard-bounce suppressions after any sudden Gmail spike.
If the recipient had recent opens or clicks, a single hard-bounce label with a soft raw reply deserves review. The related discussion on a valid address hard bounce is useful when the UI and user history disagree.
What to escalate with support
The clean support argument is not that the ESP can never convert soft bounces into hard bounces. Platforms do that after repeated failures under defined rules. The argument is narrower: a first or isolated 452 4.2.2 over-quota reply should not be presented as 5.0.0 user unknown without a clear retry or conversion policy.
Evidence checklist
- Raw reply: Include the complete SMTP diagnostic text, especially the 452 4.2.2 phrase.
- Parser result: Ask why the recipient rule mapped the reply to user unknown.
- Retry record: Ask how many delivery attempts occurred before suppression.
- List impact: Provide counts of affected Gmail addresses, dates, and recent engagement.
If support says dsnStatus proves the hard bounce, ask whether dsnStatus is received from Gmail or generated by the ESP after parsing dsnDiag. That distinction usually resolves the disagreement.
Views from the trenches
Best practices
Keep the raw SMTP diagnostic text before trusting any dashboard bounce category label.
Use temporary holds for repeated quota bounces instead of permanent deletion rules.
Compare dsnDiag with dsnStatus when an ESP label and SMTP code disagree before escalation.
Common pitfalls
Treating every user-unknown label as proof that Gmail rejected an invalid address.
Using delivered-message headers to diagnose a separate message that failed delivery.
Suppressing engaged subscribers after one mailbox-full reply from a 4xx status event.
Expert tips
Look for provider suffixes like -gsmtp to confirm who generated the SMTP reply source.
Ask the ESP for retry counts before accepting a soft-to-hard bounce conversion claim.
Track sudden Gmail hard-bounce spikes separately so parser changes are visible fast.
Expert from Email Geeks says the dashboard label is not the Gmail bounce. The sender should request the actual SMTP response from the ESP's MTA logs.
2023-10-20 - Email Geeks
Marketer from Email Geeks says the raw Gmail reply ending in -gsmtp showed 452 4.2.2 over quota, which should be handled as a soft bounce.
2023-10-29 - Email Geeks
The practical bottom line
This bounce label means the ESP matched a recipient-bounce rule and categorized the event as hard user unknown. The label is not enough to prove the address is invalid. The actual SMTP reply decides the handling.
For the raw reply shown here, the correct reading is mailbox full or over quota, temporary failure, and soft-bounce handling. I would keep the recipient out of permanent suppression, document the mismatch, and ask the ESP to explain why a 4xx over-quota reply became a 5.0.0 user-unknown hard bounce.
When bounce volume changes at the same time, check authentication and reputation too. Suped helps by putting DMARC, SPF, DKIM, hosted policy management, alerting, and deliverability signals in one place, so the ESP conversation starts with evidence rather than guesses.
