There is a particular kind of campaign failure that looks like bad luck and is actually arithmetic.
You send to ten thousand addresses. Fifteen per cent bounce. You shrug — you expected some decay, the list was a year old — and you look at the open rate on the rest, which is dismal. You rewrite the copy. You send again. It is worse.
What happened is not that your copy got worse. What happened is that the first send told every major mailbox provider that you are a sender who does not know who is on their list, and they adjusted their treatment of you accordingly. The second campaign was filtered before anyone read a word of it.
This piece is about why that happens, what each kind of bad address actually does to you, and how to fix it without throwing away the good prospects along with the dead ones.
What a bounce actually signals
A hard bounce means the address does not exist. That is the surface fact. The consequential fact is what it tells the receiving mail server about you.
Legitimate senders — a bank, a newsletter someone signed up for, a colleague — have very low bounce rates, because they are writing to people who gave them their address. Bulk senders working from scraped or purchased lists have high bounce rates, because a scraped list is full of addresses that were guessed, are stale, or never existed.
So bounce rate is one of the cleanest available proxies for "is this sender writing to people who asked to hear from them?" It is cheap for the receiver to measure and expensive for a spammer to fake. That makes it a load-bearing input into your sender reputation, and reputation is what determines whether your mail reaches the inbox, the spam folder, or nowhere at all.
Google’s sender guidelines put the spam-complaint line at 0.3%, and the threshold most providers get uncomfortable at for bounces is around 2%. Above 5% you are in trouble. At 15% you are not really a sender any more; you are a problem being managed.
The part people miss: bounces hurt the addresses that are real
This is the point that reframes everything else, so it is worth stating plainly.
If 20% of your list is dead, the cost is not that you reach 80% of your intended audience. The cost is that your reputation is damaged by the 20%, and that damage suppresses delivery to the 80% who are perfectly real and might have been interested.
You are not losing the dead addresses. You never had them. You are losing the live ones, and you are losing them invisibly, because a message filtered to spam does not report back to you. Your dashboard will show it as "delivered". It just will not be read.
This is why list hygiene is not housekeeping. It is the precondition for anything else you do working at all.
Spam traps: the addresses designed to catch you
Some of the worst addresses on a list are not merely dead. They are bait.
A pristine trap is an address that was never used by a human — created and published by an anti-abuse organisation purely to see who scrapes it. There is no legitimate way to have it. Sending to one is close to a confession: it means you harvested addresses from somewhere without consent.
A recycled trap is subtler and much more common. It is a real address, abandoned by its owner, which the provider left to bounce for a while and then reactivated as a trap. It is punishing exactly one thing: sending to a list you have not cleaned in a long time. If a two-year-old list is still in your CRM and nobody has verified it since, this is the mechanism that will find you.
Hitting traps has consequences well beyond a single campaign, because the organisations that run them feed blocklists that mailbox providers consult. Spamhaus is the best-known; getting onto one of their lists affects your mail everywhere at once, and getting off is a process rather than a button.
You cannot detect a trap by looking at it — that is the entire design. What you can do is never send to addresses that show the characteristics traps hide behind: long-unengaged, never-verified, and acquired from a source you cannot account for.
Disposable addresses, and why they matter more at signup than at send
Disposable addresses — the ten-minute mailboxes people use to get past a registration wall — are a different problem, and the place to solve them is not the campaign. It is the signup form.
A disposable address in your database is a user who will never convert, never engage, and will eventually become a bounce when the domain expires. Worse, if you are running a free trial, they are how one person becomes fifty free accounts.
The fix is to reject them at the point of entry, which costs one API call, rather than to clean them out later, which costs a reputation. Our free disposable email checker shows what that check looks like on a single address; the verification API is the version you wire into a registration form so the bad address never lands in your database in the first place.
Catch-all domains: the genuinely hard case
Here is where most verification tools quietly lie to you, so it is worth understanding properly.
A catch-all (or accept-all) domain is configured to accept mail for any address at that domain, whether or not the mailbox exists. Write to asdfghjkl@theircompany.com and the server says "yes, fine, I'll take it".
This means the standard verification method — connect to the mail server and ask whether the address exists — cannot work. The server will say yes to everything. It is not being deceptive; it is doing what it was configured to do, often for perfectly good reasons like avoiding information disclosure about who works there.
So what should a verifier report? There are three options, and only one of them is honest:
- Report "valid". This is what many tools do, because it makes the numbers look good. It is a lie. The tool does not know.
- Report "invalid". Also wrong, and expensive — catch-all domains are disproportionately larger companies, which means this quietly deletes your best prospects.
- Report "unknown — catch-all". The truth. It tells you the check could not be completed and why, and it leaves the decision with you.
The third is the only defensible answer, and it is what our catch-all detector reports. A verifier that never says "I don't know" is not more accurate. It is less honest.
What do you do with a catch-all? Send, but treat it as higher-risk: keep it out of your first large send, use it in a smaller wave, and watch what bounces. And if the address was derived — guessed from a name and a pattern rather than found — weigh it accordingly, because a guessed address at a catch-all domain has had no verification of any kind applied to it.
Role addresses: not invalid, but rarely worth the risk
info@, sales@, support@, admin@. These are real, deliverable addresses. They are also, usually, a bad idea to include in cold outreach.
They tend to be read by several people or by none. They receive a very high volume of unsolicited mail, which means the person reading them has an itchy spam-complaint finger. And a complaint from a role address carries the same reputational weight as any other.
They are not a hygiene problem in the sense that a bounce is. They are a judgement call, and the usual answer is: exclude them from cold campaigns, keep them for support and transactional contexts where they belong.
What verification can and cannot tell you
It is worth being precise about the limits, because vendors are generally not.
Verification can establish:
- Whether the address is syntactically valid (cheap, and rules out typos).
- Whether the domain exists and has mail servers configured — an MX record. A domain with no MX cannot receive mail, full stop.
- Whether the mail server accepts mail for that specific mailbox (unless it is a catch-all).
- Whether the domain is disposable, a known trap source, or a role address.
Verification cannot establish:
- Whether the person still works there. An address can be live and belong to someone who left in March.
- Whether the mailbox is monitored. Plenty of valid addresses are read by nobody.
- Whether the address exists behind a catch-all. As above — that is a genuine unknown, and anyone claiming otherwise is guessing.
Being clear about this matters, because a "98% deliverable" score from a tool that reports catch-alls as valid is not a 98% deliverable list. It is an unknown list with a confident number printed on it.
How to clean a list without destroying it
A practical order of operations:
- Syntax first. It is free and instant, and it removes the typos —
@gmial.comand its family. - Then the domain. If there is no MX record, nothing at that domain can receive mail. This single check removes a surprising share of a stale list, and it requires no contact with the mail server at all. Our deliverability checker runs this against a domain.
- Then the mailbox. The SMTP-level check. This is where you find the individual dead addresses at live domains.
- Then classify what is left. Catch-all, role, disposable, and known-risky domains all get their own treatment — not deletion, but a decision.
- Then segment by risk. Send to the clean, confirmed addresses first. Watch the bounce rate. If it is healthy, bring in the catch-alls in a second wave. Do not put your unknowns and your knowns in the same send.
That last step is the one people skip, and it is the one that protects you. If your first send is 90% confirmed-good addresses, a problem in the remaining 10% is a small dent. If it is 50/50, you have gambled your domain on the half you never checked.
Warming up, and why "just send fewer" is real advice
Reputation is per-domain and it accrues over time. A brand-new sending domain has no reputation — which is not neutral, it is suspicious, because spammers burn through fresh domains constantly.
So volume ramping is not superstition. Start small, send to your most-likely-to-engage recipients first, and let the positive signals — opens, replies, no complaints — accumulate before you scale. A domain that goes from zero to five thousand sends in a day is behaving exactly like a domain that has been bought for a spam run, and it will be treated as one.
The same logic applies after any incident. If you have burned a domain, the recovery is not a clever trick; it is weeks of low-volume, high-engagement sending, or a new domain and the patience to warm it properly.
Soft bounces, hard bounces, and the difference that matters
Not every bounce is the same, and treating them alike will make you delete good addresses and keep bad ones.
A hard bounce is permanent: the address does not exist, the domain does not exist, the mailbox has been deleted. There is no future in which this address works. Remove it immediately and permanently, and — this is the part people get wrong — remove it from every list, not just the one that bounced.
A soft bounce is temporary: the mailbox is full, the server is down, the message was too large, the recipient is on holiday with an auto-responder that misbehaves. The address is real. It may well be one of your best prospects, and deleting it on a single soft bounce throws away a live contact for no reason.
The rule that works: hard bounce, remove at once. Soft bounce, retry — but cap it. Three or four soft bounces across separate campaigns, spread over weeks, and the address should be treated as dead regardless of what the server said, because a mailbox that has been full for a month is a mailbox nobody is reading.
The danger is systems that lump these together. If your sending tool reports a single "bounced" figure with no breakdown, you cannot make either decision correctly, and you will drift toward one of the two failure modes — a list full of dead addresses, or a list that has quietly eaten its own best contacts.
Why a list decays faster than you think
The usual figure quoted is that a B2B email list decays at roughly 2 to 2.5% per month — Harvard Business Review has written about why CRM data rots this fast. Compound that and it means about a quarter of your list is dead within a year, and close to half within two.
The reason is simply that people change jobs. Every departure turns a valid address into a bounce, silently, with no notification to you. Nobody emails their vendors to say they are leaving.
Two consequences follow, and both are counter-intuitive.
First, a list you verified last year is not a verified list. It is an unverified list with a reassuring memory attached to it. Verification is a snapshot, and the snapshot expires.
Second, the addresses most likely to have decayed are the ones you most want. Decision-makers move more often than junior staff. Fast-growing companies restructure. The most valuable segment of your list is also the fastest-rotting, which means the cost of stale data falls hardest exactly where you can least afford it.
This is the argument for verifying at send time rather than at import time — and for enrichment that can tell you the person has moved, rather than merely that their address has stopped working.
The economics: what verification actually saves you
It is worth doing the arithmetic, because the case is stronger than most people assume and it is rarely laid out.
Take a list of 10,000 with a 15% dead rate, and suppose verification costs a fraction of a cent per address. Cleaning it costs you a few tens of dollars. What does it save?
- The 1,500 wasted sends. Trivial in cost. This is the saving people cite, and it is the least important one.
- The reputation damage. A 15% bounce rate will materially degrade inbox placement for the remaining 8,500. If that degradation costs you even 20% of your inbox placement, you have lost 1,700 real prospects — more than the number of dead addresses that caused it.
- The recovery time. Reputation damage is not undone by stopping. It takes weeks of careful, low-volume sending to rebuild. That is the genuinely expensive item, and it does not appear on any invoice.
- The blocklist risk. If there were traps in the 15%, you may be dealing with something considerably worse than a slow quarter.
The cost of verification is a rounding error against any one of those. The reason people skip it is not economic; it is that the damage is invisible and delayed, while the cost is visible and immediate. That is a well-known cognitive trap, and it is worth naming it as one.
Verify at signup, not just before sending
Everything above is about cleaning a list you already have. The cheaper strategy is to never acquire the bad addresses in the first place.
An open signup form with no validation will accumulate typos (@gmial.com), disposable addresses, and outright junk, and every one of them is a future bounce that you will pay for later at a much higher price than the API call that would have caught it at the door.
Real-time verification at the point of registration does three things at once:
- Catches the typo while the user is still there to fix it. This is the underrated one — it is not a security feature, it is a conversion feature. A user who mistyped their address and never got the confirmation email is a lost customer who thinks your product is broken.
- Blocks disposables before they become free-trial abuse. One person, fifty accounts, is a disposable-address problem before it is anything else.
- Keeps the database clean by construction, which means you never face the "we need to clean 200,000 records" project, because there is nothing to clean.
This is exactly what the verification API is for, and it is a materially better place to spend the effort than any amount of retrospective hygiene.
What to do if you have already damaged your domain
Suppose the worst has happened. Bounce rate was 18%, two campaigns went out, and your open rates have fallen off a cliff and stayed there.
The instinct is to buy a new domain and carry on. Sometimes that is right. But do it in the wrong order and you will burn the new one too, because the thing that damaged the first domain was the list, and the list has not changed.
The sequence that actually recovers:
- Stop sending. Every further send to a bad list deepens the hole. This is hard to do when there is a quarterly number attached to it, and it is nonetheless the first step.
- Fix authentication. Confirm SPF, DKIM and DMARC are correct. If they were wrong, some of the damage may be attribution rather than reputation, which is better news than it sounds.
- Clean the list properly. Not a sample — all of it. Segment into confirmed, unknown, and dead.
- Rebuild slowly on the confirmed segment. Low volume, high relevance, to people most likely to engage positively. You are trying to generate positive signals, and you cannot do that at scale.
- Only then consider a new domain, and warm it properly, on the clean list. A fresh domain fed a dirty list simply reproduces the original failure with a delay.
Recovery is measured in weeks, not days. There is no shortcut, and the vendors who claim otherwise are selling you a faster route back to the same place.
The uncomfortable summary
Deliverability is not a feature you buy. It is a consequence of how you behave.
Mailbox providers are, in the end, trying to answer one question on behalf of their users: does this person want to hear from this sender? Every mechanism described here — and the standards they are built on — — bounce rates, traps, engagement, authentication — is an attempt to measure that question cheaply and at scale.
Which means the durable strategy is not to look like a wanted sender. It is to be one: write to people who plausibly want to hear from you, about something specific to them, from a domain you have looked after, to addresses you have actually checked exist. Do that and the technical mechanics mostly take care of themselves.
Do the opposite, and no verification tool on earth will save you — it will simply tell you, in more detail, why the mail is not arriving.
The order that actually works
If you take one thing from this, take the sequence, because almost every deliverability disaster is a sequence error:
Authenticate, then verify, then segment, then send — and only then think about copy.
Get SPF, DKIM and DMARC right, because without them nothing else you do can be attributed to you correctly. Verify the list, because a bounce damages the addresses that are real. Segment by confidence, so an unknown cannot take down a campaign. Send in ramped waves, so reputation accrues rather than spikes. And treat the subject line as the last five per cent, not the first — which is the argument made at greater length in our piece on cold email subject lines.
Verification is the least glamorous part of outbound and the highest-leverage. Nobody has ever been promoted for cleaning a list. But every campaign that works sits on top of one that was.
Clean data and a warm domain work together. Pair real-time checks from the verification API with disciplined sending in Govarova Sequences, or start a free trial.
