Catch-alls, bounces, and why you verify before you send

You verify email addresses before sending because bounces damage your sender reputation, and unverified lists always contain dead addresses. A catch-all domain accepts mail for any address — real or not — so verification cannot fully confirm those recipients, which is why they get treated as a separate risk class. The rule is simple: no address reaches a sending tool until it has passed verification, and risky addresses are excluded or segmented, never sent to on hope.

What is a catch-all domain?

Most mail servers reject email sent to an address that does not exist — that rejection is the bounce. A catch-all server does the opposite: it accepts mail for any address at its domain. Send to nobody-real@example.co.uk and the server takes it without complaint, whether or not that mailbox exists.

Firms configure catch-alls so misspelled inbound emails still arrive somewhere. The side effect for outbound is awkward: a verification tool tests an address by asking the server "does this mailbox exist?", and a catch-all server effectively answers "yes" to everything. The address checks out as deliverable, and only after you send do you discover whether a real person was behind it. Catch-alls are common in the UK mid-market, so this is not an edge case — a typical B2B list has a meaningful slice of them.

Verification is one link in the deliverability chain — sender reputation, warm-up, authentication, and volume discipline are covered in full in the practical guide to cold email deliverability.

Why do unverified lists produce bounces?

Because contact data decays. People change jobs, firms rebrand their domains, mailboxes get closed. Commonly cited industry figures put B2B email data decay at a substantial share of a list per year, and scraped or purchased lists are worse — they inherit every error of their sources, plus guessed addresses (firstname.lastname@ patterns that were never confirmed) layered on top.

So an unverified list is not "probably fine". It typically carries 10–20% dead addresses, and each one becomes a hard bounce the moment you send to it.

How does bounce rate damage sender reputation?

Mechanically, in a chain:

1. You send to a dead address, and the receiving server returns a hard bounce.
2. Mailbox providers log the bounce against your sending domain. One bounce is noise; a pattern is a signal.
3. When bounces rise, then filters conclude you do not know your recipients — the defining trait of a spammer, since legitimate correspondents rarely mail strangers who don't exist.
4. The filter downgrades the domain. Your subsequent emails — including those to perfectly valid addresses — start landing in spam.
5. Reply rates fall, engagement signals weaken, and the downgrade compounds.

The damage is collective, not per-email. A 15% bounce rate does not cost you 15% of results; it poisons the domain that carries the other 85%. And the domain in question took six to ten weeks to warm — what a 91/100 warm-up score means covers what is actually at stake — so a single unverified upload can wipe out a quarter's worth of infrastructure.

Where does verification sit in the pipeline?

It is a fixed stage, in a fixed order:

1. List. Build the raw list of firms and decision-makers matching the ICP — the sourcing method is set out in the B2B database building guide, and tooling for the sourcing step in AI list building.
2. Enrich. Add the fields the campaign needs: role, firm size, sector detail.
3. Verify. Run every address through a verification tool. Each comes back as valid, invalid, or risky (catch-alls and unknowns).
4. Load. Only the cleared addresses enter the sending tool.
5. Send. 25–40 emails per day per inbox, to a list you know is real.

The order is the point. Verification after loading is admin; verification before loading is protection. Invalid addresses are deleted before they can do harm, and the sending domain never learns they existed.

What do you do with risky addresses?

Two defensible options, and one indefensible one.

• Exclude them. The conservative default. You lose some genuine prospects hiding behind catch-alls, but the sending domain stays pristine. Right answer for new domains and small lists.
• Segment them. Send to risky addresses from a separate, expendable mailbox, at lower volume, watching bounces closely. The main campaign domains never touch them. Right answer at larger scale, where discarding every catch-all costs too much coverage.
• Mix them in and hope. The common answer, and the wrong one. It converts an identifiable, containable risk into an invisible tax on everything you send.

The general principle: known risk gets isolated, never averaged in. It is the same logic as sending from secondary domains rather than your main one — when something goes wrong, the damage lands on an asset you can afford to lose.

---

Next step: the Growth System Audit — £450, seven days, credited against any build — maps where your growth system leaks and what to build first.