Free Email Verifier

✓ Email verification

Check a single email address end-to-end: syntax, domain, live mailbox, catch-all, disposable and role signals, with a confidence score.

No sign-up required Runs on our own infrastructure Also available via API
Try:

Runs on our diagnostic API. We don’t attach your input to an account for these free tools; short-lived rate-limit/security logs may exist, and requests are rate-limited per IP.

“Is this email address real?” sounds like a yes/no question, but a good answer has several layers. A string can be perfectly well-formed and still belong to a domain that vanished two years ago; a domain can have working mail servers and still reject the exact mailbox you care about; a server can accept every address you throw at it and tell you nothing useful in the process. A real email verifier works through all of that in order, and reports not just valid/invalid but how confident it is and why. That’s the difference between checking that an address looks like an email and checking whether a message to it would actually land.

Syntax validation is the floor, not the ceiling

The first gate is whether the address is even well-formed under RFC 5322 — a local part, an @, and a domain, with only the characters the spec allows and no stray spaces, double dots or missing pieces. This is cheap and instant, and it catches the fat-finger typos (name@gmail,com, name@@example.com). But it’s also where a lot of “validators” stop, and syntax alone proves almost nothing about deliverability. totally-made-up-person@gmail.com is valid syntax and a dead address. If you only need the format check — say, for inline form validation — use the dedicated email syntax validator. Real verification goes further.

Domain and MX: can the domain receive mail at all?

Next we look at the domain. A registered domain isn’t necessarily a mail-accepting one, so we query DNS for its MX records — the list of mail exchangers that handle inbound mail for that domain. No MX (and no usable A-record fallback) means there’s nowhere to deliver, and the address is undeliverable no matter how clean the syntax is. When MX records exist, we know which servers to talk to and in what priority order. You can inspect this layer on its own with the MX lookup tool; a lot of “email not working” tickets turn out to be a domain with broken or missing MX.

The SMTP conversation — asking without sending

This is the part that separates guessing from verifying. We open an SMTP connection to the domain’s highest-priority mail server and begin the same handshake any sending server would, defined in RFC 5321 — but we stop before anything is delivered:

>>> HELO verifier.example <<< 250 mx.recipient.com >>> MAIL FROM:<probe@verifier.example> <<< 250 OK >>> RCPT TO:<name@recipient.com> <<< 250 OK                 ← mailbox exists (or) 550 5.1.1 User unknown  ← mailbox does NOT exist >>> QUIT                    ← we disconnect here; no DATA, no message

The signal is in the server’s reply to RCPT TO. A 250 means the server is willing to accept mail for that mailbox; a 550 (user unknown / no such user) means it isn’t. Crucially, we never issue the DATA command, so no email is ever sent to the person — we hang up as soon as we’ve read the answer. You can watch this handshake yourself with the SMTP test tool. This live check is what lets a verifier flag addresses that are syntactically perfect but don’t exist.

Why 100% certainty is impossible

Mail servers are under no obligation to tell the truth, and many deliberately don’t — because the same RCPT TO trick is how spammers harvest valid addresses. Several honest ambiguities are baked into the system:

  • Catch-all (accept-all) domains reply 250 to every address, real or not, and sort it out internally later. Acceptance there proves the domain works, not that the specific mailbox exists — so we probe with a random address to detect the pattern and downgrade the result. See the catch-all checker.
  • Greylisting is a spam-fighting tactic where a server temporarily rejects the first attempt from an unknown sender (a 4xx “try again later”) expecting a legitimate server to retry. On a one-shot probe that reads as unknown, not invalid.
  • Blocked or rate-limited ports. If port 25 is filtered between us and the server, or the server throttles probes, we can’t complete the handshake and won’t pretend we did.

An honest verifier reports these as risk and uncertainty rather than inventing a confident answer. Anyone claiming 100% accuracy on every address is glossing over how SMTP actually behaves.

Quality signals: disposable, role and free-provider

Deliverability and desirability aren’t the same thing. An address can be perfectly reachable and still be one you don’t want on a list:

  • Disposable / throwaway — temporary inboxes (Mailinator, 10-minute-mail style services) used to get past signup walls. They accept mail today and evaporate tomorrow. Check these in isolation with the disposable email checker.
  • Role-based — shared functional mailboxes like info@, support@, sales@, admin@. They’re real, but they route to several people, attract more complaints, and are commonly suppressed by ESPs. More detail on the role-based checker.
  • Free-provider — Gmail, Outlook, Yahoo and friends. Not a problem by itself, but useful context when you expected a corporate signup.

Reading the result and the confidence score

We fold all of the above into one of four outcomes plus a 0–100 confidence score, so you can set your own threshold:

  • Deliverable — the mailbox accepted at RCPT TO on a non-catch-all domain. Safe to send.
  • Undeliverable — the server rejected the mailbox, or there’s no MX. Don’t send; it will bounce.
  • Risky — reachable but low-quality: catch-all, role or disposable. Send with caution, lean on engagement and double opt-in.
  • Unknown — the server gave no definitive answer (greylisting, timeout, blocked port). Neither valid nor invalid; retry later.

Bounces damage sender reputation, so the practical goal is to remove the undeliverables and treat the risky and unknown buckets deliberately. This single-address tool is ideal for spot checks and inline validation. To clean a whole list — thousands of addresses via API or CSV upload, with catch-all and disposable classification built in — create a free account (it includes free credits), and see the API docs for integration. When you’re auditing the sending side rather than a recipient, the email health check ties verification together with authentication and reputation.

Frequently asked questions

Can a catch-all address still bounce?
Yes — a catch-all domain accepts every address at SMTP time, so it can bounce later. Treat catch-all as risky and rely on engagement/double opt-in. See the catch-all checker.
What does an “unknown” result mean?
The server gave no definitive answer — usually greylisting, a timeout, or a blocked port. It’s neither valid nor invalid; retry later.
Do you send an email to verify?
No — we run the SMTP handshake and read the server’s reply to RCPT TO, then disconnect before DATA. No message is delivered.
Why is a role address (info@, support@) marked risky?
Role mailboxes route to several people and draw more complaints, so they’re flagged risky for marketing — not invalid.