An email bounce back is the automated reply you get when a message cannot reach the recipient, and the text inside it tells you exactly why, if you know how to read it. Most of that text is not prose written for humans. It is a standardized code, buried in a line of technical detail, that says in three numbers whether the problem is permanent or temporary.
This page decodes that text: the SMTP reply code, the enhanced status code underneath it, a table of the bounce messages a cold email sender actually sees, and what to do with each one. For the formula behind bounce rate and the safe thresholds for cold outreach, see our bounce rate guide. For the bigger picture of deliverability, see our cold email deliverability guide.
What is an email bounce back message in cold email?
An email bounce back message is an automated reply from a mail server explaining why a message you sent could not be delivered. It is also called a non-delivery report, delivery status notification, or NDR, depending on which mail system generated it.
A bounce back typically contains four parts: a line of plain-English explanation, the address that failed, an SMTP reply code, and an enhanced status code. The plain English is written for a human. The two codes are written for software, and they are the part worth learning to read, because the wording around them varies by provider but the codes do not.
What is the SMTP code in a cold email bounce back, and how is it different from the status code?
The SMTP reply code is the three-digit number a receiving server sends during the actual delivery attempt, such as 550 or 421. It is a general-purpose protocol response, not specific to email bounces, and on its own it is too blunt to say much.
The enhanced status code is the more useful one: a class.subject.detail code like 5.1.1 or 4.2.2, sitting right next to the SMTP code in the same bounce. RFC 3463 defines this format specifically for delivery status reporting, because the plain SMTP code space ran out of room to be precise.
The registry for these codes, RFC 5248, confirms they are centrally standardized rather than invented per provider. A 5.1.1 means the same thing whether it came from Gmail, Outlook, or a small business host.
How do you read an enhanced status code in a cold email bounce back?
Read the first number, then the second, then treat the third as detail. The first number alone tells you whether to stop sending or try again.
| Position | Meaning |
|---|---|
| First digit: 4 | Persistent transient failure. The message is valid; something temporary blocked it. Retrying later may work. |
| First digit: 5 | Permanent failure. Resending the same message will not help. |
| Second digit: 1 | Addressing. The problem is the recipient's address. |
| Second digit: 2 | Mailbox. The problem is the recipient's mailbox specifically. |
| Second digit: 3 | Mail system. The problem is the destination server. |
| Second digit: 7 | Security or policy. The message was blocked by a filter or authentication rule. |
A code like 5.1.1 reads as permanent, addressing problem: the address does not exist. A code like 4.2.2 reads as temporary, mailbox problem: the recipient's inbox is full right now.
- Read the first digit. 4 means retry later, 5 means stop and remove the address.
- Read the second digit. It tells you where the problem sits: the address, the mailbox, the server, or a policy filter.
- Use the third digit only for detail. It rarely changes what you do in cold email.
What do common bounce back messages mean and what should you do in cold email?
Most cold email bounces fall into a short list of recurring codes, and each one has a specific, correct response.
| Code | What it means | What to do in cold email |
|---|---|---|
| 5.1.1 | Mailbox does not exist at this address | Remove the address permanently. Do not retry. |
| 5.1.2 | The domain itself does not exist | Remove the address. Check for a typo in the domain. |
| 5.2.1 | Mailbox disabled or no longer accepting mail | Remove the address permanently. |
| 4.2.2 | Recipient's mailbox is full | Leave it in the sequence. Retry later; this often clears on its own. |
| 4.3.0 / 4.4.x | Receiving server temporarily unavailable or timed out | Retry later. Not the address's fault. |
| 4.7.0 | Receiver is rate-limiting or greylisting your sending IP or domain | Slow down sends to that domain; a new sending domain sees this more often during warmup. |
| 5.7.1 | Message refused by a policy or content filter | Check the message content and links; a repeated 5.7.1 from one provider suggests a filtering rule, not a one-off. |
| 5.7.26 | Message failed DMARC, SPF, or DKIM checks | Fix authentication on the sending domain before sending more. See our SPF, DKIM and DMARC overview. |
These codes come from Google Workspace's own SMTP error reference, which lists the exact pairing of SMTP code, enhanced status code, and the text Gmail sends for each. The same code numbers appear in bounces from other major providers. They all follow the same RFC 3463 structure rather than a Google-specific one.
When does a soft bounce become a hard bounce in cold email?
A soft bounce becomes a hard bounce in practice when the same temporary failure repeats across several send attempts with no sign of clearing. One full mailbox is a soft bounce. A mailbox that stays full for weeks behaves like a permanent failure even though the enhanced status code never changes from 4.x.x to 5.x.x.
The code itself will not tell you this has happened, since nothing in RFC 3463 escalates a 4.x.x into a 5.x.x automatically. It is a judgment call for whoever watches the list. If the same address keeps soft bouncing with no delivery in between, treat it as dead, even though the message still reads as temporary.
Our bounce rate guide covers how hard and soft bounces are classified and counted toward your rate. This page is about reading the message that triggers the classification.
Gmail's bounce notices arrive from "Mail Delivery Subsystem": our Mail Delivery Subsystem guide decodes each one. Temporary 4xx delays are covered in greylisting.
What does a Gmail or Google Workspace bounce back look like for cold email?
A Gmail or Google Workspace bounce arrives as an email from "Mail Delivery Subsystem," with the SMTP code, the enhanced status code, and a short explanation on one line. Google's own troubleshooting guide walks through the common consumer-facing cases: a non-existent address, a message flagged as spam, a sender rate limit, a full inbox, or an invalid HELO/EHLO value from the sending server.
A typical line reads something close to 550 5.1.1 The email account that you tried to reach does not exist, or 452 4.2.2 The recipient's inbox is out of storage space. The enhanced status code is the authoritative part.
Google also appends internal tags to every error. gsmtp appears on every one, and gcdp appears specifically when a Workspace administrator's custom rule caused the rejection. That second tag is useful context if the same bounce text appears across many recipients at one company.
What does a Microsoft or Outlook bounce back look like for cold email?
A Microsoft 365 or Exchange bounce, called an NDR, splits into a plain-English user section and a technical diagnostic section containing the enhanced status code. Microsoft's own documentation on NDRs confirms the codes follow the same RFC 3463 class-subject-detail structure used by every other major provider. A leading 4 is temporary and a leading 5 is permanent. The second digit narrows it down further: addressing, the mailbox, the mail system, or security and policy.
Microsoft's diagnostic section also names the generating server and, when relevant, a remote server that rejected the message mid-transmission. For cold email purposes, the enhanced status code in that section is the only part worth reading closely; the rest is routing detail aimed at mail administrators, not senders.
How do you tell a real bounce back from a fake one in cold email?
A real bounce back always comes from your own mail system or the recipient's, carries a matching enhanced status code, and references the actual message you sent. A fake one, sometimes used in phishing, imitates the format but usually lacks a real status code or references a message you never sent.
A few checks separate a real bounce from a fake one:
- Look for a genuine code. A real bounce almost always carries a
class.subject.detailcode somewhere in the body. - Check it references a message you actually sent. A fake one often references nothing specific.
- Treat any link asking you to "verify your account" as a red flag. A real bounce never asks you to click anything.
For verifying addresses before you ever send to them, see our cold email list quality guide.
Pipefire reads the actual bounce text in layers rather than trusting one signal.
- It checks for the standard machine-readable delivery status data first.
- It then looks for an enhanced status code like 5.1.1 or 4.2.2 in the body.
- It falls back to recognizing sender patterns like "mailer-daemon" only when neither of the first two is present.
The leading digit of the status code decides hard or soft regardless of the surrounding wording. A hard bounce or complaint suppresses the address for good across every campaign, and a soft bounce is left to retry rather than removed. Our health checks feature covers the fuller set of checks that run on every sending domain and mailbox.
Email bounce back cold email FAQ
What is a soft bounce in cold email?
A soft bounce is a temporary delivery failure, carrying an enhanced status code that starts with 4, such as a full mailbox or a server that is briefly unavailable. The same message can succeed on a later attempt without any changes.
What is a hard bounce in cold email?
A hard bounce is a permanent delivery failure, carrying an enhanced status code that starts with 5, such as an address or domain that does not exist. Retrying will not help; the address should be removed from your sending list.
Soft bounce vs hard bounce in cold email, what actually decides which one you got?
The leading digit of the enhanced status code in the bounce message decides it: 4 means temporary, 5 means permanent. The plain-English wording around the code can be inconsistent across providers, but the code itself is standardized by RFC 3463.
What does a cold email bounce back look like for a dead address?
A typical example reads close to 550 5.1.1 The email account that you tried to reach does not exist, combining the SMTP code 550, the enhanced status code 5.1.1, and a short explanation. The 5.1.1 code alone is enough to confirm it as a permanent addressing failure.
Why did my cold email bounce back with no clear error code?
Some smaller mail servers send a bounce in plain prose without a standard enhanced status code, especially older or misconfigured systems. When no code is present, look for wording like "does not exist" or "mailbox unavailable" for a permanent failure, versus "full" or "try again later" for a temporary one.