Free email verifier: check if a mailbox exists

What this verifier actually does

Paste a work email. We ask that domain's mail server whether the mailbox exists, without sending a message into the inbox. You get back verified, invalid, catch-all, or unknown — not a green tick that really means "the domain has an MX record."

That is the whole product. Syntax checks are free in every programming language. Domain checks pass for zzzzz@company.com at almost every company that receives mail. Neither of those should be sold as verification. See the three levels if you want the longer version.

A few free checks a day run here with no account, shared with the finder. After that, sign up. A credit is spent only on a verified mailbox. Invalid, catch-all, unknown, and checking the same address again are free.

When you already have the address

The finder is for "I have a name and a company." This page is for "I have an address and I do not trust it."

Typical sources that look clean and are not:

• A CSV from a conference scanner.
• A Clay / Apollo / ZoomInfo column labelled "email" with no status next to it.
• A colleague's "I found it on their website" Slack message.
• Your own sequencer's suppression list, which often still contains catch-alls from a previous vendor.

Run those through this tool (or bulk) before they touch a sending domain. A high bounce rate is not a list problem you notice later. It is a reputation problem you notice on the next campaign.

What we check, in order

1. Syntax. If it is not an email, we stop. This is not verification. It is hygiene.
2. MX. If the domain does not receive mail, we stop. company.com with no MX is a website, not an inbox.
3. Catch-all probe. We try a local-part that cannot be a real person. If the server accepts it, the domain is a catch-all and we say so. We do not then pretend the original address is verified.
4. Mailbox probe. We ask about the specific local-part you pasted. Accept without catch-all → verified. Reject → invalid. No clear answer → unknown.

We never deliver the message. The SMTP conversation is closed before DATA.

How to read the result

Verified. Safe to send, from a deliverability point of view. Legal and welcome are still your problem.

Catch-all. The address might be right. The server will not tell you. If you send it, you will not get a bounce, which is worse than a bounce: you will get silence, and you will not know why. We do not charge you. Do not mix catch-alls into a warmup list.

Invalid. Do not send. Hard bounces are what mailbox providers count against the sending domain.

Unknown. The server would not give a verdict (greylisting, a firewall, a risky result, a host that drops SMTP probes). Retry later, or treat it as unverified. Unknown results are free.

Catch-alls, at length

A catch-all domain is a deliberate mail-server setting: "accept any local-part, dump the unknown ones in a shared mailbox or discard them." IT teams turn this on so they do not have to publish a public directory. Sales teams hate it because every guessed address "works." The short definition is the glossary entry.

No honest verifier can confirm a person on a catch-all. Anyone who returns verified on zzzzz@that-domain.com is lying to you, or they only checked the domain.

What you can do instead:

• Send only if you have a second signal (they replied on LinkedIn, they are on a webinar list that used SSO).
• Use a different domain at the same company — sometimes brand.com is catch-all and corp.brand.com is not.
• Skip the row. A smaller verified list outperforms a bigger unconfirmed one. Every time.

What this will not catch

• Full mailboxes and vacation responders. Those are soft issues at send time, not existence issues.
• Role addresses you should not cold-email. info@, sales@, jobs@ can be verified and still be a waste. The verifier does not have an opinion about your targeting.
• Whether the human still works there. A mailbox can exist for months after someone leaves, forwarding to a catch-all or to a manager.
• Spam-folder placement. Authentication — SPF, DKIM, DMARC — and sending-domain reputation decide inbox vs spam. This tool does not.

A worked example (fictional)

You paste jane.doe@company.com.

• Server rejects zzzzz@company.com and accepts jane.doe@company.com → verified.
• Server accepts both → catch-all.
• Server rejects jane.doe@company.com → invalid. Try the finder in case the pattern is jdoe@ instead.

Jane Doe is not a real person at that domain.

Bulk, API, and this page

This page is for one-off checks. For a list:

• Bulk email finder accepts a CSV of names or existing addresses.
• The email finder API is the same wallet as the dashboard. There is no separate verification SKU.
• Inbound webhooks exist for tools that can POST JSON but cannot set an API header.

Rate limits follow the plan, documented in the Clay guide because that is where people usually hit them.

Common mistakes

• Verifying a personal Gmail and calling the result a "work email."
• Re-running the same catch-all fifty times hoping for a different answer. The domain is the catch-all, not the row.
• Uploading a list to a sequencer first and verifying the bounces after. The damage is already done.
• Trusting a Chrome extension that highlights "verified" on LinkedIn without saying what it checked.

Related reading

• Why “verified” email finders often aren’t
• What a high bounce rate actually costs you
• Catch-all checker if you only need the domain-level question