What does a hard bounce user unknown [5.0.0 SMTP reply matched bounce-rcpt pattern rule] mean?
Updated on 3 Oct 2026: We clarified how to read 452 4.2.2 over-quota replies, DSN retry outcomes, and ESP suppression decisions.
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 receiving system 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, that attempt encountered a temporary mailbox-full condition. The message can still fail if retries expire, but the reply does not prove the recipient is invalid. Mapping it to 5.0.0 user unknown calls for an explanation from the sending platform or ESP.
The direct answer
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. The rule name alone does not confirm that rejection occurred at the SMTP RCPT TO command.
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 is a transient SMTP reply, while 4.2.2 is the enhanced status for a full mailbox. Google defines this combination as the recipient inbox being out of storage space, and gsmtp identifies a Google-generated SMTP error. Handle the mailbox condition as temporary and check the retry outcome before changing suppression status.
The mapped 5.0.0 is a generic permanent enhanced status. A bad destination mailbox address has the more specific enhanced status 5.1.1. The words User Unknown therefore come from the platform category, not from any specificity in 5.0.0.
Main risk
The danger is removing good Gmail subscribers because the ESP label says hard bounce. If the raw reply says over quota, review retry history and keep the subscriber out of invalid-address suppression unless a later reply verifies that the address does not exist.
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. Separate the sender platform's classification from the receiving server's exact words.
|
|
|
|---|---|---|
User Unknown | Platform category | Compare it with the diagnostic reply |
5.0.0 | Generic mapped status | Check whether the receiver actually sent a 5xx code |
bounce-rcpt | Recipient rule | Do not infer the SMTP command from this name alone |
dsnDiag | Diagnostic text | Check the reply and which MTA issued it |
dsnStatus | Normalized code | Compare it with the diagnostic and DSN action |
Compact interpretation of the common fields in this bounce label.
For this specific example, dsnDiag contains a 452 4.2.2 reply while dsnStatus contains the platform's 5.0.0 result. In a full Delivery Status Notification (DSN), the Remote-MTA field helps identify whether the diagnostic came from the receiving server or the reporting MTA. When these fields disagree, preserve the complete record and ask the ESP to explain the parser rule.
Flowchart showing how to move from an ESP bounce label to the right suppression action.
How Account Engagement handles bounce records
Account Engagement marks a prospect Undeliverable after one hard bounce or five soft bounces. A 452 4.2.2 reply mapped as a hard bounce can therefore suppress the prospect sooner than correct soft-bounce handling would.
|
|
|
|---|---|---|
One hard bounce | Prospect becomes Undeliverable | Verify the raw reply before resetting |
One soft bounce | Soft-bounce count increases | Keep the diagnostic and watch for repeats |
Five soft bounces | Prospect becomes Undeliverable | Confirm whether the temporary condition persists |
Account Engagement consequences for the two possible classifications.
After confirming a misclassification or resolving the mailbox issue, an Account Engagement administrator or Marketing user can reset the detected hard or soft bounce in the prospect's Mailability section. Preserve the original SMTP reply before resetting it. If the next send bounces again, Account Engagement can return the prospect to Undeliverable.
Check both systems after a reset
In connected Salesforce records, Email Bounce Reason and Email Bounce Date can remain as historical values after the Account Engagement Hard Bounce field is reset. Compare the current mailability state with those retained fields. If Salesforce still treats the record as undeliverable, review those fields as part of the coordinated reset.
Why the Gmail over quota reply is soft
SMTP status codes beginning with 4 are transient failures. Enhanced status 4.2.2 means the mailbox is full. The receiving system did not accept the message at that attempt, but it did not say the address was permanently invalid.
What the raw reply says
- Treat the 4xx status as temporary and allow retry or short-term hold logic.
- Read over quota as a mailbox storage condition at that moment.
- Use the gsmtp suffix to identify Google's mail system as the reply source.
What the platform label says
- The ESP converted the reply into a hard-bounce category.
- An internal parser rule matched recipient-level text in the response.
- Permanent invalid-address suppression needs evidence beyond this 4xx reply.
A Gmail account can be over quota because its available storage is exhausted. That condition can clear after the user removes stored data or adds storage. Do not treat a single over-quota reply as evidence that the mailbox is gone.
A temporary reply can become a final delivery failure
A 4xx SMTP reply describes one delivery attempt. The sending server can retry, then stop when its retry window expires. A final DSN can say Action: failed while retaining a 4.2.2 status. That means this message was not delivered after retries; it does not turn the mailbox-full condition into user unknown.
|
|
|
|---|---|---|
Action: delayed; Status: 4.2.2 | Delivery is still pending | Wait for retries; do not suppress the address |
Action: failed; Status: 4.2.2 | This message was not delivered | Review retry history and use a reversible hold if needed |
Verified 5.1.1 no-user reply | Address is invalid | Suppress the address after confirming the diagnostic |
Read the DSN action and status together before deciding what to suppress.
Ask for the DSN's Action, Status, Diagnostic-Code, Remote-MTA and Last-Attempt-Date fields, plus retry logs. The SMTP transcript identifies the command that received the reply; a bounce-rcpt rule name does not.
How to confirm the real cause
Ask the ESP for the full raw bounce record, including the SMTP transcript or MTA log excerpt. Request the diagnostic string, enhanced status code, remote server name, final recipient, event timestamp, DSN action, and retry history.
- Get the original SMTP reply, not only the UI label or exported bounce category.
- Compare the first SMTP digit. A 4xx reply is temporary; a 5xx reply is permanent for that delivery request, but does not always mean an invalid address.
- Give more weight to precise phrases such as over quota, mailbox full, disabled, or no such user.
- Escalate the parser mismatch when the diagnostic text and platform status disagree.
- Avoid permanent invalid-address suppression after one mailbox-full reply.
For 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, what the final DSN action was, and whether this contact was permanently suppressed.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
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 subscribers are receiving.
When DNS and authentication matter
A mailbox-full 452 4.2.2 reply describes the recipient mailbox state. SPF, DKIM, and DMARC do not cause that response. Check authentication separately when other bounce types rise or several providers begin rejecting mail.
Domain health checker sample results showing DMARC, SPF, DKIM scorecards and detailed validation checks
Suped is our DMARC reporting and email authentication platform. Its DMARC monitoring workflow shows SPF, DKIM, and DMARC results while the bounce investigation stays focused on the receiving server's reply. This is useful when an ESP blames the sending domain but the raw reply points to recipient storage.
Run the sending domain through a domain health check when the evidence points to sender authentication or DNS. A passing result does not override a 452 4.2.2 reply, but it can rule out a separate sender-side fault. If reputation is also in scope, Suped's blocklist monitoring keeps blacklist and blocklist signals beside authentication results.
How to handle affected recipients
Do not let one over-quota 4xx reply remove a subscriber forever. A temporary pause can be appropriate after repeated over-quota replies, but it should be automated, documented, 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 soft
Record the diagnostic and keep the failure in the soft-bounce path.
Account Engagement limit
5 soft
Account Engagement marks a prospect Undeliverable after five soft bounces.
Policy review
Policy-based
Use send cadence and repeated raw replies to set any temporary hold.
Verified invalid address
5.1.1
Suppress after a clear no-user reply or another verified invalid-address response.
Account Engagement's five-soft-bounce limit is platform behavior. Any earlier temporary-hold policy should account for send cadence. A daily sender sees repeated evidence quickly, while a monthly sender has less current data at the next campaign.
- Keep recently engaged recipients eligible unless a verified invalid-address reply appears.
- Move addresses with repeated quota replies into a temporary hold segment instead of deleting them.
- Retain raw diagnostic text in your data warehouse or CDP when the ESP exposes it.
- Audit hard-bounce suppressions after any sudden Gmail spike.
If the recipient had recent clicks or replies, 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 narrower than claiming an ESP can never convert soft bounces into hard bounces. Platforms can do that after repeated failures under a defined policy. A first or isolated 452 4.2.2 over-quota reply should not be presented as 5.0.0 user unknown without a documented retry or conversion rule.
Evidence checklist
- Include the complete SMTP diagnostic text, especially the 452 4.2.2 phrase.
- Ask why the recipient parser rule mapped the reply to user unknown.
- Ask how many delivery attempts occurred before suppression.
- Provide counts of affected Gmail addresses, dates, and recent engagement.
If support says dsnStatus proves the hard bounce, ask whether dsnStatus came from Gmail or was 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 view
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 view
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
What to do with this bounce label
The ESP matched a recipient-bounce rule and categorized the event as hard user unknown. For the raw reply shown here, the mailbox was over quota at that attempt. Check the final DSN action and retries, keep the address out of permanent invalid-address suppression, and ask the ESP why a 4xx reply became a 5.0.0 user-unknown label.
