Verify close to the send, not at collection. Put accept-all results in their own bucket. Strip role addresses. Then send the first few hundred as a deliberate test batch and read the bounces before continuing.
Published by emailcampaign.ai, which runs cold sending infrastructure. The thresholds below are the ones we act on in our own sending.
What verification does, precisely
A verifier opens an SMTP conversation with the receiving server and gets as far as the recipient command without sending anything. If the server accepts, the address is reported valid. If it rejects, invalid.
That is a genuinely good test for dead addresses, and it will remove most of the mailboxes that would hard bounce. It has two blind spots, and both are the ones that matter.
| Case | Verifier says | Reality |
|---|---|---|
| Mailbox does not exist | Invalid | Correct. Remove it |
| Mailbox exists | Valid | Correct |
| Catch-all domain | Valid or accept-all | Unknown. The server accepts everything |
| Spam trap | Valid | Wrong in the way that matters. Traps accept mail by design |
| Temporarily unreachable server | Unknown or risky | Retry rather than delete |
Accept-all is the case that needs handling
A domain configured to accept mail for any address will answer yes to every address you ask about, including invented ones. So "valid" on a catch-all means only that the server did not say no.
Treating those as verified is how a campaign shows a clean pre-send report and then bounces after sending, because the failure arrives later as an asynchronous bounce once the server discovers there is no mailbox. Some domains skip the bounce and discard silently, which is worse: no signal, and your reputation quietly absorbing unknown-user traffic.
Keep them in a separate segment. Send to them last, in smaller batches, after your clean segment has established a pattern.
What to strip beyond the invalid
- Role addresses.
info@,sales@,admin@,support@. Shared inboxes, higher complaint likelihood, low reply rate, and some are monitored as traps. - Anything you cannot trace. If you do not know where a record came from, you cannot assess it. Records of unknown provenance are where traps arrive.
- Duplicates across campaigns. The same person receiving two sequences from two of your mailboxes is a complaint waiting to happen.
- Prior hard bounces and prior opt-outs. Permanently, across every future list. A suppression list that does not persist is not a suppression list.
Batch the first sends deliberately
This is the cheapest protection available and it is routinely skipped. Send three hundred, stop, read the bounces. If the rate is under two percent, continue. If it is five percent, you have learned that after three hundred messages instead of twenty thousand.
The asymmetry is the whole argument: discovering a bad segment early costs you a small batch, discovering it late costs you the domain’s reputation, and rebuilding that takes weeks of clean sending rather than days.
Classify the bounces correctly when they arrive
Read the enhanced status code rather than the three digit code. A 5.1.1 is a genuine hard bounce and the address should be suppressed. A 5.2.2 is a full mailbox, which is formatted as permanent but behaves as temporary. A 5.7.x is a policy rejection about your sending rather than the recipient, and suppressing the address records the wrong fact while hiding the real signal.
Tools that suppress on any 5.x.x will quietly delete reachable people from your list, and because that also lowers your measured bounce rate, the damage looks like an improvement.
Cadence
Re-verify anything older than about ninety days. Suppress hard bounces immediately and permanently. Review the accept-all bucket separately each time rather than promoting it into the main list.
Questions, answered straight
- How do I remove invalid emails from a list?
- Run verification close to the send date, separate accept-all results into their own segment rather than trusting them, remove role addresses and anything matching known trap patterns, and send the first few hundred as a test batch so you learn about a bad segment early.
- Does email verification catch everything?
- No. Verification checks whether a server accepts the address. It cannot detect a spam trap, because a trap accepts mail by design, and it cannot resolve a catch-all domain, because those accept every address you ask about.
- Should I remove role addresses like info@ or sales@?
- For cold outreach, generally yes. They are routed to shared inboxes, are more likely to be reported as spam, and some are monitored as traps. They also have a low reply rate, so removing them costs little.
- How old is too old for a verified list?
- About ninety days. B2B contact data decays continuously as people change roles, so a file verified three months ago will contain addresses that have since stopped working.
- What bounce rate means I should stop?
- Above five percent hard bounces, pause rather than finish the campaign. The reputation cost accrues with every additional send, and recovery is measured in weeks of clean sending.
Published 20 September 2026. Updated 20 September 2026. Written by the team that runs the infrastructure; numbers come from the platform's own provisioning and sending, and from the providers' published documentation at the time of writing.