Email Verification for Cold Email: Cut Bounces Before You Send

A typical outbound week: someone builds a 3,000-row table in Clay from an Apollo search they ran in August, the email column says “verified”, and the list goes straight into Instantly across ten inboxes on three secondary domains. By Wednesday the bounce column is climbing, two inboxes are throwing sending errors, and nobody can say whether the problem is the list, the domains or the copy.

It is usually the list. Cold lists are built from data that nobody on the receiving end confirmed, and B2B contact data goes stale faster than most people expect. The fix is not complicated, but it has to sit in the right places: once while you enrich, again right before upload, and again whenever a list has been sitting around for a few weeks.

This post is for outbound teams buying or finding contacts through data providers and sending through tools like Instantly, Smartlead and lemlist. It covers why cold lists bounce, what a provider’s “verified” flag does and does not tell you, how to handle catch-all domains and role accounts, and how to wire verification into the stack.

Why cold lists bounce more than opt-in lists

An opt-in address was typed by its owner, often confirmed by a click, and is usually mailed soon after. A cold address was found, matched or guessed by a third party, and may have been sitting in a database for months. Nothing in that chain checks that the mailbox still exists.

The biggest single cause is people changing jobs. In January 2026, 20.6% of US wage and salary workers had been with their current employer for a year or less, according to the Bureau of Labor Statistics. Many of those people left a work address behind somewhere, and a contact database that has not caught up still lists them at the old company.

When someone leaves, their employer typically disables or deletes the mailbox. The next email to it gets a hard bounce, often with wording like this on a Google Workspace domain:

Verification catches that before you send, as undeliverable/ mailbox_not_found or, where the server says the mailbox exists but is switched off, undeliverable/ account_disabled .

Job changes are not the only source of decay. Companies are acquired and move everyone to the parent’s domain. Startups shut down and let the domain lapse, which turns into undeliverable/ invalid_domain . And some “found” emails were never real in the first place: they are pattern guesses such as first.last@ that a tool produced because the pattern fit other people at the same company. Our list decay calculator shows how quickly this adds up on a list you do not refresh, and the list decay explainer covers the causes in more detail.

Why “verified” in a data export is not verified today

Most data providers attach a status to each email, and “verified” is the one everyone filters on. Treat it as a claim about a check that happened at some point, by some method, under some definition. Before you rely on it, find the answers to four questions in the provider’s own documentation:

• When was the check made? A check from last week and one from last year carry the same label in most exports. If there is a “last verified” date, export it.
• How was it made? An SMTP accept, a match against a known address pattern, and “we have seen mail delivered here before” are different kinds of evidence.
• What does the provider call a catch-all domain? Some providers label catch-all results separately. If yours folds them into “verified”, a share of your verified rows are guesses that a server accepted without checking.
• What happens to addresses the provider could not check? If a timeout or a block can still end up labelled verified, the label is weaker than it looks.

A Clay waterfall adds a layer: it asks several providers in turn, and each one brings its own definitions. If your waterfall already includes a validation step, check what that step treats as valid and what it does with catch-alls.

Even a perfect check decays. An address that was fine on the day of the export can bounce on the day of the send, for the reasons in the previous section. That is why our default advice is simple: whatever the export says, verify the final list on the day you upload it. The step-by-step guide to how email verification works explains what that check actually asks the mail server.

Secondary sending domains, and why bounces still hurt them

Most outbound teams do not send cold email from their main domain. They register lookalike domains (getnorthwind.com, northwind-hq.com), set up a few inboxes on each, warm them up and send from those. The point is isolation: if cold volume damages a domain’s reputation, invoices, support replies and customer email on the main domain are not caught in it. This is common practice rather than a rule from any mailbox provider.

Subdomains do not give you the same separation in every respect. Google’s sender guidelines FAQ says messages from a subdomain such as promotions.example.com count toward the primary domain when Google decides whether you are a bulk sender, and that once a domain qualifies as a bulk sender, the status is permanent. That is one reason teams buy separate domains instead.

Separation limits the damage. It does not make bounces free:

• The secondary domain has its own reputation. Mailbox providers judge it on the same signals as any other domain, and Amazon SES, in its own documentation, notes that high bounce rates are often used by email providers and anti-spam organizations to spot bad sending practices. See what sender reputation is for how this builds up.
• The inboxes take the hit too. Google’s sender guidelines tell senders to cut volume when messages start bouncing and to unsubscribe recipients who bounce repeatedly. An inbox that keeps sending into dead addresses is exactly what those rules are written against.
• Replacing a burned domain is slow. New domains need new inboxes, new authentication records and a new warmup period. Smartlead’s own guide asks for at least 14 days of uninterrupted warmup before campaigns, and 21 to 30 days for newer domains.
• The brand is still yours. The company name, signature and links in the message point back to you whatever domain it was sent from.

So a secondary domain is a fuse, not a shield. Verification is how you avoid blowing it.

Volume per inbox: what is a hard cap and what is common practice

Two different kinds of numbers get mixed up here. Hard limits are what the mailbox host enforces. Common practice is what outbound teams have found keeps cold inboxes healthy.

Messages per user per day: Google Workspace's hard cap for a paid account (500 on a trial). A ceiling, not a target.

2,000

Messages per user per day: Google Workspace's hard cap for a paid account (500 on a trial). A ceiling, not a target.

Cold emails per mailbox per day: the ceiling Smartlead suggests, based on its own platform data.

50

Cold emails per mailbox per day: the ceiling Smartlead suggests, based on its own platform data.

Of warmup before launching campaigns, per Smartlead's guide. Newer domains may need 21 to 30.

14+ days

Of warmup before launching campaigns, per Smartlead's guide. Newer domains may need 21 to 30.

Smartlead’s guide also suggests starting a campaign at 10 to 15 new leads per day and increasing gradually. Other tools publish their own figures, and they do not all agree, so treat any single number as a starting point rather than a law.

The numbers above are illustrative, but the arithmetic is the point: the bounce rate travels with the list, not with the infrastructure.

How verification sorts a cold list

Here is the workflow we recommend, from the data source to the sending tool. The important part is the split in the middle: each result goes to a different place, and only two of them reach the sending tool.

1. Data source

   Apollo, ZoomInfo, a Clay waterfall or a CSV from a list vendor.

3. Enrich in Clay

   Find the email, add a verification column, drop dead rows before paying for more enrichment.

5. Verify before upload

   RocketVerifier checks the final list on the day you load it into a campaign.

Split by status and sub_status

• deliverable/ none deliverable/ alias plus catch-alls with catch_all_verdict: send_safe

  Mailbox confirmed by an explicit SMTP answer, or a catch-all address the score rates as real.

  Main sequence

• risky/ catch_all catch_all_verdict: send_with_caution

  Separate campaign, small daily batches, watch bounces. Drop avoid.

  Test campaign

• risky/ role_based risky/ possible_typo

  A person decides: is info@ really the right door? Is the typo fix the real address?

  Manual review

• undeliverable risky/ possible_trap risky/ do_not_mail

  Never upload. Add to your suppression list so the next export cannot bring them back.

  Drop and suppress

• unknown/ greylisted unknown/ blocked

  No trustworthy answer yet. Verify again in a day or two; unknowns are not charged.

  Re-check

Sending tool

Instantly, Smartlead, lemlist or similar. Only two buckets ever reach it.

Main sequence Test campaign

A few notes on the buckets.

Deliverable means the receiving server gave an explicit answer that it will accept mail for the mailbox. We never mark an address deliverable because the domain is hosted on Google Workspace or Microsoft 365; if the check is blocked or deferred, the answer is unknown. That matters for B2B lists, where those two providers host a large share of company mail.

Unknown is not a soft “bad”. It means the server deferred, blocked or timed out the check. Greylisted checks are already retried automatically, up to three times about ten minutes apart. If a result is still unknown, run it again a day or two later. Unknown results are not charged, so the re-check costs nothing until you get an answer.

Undeliverable rows, plus risky/ possible_trap and risky/ do_not_mail , should never reach a campaign. Put them on your suppression list so the next export from the same provider cannot quietly bring them back.

Catch-all domains in B2B lists

A catch-all domain accepts mail for any address at the SMTP stage, real or not. Large consumer providers such as Gmail do not accept mail for addresses that do not exist, so catch-all behavior is mostly a feature of company domains, which makes it a cold email problem. On a catch-all domain, the 250 OK that would normally confirm a mailbox proves nothing.

RocketVerifier detects catch-alls by asking about three random addresses at the same domain in the same SMTP session, after the real address was accepted. If two of the three are accepted, the domain is treated as catch-all. The result is risky/ catch_all with a catch_all_verdict based on a 0 to 100 score: the hosting provider, how plausible the local part looks, and whether it matches the address pattern the domain uses. A pattern-guessed first.last@ on a domain that uses first.last@ scores better than jdr77@ on the same domain.

Verdict	Score	What to do in cold outreach
send_safe	65 and above	Main sequence, alongside your deliverable addresses
send_with_caution	35 to 64	Separate test campaign, small daily batches, watch the bounces from each batch
avoid	below 35	Drop

Keep send_with_caution addresses out of the main sequence. If they share a campaign with confirmed addresses, you cannot tell which group is producing the bounces. Run them as their own campaign, start with a small batch, and stop if that batch bounces noticeably more than your main sequence. If you have spare inbox capacity, send them from inboxes that are not carrying your best leads; that is a judgment call, not a rule.

Catch-alls are not covered by the bounce guarantee, which applies to confirmed deliverable results. The full method, with the score bands and a ramp plan, is in Catch-all emails: should you send to them? and on the catch-all resolution page.

Role accounts in prospect lists

When a provider cannot find a person’s address, exports sometimes fill the gap with info@, sales@ or contact@. These are shared mailboxes for a function rather than a person. RFC 2142 has standardized names like info, sales, support and abuse for decades, and plenty of companies run them.

They accept mail, so they are not undeliverable. RocketVerifier returns them as risky/ role_based , because the risk is different: several people or a ticket system read the inbox, nobody asked for your sequence, and the person who reports it as spam may not be the one you meant to reach. Five follow-ups to a shared inbox is a good way to collect complaints.

That is why role accounts go to manual review rather than straight to the bin. A reasonable rule:

• Keep a role address when the company is small enough that info@ probably reaches a founder, or when the message genuinely suits a shared inbox (a partnership, a vendor registration, a press enquiry).
• Drop it when the sequence is written to one person by first name. “Hi Dana” landing in sales@ reads as automated, because it is.
• Replace it when you can: the role address tells you the company is reachable, so it is worth one more enrichment pass to find the actual person.

Role-based addresses covers how they are detected.

How to wire verification into your outbound stack

Verification is cheapest and most useful at three points. You do not need all three on every list, but you need the second one every time.

Two habits make all three steps work better. First, feed every hard bounce from your sending tool back into your suppression list, so it comes back as do_not_mail the next time a provider exports it. Second, track bounces by list source. If one export or one waterfall provider produces most of your bounces, fixing that source is worth more than cleaning its output forever.

What verification does not settle: compliance

A verified address is one that will accept mail. Whether you may send to it is a separate question, and the answer depends on where you and your prospects are. What follows is an overview with sources, not legal advice. If you send cold email at scale, ask a lawyer who knows the countries you sell into.

United States. The FTC’s CAN-SPAM compliance guide states plainly that the law makes no exception for business-to-business email. It does not require consent, but it does require the following:

The FTC guide puts the penalty at up to $53,088 for each separate email that violates the law.

United Kingdom. The ICO’s business-to-business marketing guidance says the PECR rule on marketing by electronic mail does not apply to corporate subscribers, but sole traders and some partnerships are treated as individuals. It also says that a named person’s work email is still personal data, so UK GDPR applies. The ICO notes that this guidance is under review after the Data (Use and Access) Act.

European Union. GDPR applies to identifiable people acting in a business capacity. Recital 47 says direct marketing may be regarded as a legitimate interest, which is the basis most B2B outreach relies on, and Article 21 gives people an absolute right to object to direct marketing. On top of GDPR, each country implements its own electronic marketing rules, and they differ. Germany’s Act against Unfair Competition, for example, treats email advertising sent without the addressee’s prior express consent as an unacceptable nuisance and does not carve out business recipients for email.

Verification does not change any of this. It keeps your bounce rate down; it does not create consent or a lawful basis.