Email validation checks whether an address is formatted correctly, for example that it has one @, a legal local part, and a plausible domain. Email verification goes further and checks whether the address can actually receive mail, by looking up the domain’s DNS records and sometimes asking the mail server about the specific mailbox. Validation is fast and runs anywhere, including in the browser. Verification needs network lookups and is where you find out that jane@acme-old-name.com points at a domain that no longer exists.

The industry doesn’t use these words consistently, so it’s worth knowing what’s behind the labels before you pick a tool or write code.

Email validation: is it shaped like an email address?

Validation is a pure string check. It doesn’t touch the network. Given an input, it answers: “Could this possibly be an email address?”

A good validator checks:

Structure: a local part, one @, and a domain.
Allowed characters: letters, digits, and a set of symbols such as ., +, -, _ in the local part; letters, digits, hyphens, and dots in the domain.
Dot rules: no leading, trailing, or consecutive dots in the local part.
Length: a local part of 64 octets or fewer, per RFC 5321, and a total address length of 254 characters or fewer, per RFC 3696 erratum 1690.

Where validation runs

Validation belongs everywhere you accept an address: the browser, your API, your import scripts. In HTML, the built-in check is one attribute:

<input type="email" name="email" required>

The browser applies the “valid email address” rule from the WHATWG HTML standard. The spec openly calls that rule a “willful violation” of RFC 5322, because the full RFC grammar permits quoted strings and other forms no one types into a signup form. In JavaScript, the equivalent pattern from the spec looks like this:

const EMAIL_RE =
  /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;

function isValidFormat(email) {
  return email.length <= 254 && EMAIL_RE.test(email);
}

Notice that this pattern accepts user@localhost (no dot in the domain). For a public signup form you’ll usually want to require a dot. We dig into these trade-offs in email validation regex and, for front-end code specifically, how to validate an email address in JavaScript.

What validation can’t tell you

Every one of these passes a format check and is useless:

jane@acme-corp-old.com — the domain expired two years ago.
jane@gmial.com — a typo for Gmail.
x7k2p@ + a disposable inbox domain — gone in an hour.
john.smith@company.com — John left the company, and his mailbox was deleted.

That’s what verification is for.

Email verification: can it receive mail?

Verification uses network lookups to judge whether an address is deliverable. A typical verification pipeline adds these checks on top of validation:

Domain exists: the domain resolves in DNS.
MX records: the domain publishes mail exchanger records, or at least an address record that RFC 5321 treats as an implicit MX. A null MX (MX 0 .), defined in RFC 7505, means the domain accepts no mail at all.
Typo detection: the domain is compared against major providers to catch gmial.com and friends.
Disposable domain detection: the domain is compared against known temporary-inbox services.
Role-based detection: the local part is checked for shared names like info, sales, support, and admin, many of which are listed in RFC 2142.
SMTP mailbox check (optional): some verifiers connect to the mail server and issue RCPT TO to see whether that specific mailbox is accepted.

Here’s what step 2 looks like in Node.js:

import { resolveMx } from "node:dns/promises";

async function hasMailServer(domain) {
  try {
    const records = await resolveMx(domain);
    // RFC 7505 null MX: a single record with exchange "" (or ".")
    if (records.length === 1 && (records[0].exchange === "" || records[0].exchange === ".")) {
      return false;
    }
    return records.length > 0;
  } catch (err) {
    // ENOTFOUND = domain doesn't exist; ENODATA = no MX records
    return false;
  }
}

This simplified version treats “no MX” as a failure. A stricter implementation would fall back to A/AAAA lookups before rejecting, as RFC 5321 describes.

What verification still can’t tell you

Verification is a better prediction, not a guarantee:

Catch-all domains accept every address during SMTP, so a mailbox check returns “accepted” for anything.
Greylisting, described in RFC 6647, deliberately returns temporary 4xx errors to unknown senders.
Accept-then-bounce servers say yes during the SMTP session and send a bounce later.
Ownership is never proven. Only a confirmation email clicked by the recipient shows that a real person controls the inbox.

Our article on email verification accuracy covers how to read results with these limits in mind.

Email validation vs verification: side by side

	Email validation	Email verification
Question it answers	Is this formatted like an email address?	Can this address likely receive mail?
Network access	None	DNS lookups, sometimes SMTP
Speed	Microseconds	Milliseconds to seconds
Where it runs	Browser, server, scripts	Server or third-party service
Catches	Missing `@`, spaces, illegal characters, too long	Dead domains, null MX, typos, disposable and role addresses, some dead mailboxes
Misses	Everything about deliverability	Catch-all results, greylisted servers, ownership
Cost	Free, built into most frameworks	Free for DNS-level checks; paid services for high-volume SMTP checks

Why the terms get mixed up

You’ll see vendors call their product an “email validation API” that performs DNS and SMTP checks, and others call a simple regex check “verification.” Some platforms use “verify” to mean sending a confirmation link. None of these is wrong exactly; the words just aren’t standardized.

When evaluating a tool, ignore the label and ask:

Does it check syntax and length limits?
Does it look up MX records and handle null MX?
Does it detect disposable and role-based addresses?
Does it suggest corrections for typo domains?
Does it attempt SMTP mailbox checks? If so, how does it report catch-all and unknown results?

The answers tell you more than whether the product page says “validation” or “verification.”

Which one do you need?

Most teams need both, at different layers.

Use validation on every input field and API endpoint. It’s free, instant, and prevents garbage like n/a or none@none from entering your database.

Use verification at the moments where a bad address costs you something:

On signup, checkout, and lead forms, where you can ask the person to fix a typo before they leave. See real-time email verification for signup forms.
Before sending to an imported or aging list. See the bulk email verification guide.
Before cold outreach, where every bounce hits a fresh domain’s reputation.

Use a confirmation email when you need proof of ownership, such as for account creation, newsletters, or anything with legal consent attached. M3AAWG’s Sender Best Common Practices calls confirmed opt-in the highest standard because it stops typos and maliciously submitted addresses from reaching your list.

If you want to see the verification layer in action, paste an address into our free email verifier. It runs format validation plus domain and MX checks, typo detection, and disposable, role-based, and free-provider flags. It doesn’t connect to the mailbox over SMTP, so it can’t confirm that a particular inbox exists, but it will tell you quickly when an address can’t receive mail at all.

A practical layered setup

Here’s a setup that works well for most SaaS products and online stores:

Browser: type="email" plus a light regex for instant feedback.
On blur or submit: call your back end, which runs MX, typo, and disposable checks. Show a suggestion like “Did you mean gmail.com?” rather than a hard error.
On account creation: send a confirmation link. Don’t add the address to marketing lists until it’s clicked.
On every send: process bounces and suppress hard-bounced addresses. Our post on bounce classification explains which bounces to act on.

Each layer catches what the previous one missed, and none of them alone is enough.

FAQ

It’s enough to stop malformed input, but not typos on real domains or addresses on dead domains. Adding a server-side MX and typo check catches most of the rest without adding friction. Pair it with a confirmation email if you need proof of ownership.

Does email verification send an email?

No. Verification uses DNS lookups and, for some tools, a partial SMTP conversation that ends before any message is delivered. Sending a confirmation link is a separate step, often called double opt-in.

Should I validate emails on the client or the server?

Both. Client-side validation gives instant feedback, but anyone can bypass it, so always repeat validation on the server. Verification (DNS and beyond) should run on the server because it needs network access and, if you use a paid API, a secret key.

Can a valid email address still bounce?

Yes. A perfectly formatted address can bounce because the mailbox was deleted, the domain stopped accepting mail, or the receiving server rejected your message for policy reasons. That’s why verification and bounce handling both matter.

Email Validation vs Email Verification: What's the Difference?