The Best Way to Verify Cold Email Addresses

The best way to verify cold email addresses is a layered pipeline: strip syntax errors and disposable domains, confirm the domain has live MX records, run an SMTP-level check through a reputable third-party verifier, and then treat the results as three buckets. Send to valid, discard invalid, and route catch-all/unknown to isolated sending infrastructure where a bounce can't damage your best domains. No single tool returns a clean yes/no on modern B2B lists. The goal isn't a perfect verdict on every address. It's keeping hard bounces under ~2% on the mailboxes that matter while losing as few real prospects as possible.

That last part is where most guides stop being useful. They recommend a tool and move on. But verification accuracy has degraded sharply as Microsoft 365 changed how it responds to probes, as security gateways swallowed millions of B2B domains, and as catch-all configuration became the default at most mid-market companies. Below is how verification actually works, why your tool disagrees with the next one, and how to build a process that survives those limitations.

How does email verification actually work?

Every real verifier runs the same core sequence. Understanding it tells you exactly where it breaks.

That last step looks roughly like this:

The entire verification industry rests on that RCPT TO response. Which is a problem, because receiving servers have spent the last several years making that response deliberately less informative.

Why do two verification tools give different answers for the same address?

Because they're interpreting ambiguous SMTP responses differently, and each has its own house rules for what counts as "valid."

The practical consequence: a "valid" from a verifier is a claim, not a fact. Treat vendor labels as probabilistic, and grade vendors on the two errors that actually cost you: false valid (a bounce you paid for with domain reputation) and false invalid (a real prospect you deleted).

What is a catch-all domain, and how should you handle it?

A catch-all (or accept-all) domain is configured to accept mail for every address at that domain, including ones that don't exist, and sort it out internally afterward. RCPT TO always returns 250, so SMTP verification carries zero information there.

Catch-alls are extremely common in B2B, and they're the single largest source of unverifiable addresses in a typical prospect list. Anything sitting behind a security gateway (Proofpoint, Mimecast, Barracuda, Cisco) is effectively catch-all by design. You can spot these from the MX record before you spend a verification credit.

Your options, in order of how much they're worth:

What you should not do is let catch-alls sit unlabeled in your main sequence. That's how a 1.5% bounce rate quietly becomes 9%.

Why is Microsoft 365 harder to verify than Google Workspace?

Exchange Online's behavior depends on tenant configuration, and Microsoft has progressively made its RCPT TO responses less useful to outside probes.

Tenants using Directory Based Edge Blocking will reject unknown recipients at the edge, which is verifiable. Tenants with a connector or gateway in front, or with DBEB disabled, accept everything and sort it later, indistinguishable from catch-all. On top of that, Microsoft rate-limits and returns generic responses to connections that look like directory probing, so the same address can return different verdicts on different attempts from different IPs.

Google Workspace remains the more reliably verifiable of the two, but Google aggressively throttles verification traffic. Expect a higher unknown rate on Microsoft-hosted domains than on Google-hosted ones, and don't interpret that gap as your vendor being bad at its job. Check the MX record and you'll usually see why.

This is also why knowing which provider hosts your own mailboxes matters when you interpret bounces later. Google Workspace and Microsoft 365 write different NDR text for the same underlying failure.

How do you test whether your verification tool is actually accurate?

This is the step almost nobody does, and it's the one that separates teams who know their bounce rate from teams who are surprised by it. Build a known-truth seed list and score every vendor against it.

Weight false valids most heavily. A false invalid costs you one prospect. A false valid costs you a bounce, and bounces compound against the sending reputation of the mailbox and domain that generated them. Re-run this test every six months. Vendor accuracy drifts as receiving servers change behavior, and the vendor that won last year may not win now.

A reasonable production setup after testing: one primary vendor for the full list, one second-opinion vendor run only against the primary's risky/unknown bucket. Paying twice for 10% of your list is cheap. Paying twice for all of it is not.

Should you verify from your own sending IPs or mailboxes?

No. Issuing large volumes of RCPT TO commands from your sending infrastructure looks exactly like a directory harvest attack, because mechanically it is one. Receiving servers and blocklist operators watch for that pattern, and the outcome is a flagged IP or a blocked sending domain, the precise thing verification was supposed to prevent.

Keep the two functions separate. Verification is a third-party vendor's job, on their IPs, with their reputation at stake. Your sending infrastructure's job is to send, and to give you clean feedback when something fails.

That feedback loop is where owning your mailboxes rather than renting seats on shared infrastructure pays off. With full admin access to your own Google Workspace and Microsoft 365 tenants, which is what Inboxlogy provisions at $2.80 per mailbox per month with 100% ownership and admin rights, you can open the actual bounce NDRs at the mailbox level, export them, read the real SMTP status codes, and feed genuine failures back into your data. On reseller infrastructure where you only see a summary in a dashboard, you're working from someone else's interpretation of what happened.

Cheap per-mailbox pricing also makes segmentation practical. A pool of mailboxes on throwaway domains dedicated to catch-all and risky segments costs very little, and it keeps your proven domains out of the blast radius. (Warmup itself runs in your connected sending tool, whether Instantly, Smartlead, or ReachInbox, against whichever mailboxes you point it at.)

How fresh does verification need to be?

A verification result is a snapshot with a shelf life. People change jobs, companies migrate providers, and mailboxes get deprovisioned. An address verified in March and sent in September was verified against a company that may no longer employ that person.

Practical rules:

What bounce rate should you target, and how do you read bounces correctly?

Aim to keep hard bounces under 2% per mailbox, and treat anything sustained above 4–5% as a stop-and-fix signal. Most cold email platforms will flag or auto-pause sequences somewhere in that range.

But the number matters less than reading bounces correctly, and this is where a lot of otherwise careful teams corrupt their own data:

That last distinction is the single most valuable thing in this article. A rising "bounce rate" that's actually policy rejections means your SPF/DKIM/DMARC alignment, your IP reputation, or your content is the issue, and no amount of list verification will fix it. Check the raw NDR text before you conclude your data is bad.

What can verification NOT fix?

Verification confirms that a mailbox exists. It says nothing about whether mail to it will land in the inbox, and nothing about whether you should be sending it.

What does a complete pre-send workflow look like?

Put together, here is the sequence worth running before any batch enters a sequence:

Steps 6 through 8 are infrastructure decisions rather than data decisions, and they're only available to you if you control the mailboxes: separate domains for separate risk tiers, real NDR visibility, and correct authentication on every domain from the start. That's the argument for owning your sending estate rather than renting it. Verification tells you what you can't send to, but only your own infrastructure tells you the truth about what happened when you did.

FAQ

Is free email verification good enough for cold email?

Free tools generally cover syntax and MX checks, which is real but shallow filtering. They typically skip the SMTP probe, catch-all detection, and retry logic on greylisted domains, which is where the expensive errors live. At sub-cent pricing for paid verification at volume, the cost difference is trivial compared to one damaged sending domain.

Should I delete catch-all addresses or send to them?

Send to them, but only from isolated mailboxes and domains, and only where the address pattern is corroborated by confirmed addresses at the same company. Deleting all catch-alls means discarding a large share of mid-market B2B. Sending to them from your primary domains means gambling those domains on unverifiable data.

Does verifying my list improve deliverability?

It protects deliverability rather than improving it. Verification lowers hard bounces, which prevents reputation damage, but it does nothing for authentication, IP and domain reputation, sending volume ramp, or content. A perfectly verified list sent from misconfigured infrastructure still lands in spam.

How often should I re-verify a list I bought or built months ago?

Re-verify any address more than 30 days old before it sends, and verify in batches timed to each send rather than all at once upfront. B2B data decays continuously as people change roles and companies change mail providers, so the age of the verification matters as much as the quality of it.