An email bounced back because the receiving server refused it or couldn't deliver it, and the code in the bounce says which. Codes starting with 5 are permanent, codes starting with 4 are temporary, and the second part (5.1.1, 5.7.1) tells you whether the problem is the address or you. For a lead list the working rule is simple: delete the dead addresses, retry the temporary ones once, and stop sending if the refusals are about your reputation.
Reading a bounce is faster than it looks. The message is usually from "Mail Delivery Subsystem" or "Postmaster," and near the bottom is one line from the other server with a three-digit number, a dotted code and a sentence. Ignore the rest. Here is how to read that line and what to do with the address.
The first digit tells you whether to give up
A 5xx code is a permanent refusal for this message. A 4xx code means the server asked you to try again later: its mailbox is busy, it's slow, or it's rate-limiting. The dotted part after it adds the reason. Anything that starts 5.1 is about the address, 5.2 about the mailbox, 5.4 and 4.4 about the connection, and 5.7 or 4.7 about policy, which usually means you, not the address.
Where to find the line that matters
In Gmail, open the bounce and scroll past the friendly heading to the block of technical details. The useful line starts "The response from the remote server was." In Outlook and Microsoft 365 the bounce is called a non-delivery report, and the line to find begins "Remote Server returned." If your own server is the one complaining (for example, a message that your outgoing mail couldn't connect), the code is about you and not the recipient, and the fix is in your account or your tool.
The codes you will see most
| Code and wording | In plain words | Do this |
|---|---|---|
| 550 5.1.1 user unknown, or "account does not exist" | No mailbox at that address | Delete. Check for a typo first |
| 550 5.1.10 recipient not found (Microsoft 365) | Same, from a Microsoft server | Delete |
| 5.1.2 bad destination, or domain not found | The part after the @ doesn't exist | Check the spelling of the domain, then delete |
| 5.2.1 account disabled or inactive | Mailbox closed | Delete |
| 552 5.2.2 or 4.2.2 mailbox full | Person exists but is over their storage | Retry once in 2 days, then drop |
| 4.4.1 or 4.4.2 connection or timeout; 451 greylisted | Their server was slow or asked you to wait | Retry tomorrow |
| 5.7.1 or 5.7.26 blocked, policy, authentication | Refused because of you, or their rules | Keep the address. Stop and diagnose |
Microsoft's and Google's wording differs from small hosts', but the dotted codes mean the same thing across them. If the code is unclear, the sentence next to it is usually plain.
What counts as a bounce and what doesn't
An out-of-office message is not a bounce. Neither is a reply saying "wrong person." A bounce comes from a server, not a human, and it means your email didn't arrive. Both of the others did arrive. Sort them before you count, or your bounce rate will look worse than it is. The handling of those is in cold email auto-replies and out-of-office.
A batch, triaged
Priti sells shift-scheduling software to independent pharmacies. She sent 120 emails and 11 came back. Here is how she sorted them:
- 6 were 550 5.1.1 (no such mailbox). Deleted.
- 1 was 5.1.2 (domain not found). A typo: "pharmcy" for "pharmacy." She corrected it and kept it.
- 1 was 552 5.2.2 (mailbox full). Retry in two days.
- 1 was 4.4.1 (timeout). Retry tomorrow.
- 2 were 5.7.1, both at pharmacies owned by the same chain. Kept, set aside: the chain's mail rules refuse outside senders, so these two need another route.
The raw bounce rate was 11 of 120, or 9.2%. The number that should worry her is the hard address failures: the 6 unknown mailboxes plus the corrected domain, 7 of 120, or 5.8%. That is over the 5% line, which means the list has a source problem, not a typo problem. She went back to where the addresses came from. All six dead ones had been guessed from a pattern, first initial plus last name. After she switched to addresses she could trace to a pharmacy's own site, the next batch of 60 had one bounce.
A bounce log that shows the pattern
Keep one tab in your lead sheet with five columns: date, address, code, what you did, and where the address came from. After three batches, sort by the last column. Bounces almost always concentrate in one source: a purchased file, a pattern guess, a scrape from an old directory. That is much more useful than a bounce percentage, because it tells you which source to stop using. It also stops you re-importing a dead address from an old export, which is one of the most common ways to bounce twice.
When the code says stop everything
Treat a 5.7 code differently from the rest. It isn't a verdict on the address. It's a refusal because of reputation, authentication or the recipient's rules, so deleting the contact fixes nothing and sending more can make it worse. If it's one or two companies, it's theirs. If it appears across many companies, pause, and follow the diagnosis in your message has been blocked in Gmail. The Gmail-specific headings you see in the bounce itself are decoded in Gmail message not delivered: read the bounce, fix it.
Keeping bounces under control
Three habits cut most of them. Verify addresses before the first send, which how to verify email addresses before sending explains. Use real sources, not guesses, for the address itself: how to find a business owner's email address shows where they come from. And send a first batch of 25 to 50, read the bounces by code, and fix the list before the rest goes. The bounce-rate guide has the pause rule.
Rocketship finds the buyers by name, emails them from your own Gmail, follows up, and books the meeting on its own, and a bounce takes that person out of the follow-ups. Plans that get you customers start at $24.99 a month (Launch), and every monthly plan starts with a 7-day free trial, card required. See how the AI workers run outreach.