Can a Verified List Ever Have Zero Bounces? What 4 Out of 134 Really Means

No, a verified list almost never bounces at exactly zero, and on a small campaign a handful of bounces looks far worse than it is. Verification is a snapshot: mailboxes close after the check, catch-all domains can't be confirmed, and some rejections are about the sender rather than the address. Aim for a low, stable rate, read every bounce by its code, and judge a list or source on a few hundred sends, not one small batch.

The question comes up constantly in cold email forums, in nearly these words: I verify everything, keep only the good results, send 25-30 a day per inbox, and still get bounces. One sender asked how to get to zero after 4 out of 134 verified leads bounced. Here is what those 4 mean.

Small sends exaggerate

4 out of 134 is 3%. But a sample that small can't pin the true rate down. Using a standard 95% interval (Wilson):

Bounced / sent	Observed	Plausible true rate (95%)
0 / 134	0%	0% to 2.8%
1 / 134	0.7%	0.1% to 4.1%
4 / 134	3.0%	1.2% to 7.4%
20 / 1,000	2.0%	1.3% to 3.1%
0 / 300	0%	0% to 1.3%

Even a clean zero on 134 sends is consistent with a true rate near 3%. The interval only narrows with volume. Our post on testing a new lead source uses the same math to size a test, and the bounce rate calculator works out the rate for any campaign.

Why some bounces survive verification

1. Time. The longer between check and send, the more mailboxes have closed. On a multi-step sequence, step 4 goes out weeks after the check.
2. Catch-all domains. The server accepts every address during the check, then bounces the ones that don't exist. These come back as risky, not valid, for that reason.
3. The sender, not the address. Gateways and providers reject unknown or distrusted senders with policy codes. Those count as bounces in your sequencer even though the mailbox exists.
4. Temporary failures logged as bounces. Full mailboxes and throttling (4xx codes) are temporary, but some tools count them.
5. A real false positive. Occasionally a server says yes to the check and no to the message. It's the rarest cause, though it does happen.

Sort your bounces before you blame the list. The bounce message analyzer groups them by code: 5.1.1 and Microsoft's 5.4.1 are bad addresses; 5.7.x are policy; 4.x.x are temporary. Our post on verified emails that still bounce goes through each cause with fixes.

Getting as close to zero as the data allows

1. Verify within days of the send. Upload the list on the verify page the week it goes out, and re-check before late sequence steps if more than about 30 days have passed.
2. Send only the valid file. Valid, risky and invalid download as separate files.
3. Hold back catch-all and unknown rows. Send them later, in a small separate batch, from inboxes that can absorb a few bounces. Our guide to catch-all emails covers the options.
4. Suppress every hard bounce at once. Don't let step 2 go to an address that bounced at step 1.
5. Check the sending side when bounces aren't 5.1.1. Authentication, gateways and infrastructure don't show up in a list check.

What "good" looks like

A low rate that stays low across campaigns matters more than one perfect send. If several hundred sends from a verified list keep bouncing above 2-3%, and most bounces are 5.1.1, the source or the time since verification is the problem. If most are policy codes, look at the sender.

Where SimpleVerifier fits

The analyzer and calculator are free. For mailbox checks, the first 100 are free with a Google sign-in on the verify page. Starter is $9 a month for 2,500 checks, and Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.