Valid Email Address
The verdict after an address clears syntax, domain, and mailbox checks.
Well-formed isn’t the same as valid — verification confirms all three.
Definition
A valid email address is one that passes syntax, domain, and mailbox checks: it is correctly formatted, its domain resolves with a working MX record, and its mailbox is confirmed to accept mail at the SMTP level. It is the positive verdict a verification engine returns only after an address clears every layer, not just one.
“Valid” is the word every sender wants next to their list, but most people use it loosely, as a synonym for “looks right.” A verification engine means something much stricter. Here is what the word actually has to earn before we attach it to an address.
What “valid” actually means
A common assumption is that a well-formed address like [email protected] is automatically valid. It is not. Real validity is a verdict, not a shape, and it only gets assigned after an address clears three separate layers. The first is syntax, structural rules under RFC 5321 and RFC 5322 that check for a legal local part, a single @, and a real-looking domain. The second is the domain layer: does the domain resolve at all, and does it carry a working MX record naming a server that is actually configured to receive mail. The third is the mailbox layer, where a live SMTP conversation with that server confirms the specific mailbox exists and is currently accepting mail.
Only an address that clears all three gets the valid label. Miss any one, and the correct verdict is invalid or risky, not a softened version of valid.
Why well-formatted doesn’t mean deliverable
Syntactically perfect but dead addresses are far more common than most senders assume, and they come from a few predictable sources. A typo in the domain is the biggest one: a name typed correctly sitting on gmial.com instead of gmail.com looks fine at a glance and fails the moment anything actually resolves the domain. Expired accounts are another: an employee leaves a company, IT deletes the mailbox, and the address keeps circulating in old lists, CRMs, and lead forms long after it stopped accepting mail. A third source is addresses that were never real to begin with, guessed from a name-pattern, typed wrong at signup, or entered as a placeholder just to get past a required field.
None of these show up in a syntax check, because the text is perfectly legal. They only surface once something checks the domain and the mailbox behind it, which is exactly why treating a well-formed address as a valid one skips the two checks that actually matter.
The catch-all edge case
The clearest example of syntax and validity diverging is a catch-all domain. A catch-all is configured to accept mail sent to any username at all, real mailbox or not, so the receiving server returns the same accepting response for [email protected] and for a made-up string that was never provisioned. Standard SMTP verification asks the server “does this mailbox exist?” and on a catch-all domain, the server always says yes.
That means an address on a catch-all domain can look valid — well-formed, a resolvable domain, an accepting server — and still not be confirmable with certainty. We do not round that up to valid. It gets flagged risky, paired with a confidence score built from signals a single SMTP ping cannot see, so the uncertainty is visible instead of hidden behind a false valid verdict.
Using the valid/invalid/risky spectrum in practice
The mistake we see most often is treating a verification result as a binary — send to valid, delete invalid — and stop there. That throws away the most useful part of the result: the risky middle. Risky addresses — catch-all, role-based, or otherwise unresolved with full certainty — are not confirmed-good and they are not confirmed-dead either. Lumping them in with valid inflates your list with unconfirmed mailboxes. Lumping them in with invalid throws away real, reachable contacts.
- Send confidently and immediately to addresses marked valid. They cleared every layer.
- Remove addresses marked invalid before you send. They failed a check that will not resolve on retry.
- Segment risky addresses by confidence score: send to the high-confidence ones on a normal track, and hold or warm up the low-confidence ones separately.
- Re-verify periodically, since a list that was mostly valid at capture decays as mailboxes get abandoned over time.
Handled this way, the spectrum becomes a tool for protecting sender reputation instead of a source of confusion. For teams verifying lists at scale, the full nine-check pipeline behind every verdict is on the email verification page, and volume pricing is on the pricing page.
Explore more from Verifox
A valid email address sits at the center of a wider set of deliverability concepts. These are the terms most worth understanding next.
Common questions
Valid email addresses, answered
“Valid” means more than having an @ symbol — the syntax, the domain, and the mailbox all have to check out. Here’s what actually gets verified.
Does a valid email address guarantee it won’t bounce?
No, and this is the single most common misreading of a validation result. “Valid” means the address cleared syntax, domain, and mailbox checks at the moment it was tested, not that it will stay that way forever.
A mailbox can be deactivated, a domain can lose its MX records, or an inbox can fill up in the days between a check and a send. Valid is a snapshot, which is why re-verifying lists that sit unused for months matters as much as the first check.
What’s the difference between valid and deliverable?
Valid describes the verdict at the address level: this specific mailbox exists and accepts mail right now. Deliverable is a broader, send-level outcome that also depends on things a single address check can’t see, like the receiving server’s spam filtering, your sender reputation, and content.
A valid address to a real inbox can still land in junk if the sender has a poor reputation. Validity is a necessary condition for deliverability, not a guarantee of it.
Why does a correctly formatted email sometimes fail verification?
Because syntax is only the first of three layers. An address like [email protected] can be perfectly well-formed and still fail because the domain has no MX record, or because the domain resolves fine but that specific mailbox was deleted, never existed, or the receiving server rejects it during the SMTP conversation.
Typos in the domain are the single most common cause: a well-typed local part sitting on a mistyped or expired domain looks fine to the eye but fails the moment anything actually checks it.
Is a catch-all address ever marked fully valid?
Not by us, and that’s deliberate. A catch-all domain accepts mail for every username, real or not, so the SMTP handshake that normally confirms a mailbox returns the same accepting response whether the address exists or was invented on the spot.
Standard verification can’t turn that into a certain valid verdict, so we flag it risky with a confidence score instead of rounding it up to valid.
How quickly can you check if an address is valid?
A single address resolves through syntax, MX, and a live SMTP check in about two seconds with the free email checker, no signup required.
For a whole list, bulk verification runs the same three-layer pipeline across every row in parallel, so the per-address speed holds even at thousands of rows. Volume pricing is on the pricing page.
What should I do with addresses marked risky instead of valid or invalid?
Don’t treat risky as a synonym for either extreme. It means the address exists in some form — catch-all, role-based, or otherwise unresolved with certainty — but carries elevated bounce risk that a plain valid/invalid split would hide.
Score and segment those addresses instead of blasting or discarding the whole bucket: send confidently to the high-confidence ones and hold or warm up the rest. See the full breakdown on the risky email page.
What are the three checks that make an address valid?
Syntax first: does the address follow RFC 5321/5322 structure, a local part, an @, and a domain. Domain second: does the domain resolve and carry a working MX record naming a server willing to receive mail for it.
Mailbox third: does a live SMTP conversation with that server confirm the specific mailbox exists and accepts mail. An address only earns the valid verdict once it clears all three, in that order.
Is checking validity different for a single address vs. a bulk list?
The underlying checks are identical — syntax, domain, and mailbox — run per address either way. What changes at scale is the need to watch for domain-level patterns like catch-all or repeated hard bounces across many rows on the same domain.
Bulk verification also justifies periodic re-checks, since a list that was 98% valid at capture decays as mailboxes get abandoned over time.