Email Bounce Back Codes: What They Mean and What to Do
Summarize with AI
An email bounce back is not one problem. It is a rejection report that tells you whether to retry later, remove an address, correct the message, or repair your sending setup. Start with the numeric code, then read the provider's text. A 4xx response usually means wait and retry. A 5xx response means another attempt in the same form is unlikely to work. Our view is simple: routing every bounce to list cleanup is lazy diagnosis. The code should decide the owner and the next action.
How to Read an Email Bounce Back Code
A bounce notice may show a three-digit SMTP reply such as 421, 450, or 550, a dotted status such as 4.2.2 or 5.7.26, and a sentence from the receiving provider. Keep all three. The short code gives the broad outcome, the dotted code narrows the category, and the text often names the exact failure.
The RFC 3463 enhanced status code standard defines the dotted format as class.subject.detail. The first number is the class:
- 2.x.x means success. It can appear in a delivery notification, but it is not a failure.
- 4.x.x means persistent temporary failure. The message was valid, but a temporary condition delayed or stopped delivery. A later attempt may succeed.
- 5.x.x means permanent failure. Resending the same message to the same destination is unlikely to work. Something must change.
The second number identifies the area. Address problems use x.1.x, mailbox problems use x.2.x, destination mail-system problems use x.3.x, and routing problems use x.4.x. Delivery-process failures use x.5.x, content failures use x.6.x, and security or policy failures use x.7.x.
That structure turns a bounce from a vague warning into a routing instruction. A 5.1.1 belongs with the contact-data owner. A 4.4.2 belongs with mail operations. A 5.7.26 belongs with whoever controls authentication.
Common Rejection Codes and the Correct Next Action
Google's official Gmail SMTP errors and codes reference shows why the complete reply matters. Gmail maps specific conditions to codes and adds explanatory text, including whether a message was delayed, rate limited, blocked, malformed, or unauthenticated.
Use this table as an action router, not a complete catalog:
| Code | What it usually means | First action | Owner |
|---|---|---|---|
| 4.2.1 | Recipient is receiving mail too quickly, or a temporary relay limit was reached | Leave in the retry queue and monitor recurrence | Mail operations |
| 4.2.2 | Recipient inbox is out of storage | Allow limited retries, then pause that recipient if it persists | Recipient condition |
| 4.3.0 | Receiving system temporarily rejected the message | Retry later and check whether one provider is affected | Mail operations |
| 4.4.2 or 4.4.5 | Connection timeout, busy server, or congestion | Retry with delay; inspect routing if it repeats | Mail operations |
| 4.7.x | Temporary policy, reputation, authentication, DNS, rate, or TLS restriction | Stop increasing volume and investigate the exact text | Sending setup owner |
| 5.1.1 | Destination mailbox does not exist | Suppress the address immediately | Contact-data owner |
| 5.1.2 or 5.1.3 | Recipient domain cannot be found, or address syntax is invalid | Correct only from a verified source, otherwise suppress | Contact-data owner |
| 5.2.1 | Recipient account is inactive or disabled | Suppress the address | Contact-data owner |
| 5.3.4 | Message, headers, or attachments exceed a limit | Reduce the message and resend | Message owner |
| 5.4.5 or 5.4.6 | Sending limit or routing loop | Pause the affected stream and fix limits or routing | Mail administrator |
| 5.6.0 | Message is malformed | Correct message construction before resending | Sending platform owner |
| 5.7.x | Policy, authentication, reputation, relay, TLS, or security rejection | Diagnose the named control before another send | Sending setup owner |
A code beginning with 4 is not permission to retry forever. Your sending platform should use delayed retries and a defined stop condition. If a temporary error persists, pause the recipient or stream and investigate instead of creating a loop that keeps producing the same rejection.
A code beginning with 5 is not always bad contact data. Only the address and mailbox categories point directly toward suppression. A message-size failure needs a smaller message. A policy failure needs a policy or sending correction. Deleting a valid recipient because your DKIM failed leaves the real problem untouched.
Decode the Codes That Cause the Most Wrong Fixes
The following codes require different fixes based on the condition each response names.
5.1.1 means the mailbox is bad
The RFC defines 5.1.1 as a bad destination mailbox address. Gmail describes it as an account that does not exist. Suppress the exact address. If a visible typo suggests a correction, verify the corrected address through an authoritative source before using it. Do not guess a new mailbox pattern and send again.
This is the clearest list-quality rejection, so it should feed your suppression record and data-source review. Track which source supplied the address. The point is to remove one invalid contact and prevent that source from repeatedly contaminating future campaigns.
4.2.2 means wait, within limits
RFC 3463 defines x.2.2 as a full mailbox and treats it as temporary. Gmail's 452 4.2.2 message says the recipient is out of storage. A later retry can work if the recipient clears space, but your team does not control that event.
Keep this recipient separate from permanent suppressions. Allow your normal temporary-failure retry policy to work, then stop after the policy expires. Repeatedly resending outside that policy adds traffic without fixing the recipient's storage.
5.7.x does not mean one thing
The x.7.x family covers security and policy. That is a category, not a diagnosis. Gmail uses detailed 5.7.x responses for failed SPF or DKIM, missing or insufficient DMARC policy, missing reverse DNS, TLS requirements, suspicious content, low reputation, relay denial, and unsolicited-mail patterns.
Read the sentence after the code. If it names SPF, DKIM, DMARC, PTR, TLS, or alignment, verify that control. If it names reputation, rate, unsolicited mail, or suspicious links, pause expansion and inspect sending behavior, audience relevance, and content. Re-verifying the recipient list alone cannot repair a broken authentication record or a policy block.
Route Every Bounce to One of Four Owners
A reliable bounce process separates ownership before it starts making changes.
Contact-data owner
Send 5.1.1, 5.1.2, 5.1.3, and inactive-mailbox outcomes here. The action is correction from a trusted source or permanent suppression. Feed the result back to the original data source and any CRM record so another campaign cannot re-import the same failed address.
Mail operations owner
Send temporary connection, routing, congestion, and receiving-system failures here. This owner manages delayed retries, provider-level monitoring, and stop conditions. The job is to distinguish an isolated destination problem from a pattern affecting one sending domain, route, or receiving provider.
Message owner
Send message-size, malformed-message, unsupported-content, and suspicious-link findings here. The owner should make the smallest change that addresses the rejection, then test again. Replacing the list or rotating domains does not fix an oversized attachment or broken header.
Sending setup owner
Send authentication, reverse DNS, TLS, relay, reputation, and rate restrictions here. Check the exact domain and sending path used for the rejected message. Our outbound system treats contact data, mailbox configuration, sending controls, and reply handling as connected parts because a clean handoff prevents the wrong team from applying the wrong fix.
Build the Bounce Log Into a Control System
For every campaign, preserve the raw response before your sending tool collapses it into "hard" or "soft." Record the owner, action, retry status, suppression status, and resolution. Then group results by code, receiving provider, sending domain, campaign, and data source.
The contact record should retain a permanent suppression. The sending owner should see repeated authentication failures. The campaign owner should know when one message version causes content rejections. Clients should keep those records with the infrastructure, rather than losing the history when a vendor changes.
If your immediate problem is a broad increase rather than an unfamiliar code, use our guide on how to fix a high bounce rate. For provider placement questions after acceptance, an inbox placement test addresses a different decision. A bounce says the receiving system rejected or could not complete delivery. Placement asks where accepted mail landed.
Ready to Turn Bounce Codes Into Clear Actions?
We can review your ICP, campaign fit, data flow, and sending constraints, then show where ownership and routing need to improve. Book your free ICP and campaign-fit discovery call →
Frequently Asked Questions
A strong positive reply rate for B2B cold email is 1.5–3%. Top-performing campaigns with tight targeting and personalized copy can hit 4–5%. If you're below 1%, it usually signals a deliverability or messaging problem, not a volume problem.
The safe range is 30–50 emails per inbox per day for warmed inboxes. That's why outbound systems use multiple inboxes (we use 80) to reach 40,000+ monthly sends while keeping each inbox well within safe limits. Sending more than 50/day from a single inbox risks spam folder placement.
Yes. The CAN-SPAM Act permits unsolicited commercial email as long as you include a physical address, an unsubscribe mechanism, accurate headers, and non-deceptive subject lines. Unlike GDPR in Europe, the US does not require prior opt-in consent for B2B cold outreach.
Domain warm-up typically takes 2–3 weeks. During this period, sending volume gradually increases while the email warm-up tool generates positive engagement signals (opens, replies) to build sender reputation. Skipping or rushing warm-up is the most common cause of deliverability problems.
Cold email is targeted, relevant outreach to a specific person based on their role, industry, or company, with a clear business reason. Spam is untargeted mass messaging with no personalization or relevance. The distinction matters legally (CAN-SPAM compliance) and practically (deliverability depends on relevance signals).
Dimitar Petkov
Co-Founder of LeadHaste. Builds outbound systems that compound. 4x founder, Smartlead Certified Partner, Clay Solutions Partner.