Free Email Validator

The four levels of email validation

Email validation is not one thing. It is a stack of four checks, each one more invasive than the last. Most free tools stop at level one or two and call it "validation." Production verifiers go all the way through level four. The answer you get depends on how deep the tool went.

1. Syntax validation. Does the address parse against RFC 5322? Runs in your browser, takes microseconds, requires no network.
2. Domain validation. Does the domain exist? One DNS lookup, takes about 50ms.
3. MX validation. Does the domain have a mail server configured? Another DNS query against the MX record type.
4. SMTP / mailbox validation. Does the mail server actually accept this specific address? Requires opening a TCP connection to the recipient mail server and walking through SMTP commands. Takes 1-5 seconds and can be blocked by the receiver.

A syntax-only validator will tell you `definitely-not-real@gmail.com` is valid because it parses. An MX-aware validator will agree because gmail.com has MX records. An SMTP-level validator will return "accept-all" because Gmail does not reveal which mailboxes exist over SMTP. None of them are wrong, they are just answering different questions.

Level 1: syntax validation (RFC 5322)

The basic shape of an email address is `local-part@domain`. That is mostly what people think of. The full RFC 5322 grammar is far more permissive: quoted local-parts, comments inside parentheses, IP-literal domains in square brackets, dotted-atoms with restricted characters. Most basic regex checkers reject valid syntax that the RFC allows.

Syntax validation is fast and free. It runs entirely in the browser, requires no network round-trip, and scales to millions of addresses per second. The trade-off is depth: a syntactically valid address can still fail every subsequent check. Use it for form input validation where you need instant feedback, or as the first filter on a bulk list. Our Email Syntax Checker does this layer with bulk support.

There is also a stricter sibling, RFC 5321, which governs how addresses appear in SMTP envelopes. RFC 5321 disallows some of the rarer forms that RFC 5322 permits in message headers. For most real-world cases you can validate against 5322 and accept what mail clients actually generate.

Level 2: domain validation

A single DNS lookup confirms the domain exists. This catches typos like `gmial.com` or `outlok.com`, abandoned domains that have lapsed, and made-up domains that look plausible but were never registered. Domain validation runs in 20-100ms depending on resolver and is essentially free to perform.

What domain validation does not catch: a registered domain with no mail setup. Plenty of domains are registered for redirects, parking pages, SSL certificates, or domain squatting and never receive mail. You need to check MX records to know if mail is even possible.

Level 3: MX validation

MX records list the mail servers responsible for receiving mail at a domain. A domain without MX records cannot receive mail, full stop. Some mail servers fall back to the A record if MX is missing, but most modern senders refuse to do that, and per RFC 7505, a domain can explicitly opt out of email with a "null MX" record (`0 .`).

MX validation is where you find out whether a domain is genuinely set up for email. Run a MX record check on any domain and you will see the priority, hostname, and detected provider. If the answer comes back empty, no mail will reach that domain regardless of how well-formed the address is.

Level 4: SMTP and mailbox validation

This is the only level that touches the recipient mail server. The validator opens a TCP connection on port 25 (or 587 if testing submission), runs through the SMTP handshake, and asks RCPT TO for the address being verified. The server's response tells you whether the mailbox accepts mail.

The conversation looks like this:

220 mx.example.com ESMTP
EHLO check.example.org
250-mx.example.com Hello
250 PIPELINING
MAIL FROM:<sender@check.example.org>
250 2.1.0 OK
RCPT TO:<alice@example.com>
250 2.1.5 OK
QUIT
221 2.0.0 Bye

No DATA command is sent and no message body ever crosses the wire. The recipient mailbox sees nothing. The server's response to RCPT TO is the verdict: 250 means yes, 550 means no, 5xx codes mean a permanent failure, 4xx codes mean a temporary one.

Why SMTP validation is hard

• Major providers (Gmail, Outlook, Yahoo) accept almost everything at SMTP and sort the spam afterwards. They return 250 for addresses that do not exist.
• Catch-all domains accept every address regardless of mailbox existence. About 7-10% of business domains are configured this way.
• Greylisting temporarily rejects new senders with a 421 code. A single-shot probe misreads this as a failure.
• Rate limiting on the recipient side blocks repeated probes from the same IP. Bulk verification without IP rotation gets throttled fast.
• Some mail servers blacklist IPs that send too many RCPT TO without DATA, calling it harvesting.

Production verifiers handle this by maintaining clean sending IPs, rotating across pools, falling back to a second verification engine when the first cannot return a verdict, and reporting "unknown" or "accept-all" instead of guessing. Valid Email Checker uses a two-engine fallback for exactly this reason.

What "valid" actually means

When a validator says an address is valid, it means the recipient mail server accepted RCPT TO at the moment of the check. That is the strongest claim possible without sending real mail. It does not mean:

• The mailbox is monitored. Role accounts and abandoned addresses accept mail too.
• The message will reach the inbox. Spam filters apply after acceptance.
• The mailbox will still exist tomorrow. Addresses get disabled, full, or deleted.
• The recipient wants to hear from you. Consent is separate from deliverability.

Validation tells you whether the plumbing works. Engagement, permission, and content tell you whether the message will land.

Validation for signup forms vs bulk lists

These are two different problems with two different tradeoffs. Signup forms care about latency: validation needs to feel instant to the user. Bulk lists care about throughput: validation needs to finish in minutes, not hours.

Signup form validation

• Run syntax validation client-side so the user sees errors immediately.
• Catch common typos with suggestion logic: "Did you mean gmail.com?" for `gmial.com`.
• Send a confirmation email (double opt-in) instead of relying on real-time SMTP checks. Double opt-in is the only way to confirm both deliverability and consent.
• Skip SMTP checks during the signup flow. They are slow, can fail intermittently, and frustrate legitimate users when greylisting kicks in.

Bulk list validation

• Run all four levels. Bulk lists usually contain decay, typos, and disposable addresses.
• Use a service with IP rotation. Single-IP probing gets throttled at scale.
• Set a quality threshold. Most teams remove anything classified as Invalid, Disposable, or Spam Trap; treat Catch-All and Role Account based on segment.
• Re-validate annually. Address decay is roughly 22% per year, so a list cleaned 12 months ago is no longer clean.

Common invalid email patterns

Some patterns show up repeatedly in cleaning a list. Worth being able to recognise:

• Typo domains: `gmial.com`, `gnail.com`, `gamil.com`, `outlok.com`, `yahooo.com`. Catch with suggestion logic before SMTP.
• Test data left in production: `test@test.com`, `asdf@asdf.com`, `aaa@aaa.com`, `none@none.com`. These either fail syntax or land on parked domains.
• Disposable addresses: 10minutemail, mailinator, guerrillamail, tempmail. Syntactically valid, technically deliverable, but no real person reads them.
• Role inboxes with no owner: `noreply@`, `donotreply@`, `bounces@`. Valid but pointless to mail.
• Honeypot traps: addresses planted on the public web by anti-spam services to catch scrapers. Hitting one tanks your reputation.
• Dead employee accounts: `alice@employer.com` after Alice quit and her mailbox got purged. Server returns 550.

Validation and email authentication

Cleaning the list is half the inbox-placement problem. The other half is proving the message came from where it says it came from. Three records on your sending domain:

• SPF — lists which IPs are authorised to send mail for the domain.
• DKIM — cryptographically signs each message so receivers can verify it has not been tampered with.
• DMARC — tells receivers what to do if SPF or DKIM fail (none, quarantine, or reject).

Valid Email Checker runs the full deliverability audit against your sending domain so you can confirm everything passes before a campaign. If authentication fails, even a perfectly cleaned list will see degraded inbox placement.

When validation disagrees with reality

Sometimes a validator marks an address as valid and your campaign still bounces. Or marks an address as invalid and it actually works. A few reasons this happens:

• The validation ran days or weeks before the send. Mailboxes change state.
• The recipient server greylisted the validator probe but accepted the real send (or vice versa).
• The recipient server blocks the validator IP for excessive probing but accepts mail from your ESP.
• The address sits on a catch-all domain. Server accepted RCPT TO but discards the mail because the mailbox does not exist.
• The address sits on a server that responds differently to verification probes than to actual mail — some providers explicitly do this.

Validation reduces bounces, it does not eliminate them entirely. A clean list should land at under 2% hard bounces, which most ESPs treat as healthy. Below 0.5% is excellent. Trying to chase zero bounces with validation alone is a losing battle.