How to Verify an Email List Before Cold Email

Should you verify email list addresses before every cold campaign? Yes, because every address that bounces tells mailbox providers you do not know who you are writing to — and the penalty lands on your sending domain, not on the one campaign. Verification checks each address against the mail server responsible for it, flags the ones that will hard-bounce, and marks the ones that cannot be confirmed either way, so you only send to mailboxes that are actually accepting mail.

The short version of the workflow: scrape or collect your addresses, deduplicate them, run them through an SMTP-level check such as the Livescraper Email Address Verifier immediately before sending, segment by result, send only to the confirmed addresses, and ramp up volume slowly. Done consistently, it is the most reliable way to reduce bounce rate on cold outreach. The rest of this guide explains why each step matters, what verification really checks, where it stops being able to help, and how to read the output without throwing away good addresses.

Why verify your email list before every cold campaign?

Mailbox providers judge senders on behaviour, and bounces are one of the clearest signals they have. A legitimate sender emailing people who asked to hear from them rarely hits non-existent mailboxes. A sender working from a stale or bought list hits them constantly. When your bounce rate climbs, providers start treating your domain with suspicion: more of your mail goes to spam, some is throttled, and in bad cases it is blocked outright. Once that reputation is damaged, it takes weeks of careful sending to rebuild, and every campaign in the meantime underperforms.

The large providers have made their expectations explicit. Google's email sender guidelines, for example, require bulk senders to authenticate their mail and keep the spam rate reported in Postmaster Tools below 0.3%. Bounces are not the same metric as spam complaints, but they travel together: lists full of dead addresses are usually lists of people who did not expect the email. Common industry guidance is to keep hard bounces under about 2% of a send, and ideally well under 1%. Treat those as working thresholds rather than published limits — the point is that a cold list straight from a scraper or an old CRM export can easily blow through them on its own.

Cold email is especially exposed for three reasons. Lists decay — people change jobs and mailboxes close, so a list that was clean in spring is not clean in autumn. Cold senders usually lack the engagement history that cushions a marketing newsletter. And a bounce on a new or lightly used sending domain counts for more than it would on an established one. Verification is the cheapest step in the whole outbound stack that directly protects the asset you cannot easily replace.

What does email verification actually check?

"Verification" covers a ladder of checks, from trivial to genuinely informative. Knowing which rung a tool reaches tells you how much to trust it.

Syntax

Is the address well-formed — one @, a valid domain part, no illegal characters? This catches typos and scraping debris like info@example.com.Contact. It costs nothing and proves very little; a perfectly formatted address can point at a mailbox that has never existed.

Domain and MX records

Does the domain exist, and does it publish MX records saying which servers accept its mail? A domain with no mail setup cannot receive email, so this removes dead and parked domains. It still says nothing about the specific mailbox.

SMTP mailbox probe

This is the check that matters. The verifier connects to the domain's mail server and begins a delivery conversation up to the point of naming the recipient, without sending a message. The server's response to that recipient — accepted, rejected as unknown, or deferred — is the best available evidence of whether the mailbox exists today.

Catch-all (accept-all) domains

Some domains are configured to accept mail for any address at all, real or not. Their servers say yes to everything during the probe, so the verifier cannot confirm whether this particular mailbox exists. A good verifier tells you the domain is catch-all rather than pretending the address is confirmed.

Disposable and role addresses

Disposable addresses come from throwaway inbox services and are usually valid but worthless for outreach. Role addresses — info@, sales@, office@ — reach a shared inbox rather than a named person. Neither is a bounce risk on its own, but both change how you should treat the address.

The limits: what verification cannot tell you

Verification is useful and routinely oversold. Be clear about its boundaries before you rely on it.

• Catch-all domains cannot be confirmed. By design, the server accepts everything, so the probe has nothing to distinguish. Some of those addresses will bounce later, after the server has accepted and then rejected the message internally.
• Greylisting and server policy. Many servers temporarily defer unfamiliar connections, or refuse to answer probes at all as an anti-harvesting measure. The honest result is "cannot validate", not "invalid". Retrying later sometimes resolves it; sometimes it never will.
• It is a point-in-time answer. A mailbox that accepts mail today can be closed next month when someone leaves. Verify immediately before a send, not once a year.
• It is not a deliverability guarantee. Reaching the inbox also depends on your authentication (SPF, DKIM, DMARC), your sending reputation and your content. Verification removes one failure mode — writing to mailboxes that do not exist — not all of them.

What does the Livescraper Email Address Verifier return?

The Email Address Verifier is the simplest service in the Livescraper catalogue to run: an address is the whole input. You paste up to 1,000 addresses per run and each comes back with a status checked at the mail server, rather than guessed from the shape of the address. The documented status detail for a working mailbox reads SMTP validated.

Real exports carry eight columns per address:

Learn the status vocabulary on the free tier

One thing we deliberately do not do is publish a tidy, closed list of status values. The reference documents the status field and shows RECEIVING for a working mailbox, but it does not enumerate every value the field can take, and the four statuses above are what has been observed in real output — not a guaranteed set. The practical answer takes about a minute: before you build segmentation rules, run a handful of addresses you already know the answer for — your own working mailbox, a colleague's, a made-up address at your own domain, a role address — through the free tier. You will see the actual values and how status_details explains them, and you can write your rules against what the tool really returns.

Do not treat "unknown" as a failure

In the sample behind the column list above, unknown was the single most common status — usually a mail server that refuses to confirm either way, which status_details then explains. Deleting every unknown would throw away addresses that are perfectly fine. Always read status together with status_details.

Verify email list, then send: the full workflow

1. Build the list from a fresh source. For local and small-business outreach, the usual route is a Google Maps pull for the categories and areas you sell to, then the Email & Contact Scraper to read published addresses off each business's website. Our guide to collecting verified contact information for local businesses covers that end of the pipeline in detail.
2. Deduplicate. Lowercase and trim every address, then remove exact duplicates. The same address often appears on several pages of one site, or across a chain's location pages. There is no reason to pay to verify it twice, and no reason to email it twice. If your list started as Maps data, the techniques in cleaning and deduplicating Google Maps data handle the business-level duplicates first.
3. Remove your suppression list. Strip out anyone who has unsubscribed, objected or bounced before. These must never be mailed again, regardless of what a verifier says.
4. Verify immediately before the send. Split the list into runs of up to 1,000 addresses and run each through the Email Address Verifier. If the campaign starts next week, verify next week, not today.
5. Segment by result. Turn the output into a small number of buckets with clear rules (see the next section).
6. Send only to the confirmed segment in the main campaign. Everything else gets a different treatment or nothing.
7. Warm up and throttle. Ramp volume gradually on any new sending domain or mailbox, spread sends through the day, and cap daily volume per mailbox. Watch bounces and replies on the first few hundred sends before releasing the rest.
8. Feed results back. Add hard bounces to your suppression list, and re-verify any address that sits unused for more than a few weeks before you mail it.

How to segment the verification results

Each time you verify email list output, the job is the same: turn eight columns into a decision per address. Write these rules once, against the vocabulary you saw in your free-tier test, and apply them to every list.

• Send. status confirms a working mailbox (for example receiving), deliverable is 1, catch_all is 0 and disposable is 0. This is your main campaign.
• Suppress. invalid or undeliverable, or a status_details such as "Mailbox not found". Do not mail these, and add them to your suppression list.
• Drop disposable addresses. disposable is 1. Even if the mailbox exists, nobody is reading it for business.
• Catch-all: send carefully or not at all. catch_all is 1. Some of these are real; you cannot know which. If you mail them, do it in a small separate batch from a well-warmed mailbox, after the main send, and stop if bounces rise.
• Unknown: read the reason. If status_details says the server declined to confirm (policy or IP block), re-verify later or treat like catch-all. Never mix these into the main send unexamined.
• Role accounts: decide on purpose. role_account is 1. For small local businesses, info@ is often the owner's main inbox and a perfectly good target. For larger companies it lands in a shared queue, so a named contact will usually perform better. Tag them so you can compare results.

A worked example: 4,000 restaurants

Say you sell an online ordering system and pull 4,000 independent restaurants across two regions from Google Maps, then run their websites through the Email & Contact Scraper. You end up with, illustratively, 2,700 addresses. After lowercasing and deduplicating — many restaurants publish the same address on their contact, reservations and imprint pages — you have 2,300 unique addresses. Your suppression list removes another 40.

You split the remaining 2,260 into three runs of up to 1,000 and verify them the morning before the campaign. Suppose the results come back roughly like this: about 1,450 confirmed and deliverable, 260 invalid or undeliverable, 330 on catch-all domains, 190 unknown with a server-policy explanation, and about 30 flagged disposable. You send the 1,450 in the main campaign, ramped over several days. You suppress the 260 permanently. You re-verify the 190 unknowns two days later and move any that confirm into the main send. The catch-alls go out last, in a small batch, from a mailbox with a good track record.

Without that step, roughly one address in nine would have been a near-certain bounce, sent in a single blast from a fresh domain — exactly the pattern that gets a domain throttled. With it, your first send goes to people whose mailboxes exist, and your bounce rate reflects the decay you cannot see rather than the decay you could.

What does email list cleaning cost?

Every new Livescraper account gets its first 500 rows free, one time, with no credit card — which is also how you learn the status vocabulary before you rely on it. After that, verification costs $0.002 per address, roughly $2 per 1,000, pay-as-you-go with no subscription. Credits do not expire and there is no monthly reset.

In the example above, verifying 2,260 addresses costs about $4.52, or around $3.52 if your free rows are still unused. Compare that with weeks of reduced inbox placement on a damaged domain, and verification is the least expensive insurance in the outbound stack. For guidance on what to write once the list is clean, see how to build better cold email campaigns using Google Maps data.

Compliance: verification is light-touch, outreach is not

Checking an address asks a mail server a question; it does not read a mailbox, collect anything new about the person, or add anyone to a list, and Livescraper exports auto-delete after 30 days. But an email address that identifies a person is personal data, and the obligations that really matter sit on the outreach itself: a lawful basis for contacting people, telling them where you got their details, honouring objections and erasure requests, and following each country's direct-marketing rules — CAN-SPAM in the US, PECR in the UK, and the stricter consent rules in markets such as Germany. This is not legal advice; check the rules for each country you send into.

Conclusion

Taking the time to verify email list addresses is the step that keeps a cold campaign from damaging the domain you send it from. A real check goes beyond syntax and MX records to the mail server itself, flags catch-all, disposable and role addresses, and is honest about what it cannot confirm. Build a fresh list, deduplicate, verify immediately before sending, segment on status and status_details rather than deleting everything that is not a clean yes, send to confirmed addresses only, and ramp volume gently. Start with the free 500 rows in the Email Address Verifier, test it on addresses you know, and write your rules against what it actually returns.

Related reading: How to Build Better Cold Email Campaigns Using Google Maps Data, How to Collect Verified Contact Information for Local Businesses, How to Find Business Emails from Google Maps at Scale.