Email verification

Where this lives. Sign in and open /verify in the app.

What it does

Verify emails checks a file of addresses and hands you the results, on purpose without turning any of it into a lead, a company, or a list. As the page puts it, the file is "checked, reported on, and deleted when you say so." This makes it the place to test a bought list or a scraped export before it goes anywhere near a campaign. If you actually want the platform to create leads from a file, use the Import as leads instead link in the page header, which is a separate flow.

Each uploaded file becomes a batch. A batch is verified address by address against the receiving mail server, and every address ends up in one of five result buckets: valid, invalid, accept-all, risky, or unknown. You can re-check unknowns, download results by category, or apply a batch's verdicts onto matching leads already in your CRM.

Before you start

• Have a CSV or plain text file ready, one address per line. Addresses are pulled out from anywhere in the file, so extra columns do not need to be removed first.
• Deciding whether to verify or import matters here: verifying never creates records, importing does.
• Batches are removed automatically 30 days after they are created, so download anything you need before then.

Set it up, step by step

1. Click Choose a file and pick a .csv or .txt file.
2. The file is read in your browser and its addresses are extracted, then uploaded in batches of up to 10,000 at a time for large files. Verification starts automatically once the upload finishes.
3. A notice confirms what was queued, for example "Checking 4,200 addresses, 15 duplicates skipped, 3 malformed lines ignored."
4. While a batch is queued or running, its card shows "X of Y answered." If some addresses are waiting on a "try again later" response from their mail server (greylisting), the card shows how many and when the next retry runs. Retries follow a ladder of 5, then 15, then 45 minutes, and a gateway that keeps dropping the connection is rested longer between tries. Click Retry now to bring the next retry forward instead of waiting.
5. When a batch finishes, its status changes to done and result pills appear: a count each for valid, accept-all, invalid, and, if any occurred, risky, unknown, duplicates skipped, and malformed. A per-provider table (Google Workspace, Microsoft 365, Proofpoint, Barracuda, Mimecast, Yahoo, GoDaddy, Zoho, Other) breaks the same counts down by mail provider.
6. If a finished batch has unknown addresses, click Re-check N unknown to requeue just those and confirm. They go back through the full check from the start.
7. To carry a batch's verdicts onto leads already in your CRM that share the same addresses, click Apply results to leads (or Apply results so far while the batch is still running) and confirm. A lead the platform has probed more recently than this batch keeps its own result; nothing is created or deleted, and each change is recorded in the lead's verification history.
8. Download results at any point using the Deliverable, Valid only, Invalid, or Everything links under the batch.
9. Click Delete on a batch to remove its addresses and every result immediately, or leave it to expire on its own.

What you should see

A finished batch shows a green valid pill, a red invalid pill, and an amber accept-all pill (plus risky and unknown pills only when those results occurred). Hovering the accept-all pill explains that the domain accepts every address at SMTP time and that no verifier can confirm the mailbox actually exists without sending mail to it; it is deliverable, with bounce risk, not a failed check. Applying results shows a message such as "Applied to 380 leads (12 kept a newer probe): 310 valid, 70 invalid."

Common problems

• Google Workspace shows mostly accept-all: this is expected on domains where Google accepts every address at SMTP time and bounces later. The page calls this out directly when it happens: "no verifier can tell a real mailbox from a typo" on those domains, and it records that honestly rather than guessing.
• A batch seems stuck with addresses "waiting on a retry": this is the greylisting ladder (5, then 15, then 45 minutes) working as intended. Use Retry now if you do not want to wait.
• Unknown results after a batch finishes: these came from a resolver that was busy, a gateway that dropped the connection, or a server that never answered in time. Use Re-check N unknown to try them again.
• Deleting a batch: the confirmation is explicit that this removes its addresses and every result. That is the mode's core promise, and there is no undo.
• Leads not updating after Apply results: a lead keeps its own verdict if it was probed more recently than the batch you are applying. This is by design, not a bug.

Related

• Domains

Common questions

What does accept-all or catch-all mean?

The receiving domain accepts mail for every address, so no probe can prove an individual mailbox exists. It is a policy of that domain, not a fault in the check. Send to accept-all addresses in small volumes and watch what bounces.

Why verify before sending rather than after?

Because a hard bounce rate above about two percent reads to a provider as a bought or stale list, and it is the fastest way to lose a domain that has just finished three weeks of warm-up. Verification costs cents; the domain costs three weeks.

What should I do with unknown results?

Treat them as a separate, smaller send rather than dropping them. Unknown usually means the receiving server would not answer the probe, which is common at well-defended domains and says nothing about the person.

Read next

• Lists, leads and companies
• Cold email deliverability

Last updated September 19, 2026. Written by the team that operates the platform.