Free email address checker.
Check one address for the failures you can catch without sending to it: syntax, whether the domain accepts mail at all, disposable domains, role accounts and freemail. Only an SMTP conversation confirms a specific mailbox exists, and a browser cannot open one, so this covers every step before that.
Privacy: this tool runs entirely in your browser. When you click Check, one DNS query for the domain you typed goes to Cloudflare's public DNS resolver (Google's as fallback). Nothing is stored, logged or sent to GrowthPal.
Verification at a glance
| Item | Value |
|---|---|
| Checked here | Syntax, whether the domain has a mail server, disposable domains, role accounts, freemail |
| Not checkable in a browser | Whether the specific mailbox exists. That needs an SMTP conversation from a server |
| Bounce rate to stay under | 2%, and comfortably under. A verified list runs close to zero |
| Catch-all domains | Accept mail to any address, so no verification can confirm a real mailbox behind one |
| Syntax specification | RFC 5322, which is far more permissive than most validators assume |
What is email verification?
Email verification is the process of establishing, without sending a real message, whether an address is likely to accept mail. It runs as a series of increasingly expensive checks, each one ruling out a different kind of failure.
The cheap checks are structural and run anywhere: is the address well-formed, does the domain exist, does it publish a mail server, is it a throwaway domain, is it a shared role mailbox rather than a person. The expensive check is a conversation with the receiving server that asks whether it would accept mail for that specific address.
The reason any of this matters is that inbox providers read bounce rate as a statement about how you built your list. A sender who does not know whether their addresses exist looks like a sender who scraped, and past roughly 2% everything else gets read more sceptically, including the campaigns that were working.
How to read your check result
The tool gives one overall verdict and then the signals behind it.
Do not send means a check failed outright: broken syntax, no mail server on the domain, or a disposable domain. These are not judgement calls.
Sendable with caveats means the address will probably accept mail but something about it is worth knowing first, usually a role account or a personal freemail address. Whether that matters depends on who you are selling to.
Passes every pre-send check means nothing failed at this level. It is not a guarantee the mailbox exists, and the tool says so in its own results rather than letting you assume otherwise.
That distinction is the whole point of the page. For one address, this is usually enough. For a list you are about to put volume behind, run a verification service that completes the SMTP step, because the difference between "probably fine" and "confirmed" is measured in bounce rate, and bounce rate is measured in reputation.
What each signal means
| Signal | What it means | What to do |
|---|---|---|
| Invalid format | The address is not well-formed. | Remove, or fix an obvious typo and re-check. |
| No mail server | The domain publishes no MX, so it cannot receive mail. | Remove. This is a guaranteed bounce. |
| Disposable domain | A throwaway inbox provider. | Remove. Nobody buying software signs up from one. |
| Role account | info@, sales@, support@ and similar reach a queue, not a person. | Remove for cold outbound. Some are seeded as spam traps. |
| Personal freemail | A consumer mailbox rather than a work address. | For B2B, find the work address instead. |
| Catch-all domain | The domain accepts every address, so nothing can confirm this one. | Treat as unconfirmed. It will not bounce, but it may not reach anyone. |
| Passes every check | No structural failure found. | Confirm with an SMTP-level service before putting volume behind it. |
The verification waterfall, and where each step runs
| Step | What it establishes | Runs where |
|---|---|---|
| Syntax | The address is structurally valid. | Browser |
| Domain and MX | The domain exists and accepts mail at all. | Browser |
| Classification | Disposable, role account or freemail. | Browser |
| SMTP probe | The receiving server would accept mail for this exact address. | Server-side service |
| Catch-all detection | Whether the domain accepts everything, making the probe meaningless. | Server-side service |
How to clean a list before a campaign
The order matters, because each step removes addresses the next step would otherwise waste money on.
- Deduplicate first, across the whole list. The same person at two spellings counts twice against you if both bounce, and looks like a bot if both deliver.
- Drop the structural failures. Bad syntax, domains with no MX, disposable domains. These need no judgement and no budget.
- Strip role accounts. Anything addressed to a function rather than a person. They rarely reply and some exist only to catch senders.
- Run the remainder through an SMTP-level verifier. This is the step a browser cannot do and the one that actually moves your bounce rate.
- Decide what to do with catch-all results. They will not bounce, so they are safe for reputation, but they may never reach a person. Segment them rather than mixing them in.
- Re-verify anything older than a quarter. People change jobs, companies get acquired and domains migrate, all without telling your database.
Common questions about email verification
Why can this not confirm the mailbox exists?
Confirming one specific mailbox needs an SMTP conversation with the receiving server, and a browser cannot open one. This catches every failure you can catch without it: broken syntax, a domain with no mail server, disposable domains and role accounts. For a full list, run a verification service before sending.
What is wrong with role accounts like info@ or sales@?
They reach a shared mailbox or a ticket queue rather than a person. They reply rarely, they are often watched by whoever handles abuse complaints, and some are seeded deliberately as spam traps. Mailing them costs reputation and returns almost nothing.
How clean does a list need to be?
Under 2% bounces, and comfortably under. That is where inbox providers start reading your sending as guesswork rather than knowledge. A properly verified list runs close to zero, which is the standard worth holding rather than the threshold.
Is a catch-all domain the same as a valid address?
No. A catch-all accepts mail to any address, so verification cannot tell a real mailbox from a typo. It will not bounce, which protects your rate, but it may never reach a human either. Treat catch-all results as unconfirmed rather than good.
How often should I re-verify a list?
Quarterly for anything you are still mailing, and always before a campaign that puts real volume behind an older segment. B2B data decays constantly through job changes, acquisitions and domain migrations, none of which produce a notification. A list that verified clean six months ago is not a list that is clean now.
Does a verified list guarantee I reach the inbox?
No. Verification protects you from bounces, which is a reputation problem, not a placement guarantee. Authentication, warmup, sending volume and whether people engage all decide placement afterwards. A clean list is the floor you build on rather than the thing that gets you read.