How to See If an Email Address Is Valid (2026 Guide)

“Is this email address valid?” is a deceptively simple question. The honest answer is: it depends what you mean by valid. A string that looks like an email might be:

• Syntactically wrong (bob@gmail — no TLD)
• Syntactically fine but the domain doesn’t exist (bob@gmial.com)
• Syntactically fine, domain exists, but mailbox doesn’t (bob@gmail.com for a deleted Gmail account)
• All of the above pass, but the address is on a spam-trap list (instant deliverability damage)

Each level requires more work to check. This guide walks through all four, explains when each is enough, and gives you a decision framework for which checks to run.

Level 1: Syntax check

The cheapest check. You’re just verifying the string is shaped like an email address: something before an @, a domain after, a TLD on the end.

A practical regex for this:

^[^s@]+@[^s@]+.[^s@]{2,}$

This rejects the most common typos:

• Missing @: bobgmail.com
• Missing TLD: bob@gmail
• Whitespace in the address: bob smith@gmail.com
• Multiple @ symbols: bob@@gmail.com

What it does not check:

• Whether the domain exists
• Whether the mailbox is real
• Whether the address is currently active

Use when: form field validator, instant feedback as the user types. Sub-millisecond, no network call.

Don’t use when: this is your only check. Syntax-valid addresses still bounce constantly.

How long this takes

Less than a millisecond. Runs entirely on the user’s machine.

Unicode and IDN edge cases

Modern email allows non-ASCII characters in both the local part (josé@example.com) and the domain (bob@café.com, which DNS sees as the Punycode form xn--caf-dma.com). A naïve regex that only allows [a-zA-Z0-9] rejects these as invalid, even though they are perfectly legitimate.

Two practical positions to take:

• Permissive: accept anything that has a single @, non-empty parts on both sides, and at least one dot in the domain. Defer the harder checks (DNS, mailbox) to Level 2+. This is what most modern validators do.
• Strict: use a library that implements RFC 6532 (internationalized email) instead of rolling your own regex. In JavaScript, validator.js and email-validator both support it; in Python, email-validator; in Ruby, truemail. See the format of an email address guide for the full character rules.

The takeaway: if your regex hardcodes ASCII, you will reject real users with accented names. In 2026, that’s a noticeable share of signups in any global product.

Level 2: Domain check (MX record lookup)

Once the syntax is good, the next question is whether the domain after the @ actually accepts mail. The DNS record that controls this is called an MX record (mail exchange). Domains without one cannot receive email.

Checking this requires a DNS lookup. In most programming languages, this is one library call:

• JavaScript (Node): dns.resolveMx(domain)
• Python: dns.resolver.resolve(domain, "MX") via dnspython
• PHP: checkdnsrr($domain, "MX") (built-in)
• Ruby: Resolv::DNS.new.getresources(domain, Resolv::DNS::Resource::IN::MX)

What this catches that syntax doesn’t:

• Typo’d domains (bob@gmial.com has no MX records)
• Made-up domains used as throwaway addresses
• Recently expired domains

What it still doesn’t catch:

• Mailboxes that don’t exist on a valid domain
• Catch-all domains that accept everything
• Disposable email services (Mailinator has MX records — its whole business)
• Spam traps

Use when: stricter signup validation, list cleaning before a campaign send. Takes 10-50ms per check.

Don’t use when: you need to know if a specific mailbox exists, not just whether the domain accepts mail.

For a deeper dive into how the MX lookup actually works (including A-record fallback and priority handling), see MX record lookup.

Level 3: Mailbox check (SMTP probe)

To know whether bob@gmail.com actually exists as a mailbox — not just whether gmail.com accepts mail — you have to ask the mail server directly. This is called an SMTP probe.

The mechanics: open a TCP connection to the domain’s mail server, send the SMTP handshake (HELO, MAIL FROM, RCPT TO), and watch the response. If the server responds with 250 to RCPT TO, the mailbox exists. If 550, it doesn’t.

In practice this is much harder than it sounds:

• Mail servers don’t trust strangers. Most will greylist your IP, slow-respond, or blocklist you after a few probes. Run too many and your sender reputation tanks across the board.
• Catch-all servers say yes to everything. A 250 response from a catch-all domain doesn’t mean the mailbox exists. You have to probe a few obviously-fake addresses to detect this.
• Latency varies wildly. A fast server responds in a few hundred milliseconds. A greylisted server can take 30+ seconds.
• False positives are common when servers refuse to confirm or deny mailbox existence (some explicitly do this for privacy).

This is why most production signup flows delegate SMTP probing to a verification API instead of running it themselves. The API provider maintains a clean IP pool, batches probes intelligently, and absorbs the operational pain.

Use when: signup forms, lead-list cleaning, anywhere a bounce would be costly. Use a verification API, not your own code.

Don’t use when: you’re trying to validate hundreds of addresses synchronously inline. SMTP probes don’t scale that way.

How long this takes

A single mailbox check typically completes in 200-500ms. Worst-case (slow server + greylisting) it can take 30 seconds.

Level 4: Reputation / deliverability check

The final layer is whether an address can be safely emailed. Even a real, deliverable mailbox can be:

• A disposable inbox (Mailinator, Guerrilla Mail, 10minutemail) — accepts mail but the user won’t see it
• A spam trap — addresses seeded by mailbox providers to catch lazy senders; emailing one nukes your sender reputation
• A role-based account (info@, support@, noreply@) — usually unmonitored, often filtered

These checks usually require maintained lists. A verification API will:

• Match the domain against an updated disposable-domain list
• Match the local part against role-based patterns
• Match the full address against known spam traps it has aggregated

Use when: marketing list cleaning, bulk signup verification, anywhere sender reputation matters.

Role-account gotchas

The role-based check (info@, support@, sales@, admin@, noreply@, careers@) is one of the most common follow-up questions about validation. Two things to know:

• Role accounts are usually real mailboxes. A Level 3 SMTP probe will return 250 for info@somecompany.com because someone, somewhere, is receiving that mail. The “risky” label comes from deliverability, not existence.
• Block them at signup, allow them at sales. For consumer signups, role accounts almost always belong to bots or shared inboxes — block them. For B2B prospecting and outbound, sales@ or partnerships@ is often the intended recipient — allow them, just don’t send marketing-style content. Truelist surfaces this with email_state: "risky" + email_sub_state: "is_role" so you can branch on it.

A related trap: disposable detection lags. New disposable services launch weekly. A validator that hasn’t refreshed its disposable list in six months will let many through. When picking a provider, ask how often they refresh — daily is fine, monthly is not.

What changed in 2024-2026: Gmail and Yahoo’s sender requirements

If your post-signup plan includes sending marketing email, validation isn’t just about avoiding bounces anymore. In February 2024 Gmail and Yahoo started enforcing stricter rules on bulk senders (anyone sending 5,000+ messages a day to their users):

• SPF, DKIM, and DMARC are now required for the sending domain.
• One-click unsubscribe (List-Unsubscribe-Post header) is required for marketing mail.
• Spam complaint rate must stay under 0.3% — over 0.1% is a warning zone.

Every bad address that hard-bounces, every disposable that complains, every role-account auto-reply that loops — all of it counts against a reputation budget that’s now much tighter. The practical implication: Level 2 (MX) is no longer optional for any sender doing more than a few hundred emails a day, and Level 4 (disposable and spam-trap filtering) is mandatory if you send marketing email. See why emails bounce back, email sender reputation score, and what is SMTP authentication.

Mobile and autofill patterns

A growing share of signups happens on mobile, where the input UX is fundamentally different from desktop:

• Validate on blur, not on every keystroke. Autofill pastes the whole address at once and per-keystroke validation flickers an error state mid-paste.
• Disable autocorrect transforms with autocomplete="email" autocapitalize="none" spellcheck="false" on the input. Autocorrect happily turns gmail.com into email.com.
• Soft-warn, don’t block, on Level 2/3 failures. A flaky cell connection makes the MX or SMTP check time out — hard-blocking submit punishes the network, not the user. Run the full check server-side on submit.
• Treat a confirmation code as the final source of truth for transactional flows. iOS QuickType suggestions are sometimes the user’s secondary address (an old work email), and only an actual round-trip confirms ownership.

Putting the levels together

Most production validation does syntax + verification API in two calls:

1. On the client, run the regex syntax check as the user types. Instant feedback for typos.
2. On the server, call a verification API on submit. This runs MX, SMTP, disposable, and reputation checks in one network round-trip.

A small but important pattern: for the API call, skip the slow SMTP probe synchronously and queue it for async background processing. Truelist’s verify_inline endpoint supports this with the checks=syntax,mx,disposable,role parameter — sub-200ms response that’s good enough to unblock the user, plus you can run the full SMTP probe later via a background job.

curl -X POST 
  -H "Authorization: Bearer YOUR_API_KEY" 
  "https://api.truelist.io/api/v1/verify_inline?email=bob@example.com&checks=syntax,mx,disposable,role"

Response:

{
  "emails": [
    {
      "address": "bob@example.com",
      "email_state": "ok",
      "email_sub_state": "email_ok"
    }
  ]
}

email_state is the headline result (ok, email_invalid, risky, accept_all, unknown). See the email validation API guide for the full schema.

Picking your validation level

A decision table:

Scenario	Levels you need
Form field validator (instant feedback)	1 (syntax)
Reject typos on signup before backend hit	1 + 2 (syntax + MX)
Standard signup flow, no anti-fraud focus	1 + 2 + 4-lite (syntax + MX + disposable check)
Signup flow, want clean lists for marketing	All four (use a verification API)
Bulk-validate an imported CSV	All four (verification API, async)
One-off “is this address real?”	All four (use Truelist’s free verifier)

The most common mistake is using only Level 1. The regex is fine, but it lets through every disposable and every typo’d domain. Adding Level 2 catches 80%+ of typos for almost no cost (one DNS lookup). Adding Level 4 via an API closes the rest.

For language-specific implementations, see JavaScript email validation, Python email validation, or PHP email verification. For the API request/response details, see email validation API.

The 2026 provider landscape

The modern API options worth considering are Truelist, ZeroBounce, NeverBounce, and Kickbox. They all run the same core probes; quality differences come down to disposable-list freshness, accept-all handling, and pricing model.

Truelist is built for steady-state usage: flat monthly pricing with unlimited validations, a 100-validation free tier, and the verify_inline fast-path for sub-200ms inline use. ZeroBounce, NeverBounce, and Kickbox are credit-based — fine for one-off cleanups, noisy for continuous validation. Decide based on whether your usage is spiky (credits) or steady (flat). See the free email validation and bulk email verifier guides for more.

Frequently asked questions

How do I check if an email address is valid for free? Run the Level 1 syntax regex client-side, then call a free verification API for the deeper checks. Truelist offers 100 free validations. For ongoing one-at-a-time checks, the email address existence checker tool runs the same probes through a UI without an API key.

What’s the difference between email validation and email verification? The terms get used interchangeably. The rough convention: validation refers to Levels 1-2 (syntax and format), verification refers to Levels 3-4 (mailbox existence and reputation). A complete check covers both.

Can I tell if an email address is valid without sending an email? Yes, in almost all cases. The Level 1-3 checks determine deliverability without ever sending a message. The only thing they can’t confirm is whether the human at the inbox will read it — that still needs a transactional confirmation email.

Why do some valid email addresses still bounce? Three common reasons: the mailbox is over quota, the recipient server has greylisted your sending IP, or your sending domain reputation is low. None are validation failures — they’re delivery-time issues. See why emails bounce back.

Should I block role-based addresses (info@, support@) at signup? For consumer products, yes — they’re almost always bots or shared inboxes. For B2B sales tools, surface a warning but allow it. Branch on email_state: "risky" + email_sub_state: "is_role" instead of treating it as a hard reject.

How often should I revalidate my email list? Addresses go stale at roughly 2-3% per month. Revalidate any address you haven’t sent to in 90 days, and revalidate your full active list every 6 months. See email list cleaning services.