Why Your Follow-Up Emails Bounce More Than Step 1 (and How to Stop It)

If step 1 of your sequence bounces under 2% and step 3 bounces at 5% or more, there are four usual causes. First, arithmetic: fewer emails go out on later steps, so the same handful of bounces is a bigger percentage. Second, delayed bounces from step 1 that arrived late and were never removed. Third, decay: addresses that closed during a long sequence. Fourth, blocks that build up as you keep mailing the same companies. Read the bounce codes per step to tell them apart. Then suppress every hard bounce before the next step fires, and re-verify leads whose next send is weeks after their last check.

The pattern is common. One r/coldemail poster described it in May 2026: "bounce rate on step 1 is consistently under 2%... climbs to 5-8% by the time the sequence completes."

Cause 1: the denominator shrinks

Every step sends to fewer people than the one before. People reply, unsubscribe, book a meeting, bounce or are removed by hand. Some tools report bounce rate per step, so step 3's rate is calculated on a smaller base.

An illustrative example:

Step	Emails sent	Bounces	Bounce rate
1	2,000	30	1.5%
2	1,700	25	1.5%
3	900	25	2.8%
4	400	20	5.0%

Steps 2 to 4 together produced fewer bounces than step 1 did. The rising percentage comes mostly from the shrinking base. If your step 4 only goes to a few hundred leads, a handful of bounces will always look alarming.

Check: compare bounce counts per step, not just rates. Also check how your tool counts. Some count a bounced send as a "touch" in the step total, which changes the maths again.

Cause 2: bounces that arrive late

Not every bounce comes back during the SMTP conversation. Some servers, including many security gateways and some catch-all setups, accept the message first and send a bounce message (NDR) minutes, hours or days later. Your tool may record the step-1 send as delivered, then pick up the bounce later. That is either too late to stop step 2, or the bounce gets attributed to whichever step happened to be in flight.

You will see this most on:

• Catch-all domains, which accept every address at the door and may bounce unknown ones afterwards.
• Gateway-protected companies (Proofpoint, Mimecast and others) that accept first and reject later.
• Hybrid Microsoft 365 tenants where a directory sync gap shows up after acceptance.

Fix: make sure your sending tool reads bounce messages into the mailbox (most sequencers do this by watching the inbox for NDRs). Give the inbox time between steps; a 2-3 day gap lets late bounces land before the next step. And treat catch-all rows as their own segment. See should you email catch-all addresses.

Cause 3: addresses die during the sequence

A four-step sequence with gaps of a week runs for a month. Add the time between verifying and launching, and some leads were last checked six weeks before their final step. B2B data decays as people leave jobs, companies rebrand and mailboxes are closed. Our post on B2B contact data decay covers how fast.

Mailboxes also go through a soft phase before a hard one. A mailbox that is full (552 5.2.2) or temporarily disabled on step 1 can be gone by step 3. See hard bounce vs soft bounce for how the two differ.

Fix:

1. Verify close to launch. A list checked the day before step 1 starts the sequence clean.
2. Re-verify before late steps for leads whose last check was more than about three to four weeks before the step fires. A re-check of only the leads due next week is a small job. The email list decay calculator helps you judge how much of a list has probably gone stale.
3. Shorten long sequences. Four steps over two to three weeks decays less than six steps over two months.

Cause 4: blocks build up as you keep mailing

Each step is another message from you to the same companies. If recipients mark step 1 as junk, or a gateway starts to see a pattern, later steps can be rejected outright. Those rejections are counted as bounces by most sending tools, even though the address is fine.

Look for these in later steps:

Bounce text	What it is
550 5.7.1 with spam or policy wording	A content or reputation rejection
554 Blocked - see https://proofpoint.com/postmaster	Proofpoint reputation block. See Proofpoint blocking your emails
550 Administrative prohibition envelope blocked	A Mimecast blocked-sender or SPF rule. See Mimecast rejections explained
451 4.7.650 ... rate limited due to IP reputation	Microsoft consumer throttle. See 451 4.7.650
421 4.7.0 / 4.7.28 from Gmail	Gmail rate limiting on reputation. See Gmail bounce codes

Fix: these are not list problems, so verifying again will not help. Slow down, check authentication, rotate fewer messages per inbox per day (see cold emails per day per inbox), and make follow-ups short, plain and easy to say no to.

How to tell which cause you have

1. Export bounces with the full bounce text and the step number. Most sequencers can filter bounced leads by campaign and step.
2. Paste them into Bounce Doctor. It sorts each bounce into bad address, missing domain, sender block, security gateway or temporary, and builds suppress and retry files.
3. Read the split by step:

What you find on later steps	Likely cause
Few bounces in absolute terms, rate up only because sends fell	Cause 1, the denominator
5.1.1, 5.4.1, "user unknown" on addresses that showed delivered on step 1	Cause 2, late bounces
Bad-address bounces on leads verified long ago	Cause 3, decay
5.7.x, gateway blocks, Microsoft or Gmail throttling	Cause 4, blocks

Most campaigns show a mix. Fix the biggest slice first.

A routine that keeps follow-ups clean

1. Verify within a few days of launch. Send step 1 only to valid rows. Upload on the verify page.
2. Leave 2-3 days between steps so late bounces land before the next send.
3. Suppress every hard bounce globally, not just in that campaign. A lead that bounced in client A's workspace should not get step 1 again from client B's. See cold email suppression lists.
4. Re-verify leads due for a step if their last check is a month old or more.
5. Watch the bounce mix per step. A rise in 5.7.x codes is your cue to slow down, not to re-verify.
6. Never re-import a bounced lead without re-verifying it. Old CSVs bring dead addresses back.

Where SimpleVerifier fits

SimpleVerifier handles steps 1 and 4: a full check before launch, and a quick re-check of the leads due next. Valid means a server confirmed the mailbox. Catch-alls stay risky and graded, so you can keep them out of the main sequence. Rows we could not check come back to retry, not as valid. A re-check of a few hundred leads takes seconds on the verify page or through the API.

The first 100 checks are free with a Google sign-in. Plans are on the pricing page.