How to Verify Emails Before Outreach

Cold outreach leaves less room for a dirty list than a newsletter does. A newsletter audience is usually built from people who entered their own mailbox. An outreach file is often assembled from many sources, over many weeks, by many hands. If you verify emails before outreach, you are not trying to write a better opener. You are trying to keep nonexistent mailboxes from using up sends, creating hard bounces, and teaching receiving systems to distrust the domain you send from.

This guide is email verification for cold email in the narrow sense: how to prepare a list before outreach when the addresses already sit in a sheet or CRM. It skips discovery methods, pattern guessing, and sequence writing. If you need the product definition, open what an email verifier is. The file workflow sits in bulk email verification. Bounce-rate context lives in reducing bounce rate with list verification. Catch-all rows are covered separately in catch-all emails. The tool itself is described on the email verifier page.

What this guide covers, and what it leaves out

In scope:

Checking addresses you already stored.
Reading the result file with a first-contact send in mind.
Suppressing undeliverable rows before anyone presses send.
Understanding why wasted mail is more expensive when daily sending caps are involved.

Out of scope:

Collecting or discovering addresses.
Writing subject lines, personalization, or follow-up cadences.
Choosing a sequencer or inbox-rotation setup.

If a paragraph would teach you how to build the list, it does not belong here. The only list that matters is the one you brought with you.

Why first-contact lists punish bad rows faster

Newsletter bounces are still harmful, but the addresses often came from a form the person completed. Outreach files more often include older exports, conference scans, CRM history, and enrichments that were never re-checked. A well-formed string is common. A living mailbox is not guaranteed.

Receiving systems also see first-contact mail as more suspicious than mail to people who already replied. A cluster of hard bounces in that stream is a sharp signal. Outreach bounce prevention starts by taking undeliverable rows out before the first batch, not by inspecting a bounce report after the domain is already in trouble.

Verification does not make a stranger want the message. It only stops you from spending a send on an address that cannot receive one.

Check the file you already have

Work in this order:

Freeze a copy. Export the outreach segment from the CRM or sheet you will actually send from. Note the date and who produced the file.
Deduplicate. One person with three copied rows still produces one conversation, but three verification checks and three chances to trip a provider if you mail every copy.
Run a verifier on the unique addresses. kukudze takes a pasted list or an uploaded CSV or TXT file. It has no public API today, so you check lists on the site. Pick the email column on the upload screen, then download the results as a CSV.
Split the output before anyone imports it back. Invalid rows, unknown rows, and catch-all rows should never share a single “ready” tab.
Return only the sendable set to the sequencer or inbox you use, and store the suppressed set where a teammate cannot paste it back in.

If the file is small, a one-by-one check is fine. If it is a campaign file, use bulk cleaning so every row gets the same rules. A syntax-only glance (missing @, obvious broken domains) is a reasonable first skim. It is not enough for outreach bounce prevention, because most harmful rows look correctly written.

On kukudze’s pricing page, Free is $0 with 100 checks a month and lists up to 50 rows. That fits a small first-contact batch, not a big file. Starter ($9 a month, 2,000 checks, lists up to 1,000 rows), Pro ($19 a month, 5,000 checks, lists up to 5,000 rows) and Agency ($39 a month, 15,000 checks, lists up to 15,000 rows) are coming soon and cannot be bought yet. Every plan runs the same 4 checks: format, whether the domain can receive mail, the mailbox answer, and whether the domain accepts all mail. Plans differ only in checks per month and rows per list. kukudze does not flag throwaway inboxes, trap addresses or role inboxes, so filter those by hand if they matter for this sheet.

Read the results with outreach in mind

A first-touch send should be stricter than a long-running newsletter in one respect: you have no prior engagement to offset a bounce cluster. Use a conservative default:

Invalid: Remove from the sendable file. Do not “test a few” to see what happens. Those tests are the bounces you were trying to avoid.
Valid (or deliverable): Eligible from a mailbox point of view. You still need a lawful basis to email the person and a message that matches that basis. Verification does not create permission.
Unknown: Retry the check. If the row stays unknown, keep it out of the first batch or mail a tiny watched slice, not the whole leftover pile.
Accept-all (also called catch-all): This domain took the recipient without proving the inbox. For outreach, isolate these rows. Some teams skip them on a first touch because the bounce risk is concentrated and unexplained. Others send a smaller, slower slice and stop if bounces appear. Either policy is clearer than mixing them into the main file. See catch-all emails.
Disposable: Default to skip. A temporary inbox is a weak place to start a conversation you hope to continue.
Role addresses: A function inbox (info@, sales@) can still accept mail and remain a poor first-contact target. That is a targeting choice, not a verification failure. kukudze does not flag role addresses, so filter prefixes like info@ in your sheet and use that to segment, not to invent a bounce prediction.

Keep the original status labels with the contact. When someone asks why a row never entered the sequence, the file should answer without a meeting.

Sending limits that make wasted mail expensive

Invalid addresses do not only bounce. They can interrupt your ability to send anything else.

Gmail’s sending-limits help page describes an error that says you hit a sending limit when a personal Gmail account goes past 500 recipients inside one message or past 500 messages across a day. The same page describes a second error, “Messages you sent couldn’t be delivered,” which can appear when many outgoing items fail because an address is invalid or the destination bounces them. Google notes that sending can resume after a wait of up to a day, and it tells readers to review recipients’ addresses ahead of time so those addresses are current.

If you send through work or school, Google Workspace sending limits apply instead. That page states that after a user hits a limit, they cannot send new messages for up to 24 hours, while they can still receive mail and use other Google services. Daily limits are applied over a rolling 24-hour period. The published maximum messages per day is 2,000 for standard paid accounts and 500 for trial accounts (the page lists several other recipient caps as well). Those figures can change; read the live table when you plan volume.

Two practical consequences follow for email verification for cold email:

Every invalid row you attempt is not only a bounce. On a capped inbox it is also one of the day’s sends you cannot use on a deliverable contact.
A burst of invalid recipients can trigger the “couldn’t be delivered” condition Google describes, which pauses sending for hours you probably intended to use.

Google’s bulk sender guidelines are aimed at people who send large volumes to Gmail users. They still reinforce the same habit this article is about: confirm addresses rather than discovering problems at send time. Authentication, spam-rate thresholds, and one-click unsubscribe rules on that page are separate obligations. Verification does not satisfy them.

What a clean file still cannot promise

A verified outreach list can still fail in ordinary ways:

The person does not want unsolicited mail.
The message is irrelevant or misleading.
Authentication is missing, so filters distrust the domain even when the mailbox exists.
The mailbox was closed after you checked it.
You exceeded a provider cap with otherwise fine mail.

Think of verification as outreach bounce prevention for the “no such mailbox” class of errors. It cannot replace permission, relevance, or technical setup, and it is not a lesson in how to build the audience. Bring a list you already have a reason to contact. Then make sure the rows on it can receive mail before you spend the day’s sends.

FAQ

Does this article show how to collect prospect addresses?

No. It starts after the addresses already exist in your sheet or CRM. Nothing here describes discovery, pattern guessing, or scraping. If you need help with verification itself, stay on this page and the related kukudze guides linked above.

Should I mail catch-all rows on a first touch?

Not in the same batch as proven-valid rows. Catch-all means the inbox was not proven. If you decide to contact some of those domains, isolate them, keep the volume modest, and stop if bounces appear. Skipping them on the first touch is a reasonable default.

Will verification stop every outreach bounce?

No. It reduces bounces caused by addresses that do not exist or cannot accept mail. It does not prevent blocks based on content, reputation, or policy, and it cannot forecast a mailbox that disappears tomorrow. Read new bounce notices and feed hard failures back into suppression.

How do Gmail sending limits relate to list quality?

On a personal Gmail account, Google caps daily sends and notes that many invalid or bouncing recipients can produce a delivery error that pauses sending. Cleaning the file first protects both your bounce rate and the limited number of messages you are allowed to attempt. Workspace accounts have higher published caps, but the same logic applies: do not spend the quota on dead rows.

Do I need a dedicated verifier if my tool already has a check?

If the tool you already use publishes a mailbox-level check and you trust its labels, you may not need a second vendor. If it only reviews format, or if its allowance is shared with unrelated features you do not want draining the cleaning budget, run the file through a dedicated verifier such as kukudze before the first send.

Wrapping up

To verify emails before outreach, take the list you already have, check it, and keep invalid rows out of the first send. Read unknown and catch-all results as incomplete proofs, not as free permission to mail everyone who is left. Google’s own sending-limit documentation tells you to check addresses before you send and describes how invalid recipients can stall an account. A verifier exists to do that check without using your daily quota as the test. Bring the file. Clean the file. Then send only what can be delivered.