Email validation is the process of checking whether an email address is correctly formatted, real, and able to receive mail, before you send to it. A validation tool runs each address through a short series of tests and returns a verdict, usually valid, invalid, catch-all or unknown, so you can drop the bad ones before they turn into bounces.

The reason to bother is that a bounce costs more than the email it lost. Each one is recorded against the domain that sent it, and a run of them tells mailbox providers you mail addresses you never checked. The next campaign pays for that too, including the messages going to perfectly good contacts.

Most teams do validate. Where it slips is in the details: one pass at import and never again, catch-all results counted as valid, and a sign-up form that looks for an @ sign and nothing else. In each case the tool did what it was asked. The process around it is what failed.

TL;DR

• A full check runs four layers: syntax, the domain and its MX records, an SMTP conversation that asks the recipient's server about the mailbox without sending anything, and flags for addresses that exist but cause trouble (catch-all, role, disposable, known spam traps).

• MX validation is only the second of those layers. It proves the domain can take mail and says nothing about whether this person's mailbox exists.

• Act on each result according to where the address came from. Invalid and disposable addresses come off every list. On a cold list, catch-all and unknown results wait for a re-check or go out last in a small batch, while on a sign-up form they can usually pass.

• Bounces are what validation prevents. Aim for the under-2% bounce rate Amazon SES recommends, and pause any cold inbox that passes about 3% hard bounces, because the list is almost always the cause.

• Validate when the list is built, again right before each send, and live on forms. A browser's email field checks the format only, so a form needs a real-time validation call or a confirmation email behind it.

• A clean result lowers bounce risk without removing it. Catch-all servers, servers that won't answer and unverified vendor accuracy figures (ZeroBounce advertises 99.6%) all leave a gap, and validation has no effect on inbox placement.

What an email validation tool actually tests

Every validator works through the same layers, cheapest first. Each one catches a kind of bad address the layer before it can't see, and an address only counts as valid once it has passed all of them.

Syntax: is it shaped like an address?

The first pass checks the format. One @ sign, something before it, a plausible domain after it, no spaces or characters that aren't allowed. It also enforces limits most people never think about: the SMTP standard, RFC 5321, caps the part before the @ at 64 octets. Syntax failures are mostly typos and broken imports, such as a comma where a dot should be or two addresses pasted into one cell, and they cost nothing to catch.

Domain: can it receive mail at all?

Next the tool looks the domain up in DNS. If the domain doesn't exist, or publishes a record declaring that it accepts no mail, every address on it is dead, whoever it belongs to. This layer is MX validation, and it has its own entry because the rules are less obvious than they look (a domain with no MX record can sometimes still receive mail). For email validation, the point is that this step rules out domains, not people.

Mailbox: does this inbox exist?

The deepest layer opens a connection to the domain's mail server, introduces itself as a sender, names the address as a recipient and hangs up before any message is sent. If the server rejects that recipient, the mailbox doesn't exist. If it accepts, the mailbox very likely does.

Servers don't have to cooperate, though. RFC 5321 lets sites switch off VRFY, the old command that once answered "does this user exist?" directly, and tells them to reply with a neutral 252 code rather than a yes or a no. Validators work around that by using the recipient step instead, and some servers keep that answer vague as well. Those are the addresses that come back unknown.

Risk flags: addresses that exist and still hurt you

A mailbox can be real and still a poor idea to email. Most validators flag four kinds:

• Catch-all addresses, on domains whose server accepts mail for any name. The validator can't tell a real mailbox there from a made-up one.

• Role addresses such as info@, sales@ or support@, which land in a shared inbox with whoever triages it, rarely the buyer you wanted.

• Disposable addresses from temporary inbox services, created to grab a download or a free trial and abandoned soon after.

• Known spam traps, addresses kept only to catch senders working from bad data. Amazon SES notes that even a small number of trap hits can do real harm to a sender's reputation, and that the organizations running traps keep the addresses confidential, so a validator can only flag the ones it has found.

Reading a validation report and deciding what goes out

A validation run gives every address a label. Vendors name them differently, but NeverBounce's five are typical: valid, invalid, disposable, catchall and unknown, with role and trap flags on top in many tools. What you do with each label depends on where the address came from.

The vendors say as much. NeverBounce's API reference suggests letting valid, catch-all and unknown results through at the point of entry and blocking only disposable and invalid ones. That makes sense for a form, where the person typing the address almost certainly owns it. A cold list has nobody vouching for it, so the same labels need stricter handling.

The labels only help if two more things happen. Write each result back to the contact record with the date of the check, because a sequencer that only knows "valid" can't tell yesterday's check from one last spring. And count only valid addresses toward your coverage rate. A catch-all address fills the email field without giving you anyone you can reliably reach.

Why a bounce costs more than one lost email

Mailbox providers watch bounce rates because careless senders tend to have high ones. Amazon SES says so directly in its sending review FAQ: providers and anti-spam groups use high bounce rates to detect bad sending practices, and those rates can move mail into the spam folder. Its own guidance is to keep your bounce rate below 2%.

For cold email we watch a stricter line, per inbox. Once a single inbox passes about 3% hard bounces, it stops sending and the list behind it gets checked, because slowing the inbox down won't fix bad data. Gmail's and Yahoo's sender rules lean the same way, and email deliverability goes through them.

The cost lands on your sender reputation, and that belongs to the domain, not to the list that caused the trouble. A brand-new domain in your cold email infrastructure has no history to absorb a bad week, so its first campaigns should carry only addresses that came back valid.

When to validate: building the list, before each send, and on forms

A validation result describes an address on the day you checked it. People leave jobs, companies move to new domains and old mailboxes get closed, and your spreadsheet hears about none of it. That's data decay, and it's the reason a single check is never enough.

While the list is being built

The cheapest place to stop a bad address is before it reaches the CRM. During list building, put the validation step directly after the email-finding step, so every address data enrichment turns up is tested before anyone relies on it. In a Clay table that's one more column, calling a validator such as ZeroBounce, NeverBounce or DeBounce. Only valid results move on to the CRM, and the rest stay in the table with their label, so nobody imports them by accident later.

Built this way, the check runs on every row without anyone remembering it, which is what lets prospecting workflows run on their own at volume.

Right before each send

Run the list again just before it goes into a sequence. A list built three weeks ago has had three weeks to decay, and a segment pulled from the CRM may contain addresses that last passed a check a year ago. Our rule of thumb is that if the last check is older than the campaign brief, the list gets checked again.

Between campaigns, a scheduled sweep of the whole database keeps old records from piling up. That sweep belongs to your wider data hygiene routine rather than to any one campaign.

On forms, as people type

A form field marked as an email input does very little. The WHATWG HTML standard, which browsers follow, defines its own simplified address format and openly calls it a willful violation of RFC 5322, the email format standard. All the browser confirms is that the text looks like an address. It has no idea whether the domain or the mailbox exists.

So a form needs something behind the field: a real-time call to a validator when the form is submitted, or a confirmation email the person has to click. Amazon SES recommends double opt-in for new sign-ups and asking people to type their address twice. For demo and contact forms, a real-time check that blocks invalid and disposable addresses and lets everything else through is usually enough, and it stops a mistyped domain from creating a lead nobody can ever answer.

What a passing email validation result can't promise

Validation removes most of the avoidable bounce risk. It doesn't remove all of it, and it has nothing to say about what happens after a message is delivered.

Some results are best guesses by design. A catch-all domain says yes to every name, so an address on it can bounce days later or disappear without any bounce at all. Some servers accept a recipient during the check and reject the real message afterward. Others answer slowly or not at all, which is how you end up with unknowns.

Accuracy figures deserve the same caution. ZeroBounce's homepage advertises 99.6% accuracy without saying which addresses, which mix of domains or which period that number describes, so read it as a sales claim, not a measurement. The measurement that matters is yours: validate a list, send a small first batch, and count hard bounces per inbox. If a list that came back clean bounces above 2%, either the source or the validator isn't doing what it claims.

Validation also stops at the address. It can't tell you whether the person still works at the company, which is what contact verification adds on top. And it has no influence on whether a delivered message reaches the inbox or the spam folder. Your inbox placement rate depends on authentication, sending pace, content and reputation, and a perfectly validated list can still land in spam if those are off.

In short

Email validation answers one narrow question, whether an address can receive mail, and it answers it in layers: format, domain, mailbox, risk. That narrowness is its strength. The check is cheap, fast and easy to automate, and it removes the bounces that do the most avoidable damage.

The judgment sits around the tool. Decide what each label means on a form and on a cold list, check again before every send, and trust your own bounce numbers over any vendor's accuracy figure. Teams that get this right hardly think about validation at all, because their bounce reports stay dull.

It's one of the first gates in any system that turns lists into pipeline, and the outbound people worth learning from won't send a list that hasn't just been checked.

When Nebor sets this up for a client, the validation step lives in their own Clay tables, forms and sequencer, with each result written back to the CRM, and the client keeps a one-page note on what every label triggers once the build is handed over.

Frequently asked questions