Verified addresses still bounce for three reasons: the verifier guessed (some mail servers accept anything and reject later), the data went stale (people leave jobs), or the bounce is about you, not them (your domain or IP is being blocked). The bounce message tells you which. Read the code in the bounce first, then act on it. Re-verifying the list does not help if the problem is your sender.
A list that comes back "valid" feels safe. It is not a promise. Verification is an educated check of a mailbox you cannot see into, and the check is only as current as the day it ran. This page is about what is left after verification, which is a different problem from the one in how to verify email addresses before sending.
Step 1: Read the code, not the dashboard
Every bounce carries a numeric code. Google's own documentation on Gmail SMTP errors lists the common ones. These are the codes you will meet most with Gmail and Google Workspace recipients, and what Google says each means:
| Code | Google's meaning | Whose problem |
|---|---|---|
| 550 5.1.1 | Permanent. The recipient address does not exist. | The list. Remove it. |
| 553 5.1.2 | Permanent. The recipient domain cannot be found. | The list. Check the domain for typos. |
| 452 4.2.2 | Temporary. The recipient's mailbox is full. | Theirs. Retry later. |
| 552 5.2.2 | Permanent. Mailbox full and inactive. | The list. Treat as dead. |
| 450 4.2.1 | Temporary. The recipient is getting too much mail too fast. | Theirs. Retry later. |
| 421 4.7.0 | Temporary. Gmail closed the connection or rate-limited the sender, for example over IP reputation. | Yours. |
| 550 5.7.1 | Permanent. Blocked for policy, spam, reputation, content or RFC compliance reasons. | Usually yours. |
The last two rows are the trap. A 5.7.1 or a 4.7.0 says nothing about whether the person exists. If your "bounces" are mostly those codes, your list is fine and your sending is the problem. See SPF, DKIM and DMARC for cold email and the Gmail blocked-message fix. Other mail systems use similar numbers, but the wording differs, so read the line of text beside the code.
Why a verified address can still be dead
- Catch-all domains. Some companies configure their mail server to accept every address and sort it later. A verifier cannot tell if "jordan@" exists, so it marks it risky or passes it. The real answer comes when your message is delivered or dropped.
- Delayed rejections and greylisting. Some servers say yes to a verifier's check and only decide on the real message, so the rejection arrives as a bounce a few minutes after you send. Greylisting is a cousin: the server refuses a first attempt for a while and accepts the retry, which leaves the check unsure and gets the address marked "valid" or "risky" on a guess.
- Age. A list verified in March and sent in October carries seven months of people changing jobs. Whoever left in June now has a closed mailbox.
- Role and shared mailboxes. info@ and sales@ are often forwarded to people who left. They pass checks and still go nowhere useful.
- Typos introduced after. Merging two sheets, copying a column or an autocomplete can change an address between the check and the send.
How to tell if an address really belongs to that person
When verification says "valid" but you doubt it, check the facts around the address rather than the address alone.
- Match the pattern. Find two other people at the same company in press releases or on their site. If they use first.last@ and your address is flast@, one of them is wrong.
- Check the domain. The email's domain should be the company's own site. A sheet that lists acme-corp.co when the website is acme.com has the wrong domain, and every address on it will fail.
- Check the person is still there. Open their LinkedIn or the company's team page. If the role has changed, the address may be closed.
- Send one by hand. For a high-value prospect, a plain email from your own mailbox is the best verification there is.
A worked example. Say a recruiting firm in Denver has 400 verified addresses and sees 31 bounces, 7.75 percent. It sorts them: 19 are 550 5.1.1 (no such mailbox), 4 are 552 5.2.2 (full and inactive), 6 are 550 5.7.1 (blocked) and 2 are timeouts. That is 23 list problems and 6 sender problems. The fix is two separate jobs: delete the 23, and for the 6, look at authentication and sending volume. Without sorting, it would have bought a second verification pass that fixes none of the six.
Step 2: Sort the bounces into three piles
- Remove now: 5.1.1, 5.1.2 and 5.2.2. Never send to those again. The distinction between hard and soft is in soft bounce versus hard bounce.
- Retry once later: 4.2.2, 4.2.1 and other temporary codes. Wait a day. If it fails again, treat as dead.
- Fix on your side: 4.7.0, 5.7.1 and anything about reputation, authentication or content. Slow down, send fewer emails a day and check your records.
Step 3: Know your bounce rate
Track bounces as a share of sent emails each week. If it climbs, you will feel it in replies before you see it in a report, because mail providers start treating you as a risk. What counts as high and how to bring it down is in cold email bounce rate.
Step 4: Keep the list fresh
- Verify within a few days of sending, not weeks.
- Send in smaller batches, so a bad batch is a small loss.
- Mark every bounced address in your sheet with the code and the date.
- Add a column for "last confirmed" and drop anyone older than a quarter.
Keeping data fresh by hand takes hours every week. Rocketship finds each person with an email at the time you search and charges nothing when no email is found: 4 credits for each person found with an email, and extra credits are 1,000 for $45. The plans show how many credits come with each.