Email verification is the process of checking whether an email address is correctly formed, belongs to a domain that can receive mail, and is likely to accept your message, all before you hit send. A typical verifier runs a series of checks: syntax, domain and MX records, known disposable or role-based patterns, and sometimes a live conversation with the receiving mail server. The goal is to keep bad addresses off your list so they never turn into bounces, wasted sends, or reputation damage.

This guide explains what each check does, why mailbox providers care about the results, and where verification stops being reliable.

Why email verification matters

Every address you send to that doesn’t exist produces a hard bounce. A few are normal. A lot of them tell mailbox providers and your sending platform that you aren’t managing your list, which is one of the oldest signals of spam.

The thresholds are not hypothetical. Amazon SES, for example, publishes its limits: it recommends keeping your bounce rate below 5%, places accounts under review at 5% or higher, and may pause sending at 10% or higher. SES counts only hard bounces in that rate, which are exactly the “address doesn’t exist” failures that verification is designed to catch.

Mailbox providers say the same thing in their own words. Yahoo’s sender best practices tell senders to monitor bounces, remove invalid recipients promptly, and use confirmed opt-in to reduce invalid addresses. The M3AAWG Sender Best Common Practices (version 4.0, updated August 2026) notes that large volumes of permanent failures usually point to a poorly managed registration process or an old list, and that they can hurt the sending IP’s reputation.

Verification is cheap insurance against all of that. It also has practical side benefits:

Fewer lost customers. A typo like jane@gmial.com at checkout means the receipt, shipping notice, and password reset all disappear.
Cleaner data. Sales and support teams stop chasing contacts that were never reachable.
Lower costs. Most email platforms bill by contact or by send, so dead addresses cost money every month.

How email verification works, step by step

Most verifiers run checks in order from cheapest to most expensive. If an address fails an early step, there’s no reason to run the later ones.

1. Syntax check

The first pass confirms the address is structurally valid: one @, a non-empty local part before it, and a domain after it that looks like a real hostname. Good verifiers also enforce length limits. RFC 5321 caps the local part at 64 octets and a path at 256 octets including the angle brackets, which is why RFC 3696 erratum 1690 puts the practical maximum for a full address at 254 characters.

Syntax checks catch the obvious junk: john.smith@, john smith@company.com, john@@company.com, or a phone number typed into the email field. If you want the details of what the standards actually allow, see our guide to email address syntax under RFC 5321 and 5322.

2. Domain and MX record check

Next, the verifier asks DNS whether the domain exists and where it accepts mail. That’s what MX (mail exchanger) records are for. A healthy domain returns something like this:

$ dig +short MX example-company.com
10 mx1.example-company.com.
20 mx2.example-company.com.

If a domain has no MX records, RFC 5321 says senders should fall back to the domain’s address (A or AAAA) record, treating it as an implicit MX. A domain can also explicitly say “I accept no mail” by publishing a null MX record, defined in RFC 7505:

example.net.    IN MX 0 .

An address on a domain that doesn’t resolve, or that publishes a null MX, can’t receive email. This single check catches a large share of the bad addresses you’ll find in old lists, because companies shut down, rebrand, and let domains expire.

3. Domain typo check

Some addresses pass syntax and even point at a real domain, but obviously aren’t what the person meant. gmial.com, yaho.com, and hotmial.com are common examples. A typo check compares the domain against well-known providers and flags close misspellings with a suggestion. This matters most on signup and checkout forms, where you can ask the person to fix it on the spot.

4. Disposable and temporary domain check

Disposable email services hand out short-lived inboxes that work for a few minutes or hours. The address is technically deliverable when someone signs up, but it won’t be later. Verifiers keep lists of these domains and flag matches. Whether you block them depends on your use case; a free trial or coupon form usually should, a support contact form might not.

5. Role-based address check

Addresses like info@, sales@, support@, and admin@ usually deliver to a shared inbox or a group of people rather than one person. These names are long established; RFC 2142 (1997) lists INFO, MARKETING, SALES, SUPPORT, ABUSE, and others as standard mailbox names. Role addresses are real and often deliverable, but they tend to have lower engagement and a higher chance that someone who never opted in hits “Report spam.” Verifiers flag them so you can decide.

6. Free provider detection

Knowing whether an address is on a free consumer provider (Gmail, Yahoo, Outlook.com, iCloud) or a company domain doesn’t make it more or less valid. It’s a data point: B2B teams use it for lead scoring, and fraud teams use it alongside other signals.

7. SMTP mailbox check (optional, and limited)

The deepest check connects to the domain’s mail server and starts a delivery conversation without sending a message:

220 mx1.example-company.com ESMTP
HELO verifier.example.org
250 mx1.example-company.com
MAIL FROM:<check@verifier.example.org>
250 2.1.0 OK
RCPT TO:<jane.doe@example-company.com>
550 5.1.1 User unknown
QUIT

A 550 with enhanced status code 5.1.1 means “bad destination mailbox address” under RFC 3463, so that address is almost certainly dead. A 250 means the server accepted the recipient at that moment, which is a good sign but not proof.

The catch is that many servers don’t give honest answers here. Catch-all domains accept every address. Some servers greylist unknown senders with a temporary 4xx reply. Large providers may accept at RCPT TO and bounce later. We explain the details in how SMTP email verification works and its limits.

What each check catches: a quick reference

Check	Catches	Misses
Syntax	Malformed addresses, spaces, double `@`, too-long addresses	Well-formed addresses that don’t exist
Domain / MX	Dead or misspelled domains, null MX domains	Dead mailboxes on live domains
Typo detection	`gmial.com`, `yaho.com`, and similar	Typos in the local part (`jhon@`)
Disposable	Throwaway inbox services on known lists	Brand-new disposable domains
Role-based	`info@`, `sales@`, `admin@` and similar	Shared inboxes with personal-looking names
Free provider	Consumer webmail domains	Nothing; it’s a label, not a verdict
SMTP mailbox	Mailboxes the server explicitly rejects	Catch-all domains, greylisting, providers that accept then bounce

Email verification vs. confirmation emails

Verification is a prediction. The only way to know for certain that a person controls an address is to send them a message and have them act on it, such as clicking a confirmation link. That’s double opt-in (also called confirmed opt-in), and M3AAWG describes it as the highest opt-in standard because it stops typos and maliciously submitted addresses from being added to your mailings.

The two work best together. Verify at the form to catch typos and junk while the person is still on the page, then send a confirmation email to prove ownership.

Where email verification fits in your workflow

You’ll get the most value from verification at three points:

At the point of capture. Check addresses in real time on signup, checkout, and lead forms. This is where you can still fix typos. See real-time email verification for signup forms.
Before a big send to an older list. If a list hasn’t been mailed in months, or came from an import or a CRM migration, verify it in bulk first. Our bulk email verification guide walks through the process.
On an ongoing schedule. Lists decay as people change jobs and abandon inboxes. How often you re-verify depends on how fast your list churns, and on how much of it you mail regularly.

Verification doesn’t replace bounce handling. Your sending platform will still report bounces, and you should still suppress those addresses. Our post on what belongs on a suppression list covers how to set that up.

What email verification can’t do

It’s worth being clear about the limits, because some marketing around verification oversells it.

It can’t guarantee delivery. A valid address can still reject your mail for reputation, authentication, or content reasons.
It can’t guarantee inbox placement. Spam filtering happens after acceptance and depends on your sender reputation and engagement.
It can’t reliably detect every spam trap. Recycled spam traps are often real, accepting mailboxes. Avoiding them is mostly about how you collect and age addresses.
It can’t tell you whether someone wants your email. A perfectly valid address that never opted in can still generate complaints.

If you want to check a handful of addresses right now, our free email verifier runs the syntax, domain and MX, disposable domain, role-based, free provider, and typo checks described above. It does not open an SMTP connection to the mailbox, so it tells you whether an address can plausibly receive mail, not whether a specific inbox exists.

FAQ

Is email verification the same as email validation?

People use the terms loosely, but they usually mean different depths of checking. Validation typically refers to format and syntax checks, while verification adds DNS, domain, and sometimes mailbox-level checks. We break down the difference in email validation vs. email verification.

Does email verification send an email to the person?

No. Standard verification checks DNS records and, in some tools, talks to the receiving mail server without completing a delivery. Nothing reaches the recipient’s inbox. Confirmation emails (double opt-in) are a separate step that does send a message.

Can email verification tell me if a Gmail address exists?

Only partially. Syntax, domain, and typo checks work for Gmail like any other domain, and some SMTP-based tools get a response from Google’s servers. But no external check is a guarantee, and the only certain proof is the person clicking a confirmation link you sent.

How accurate is email verification?

Checks like syntax, MX lookups, and null MX detection are deterministic, so they’re right when they say an address can’t receive mail. Mailbox-level results are less certain because of catch-all domains, greylisting, and servers that accept first and bounce later. Treat a mailbox-level “valid” as a strong hint, not proof.

Will verifying my list fix my deliverability?

It removes one major cause of problems: bounces from dead addresses. It won’t fix missing authentication, poor content, or low engagement. Those need fixing separately, starting with SPF, DKIM, and DMARC.

What Is Email Verification and How Does It Work?