The five layers of email validation
Validating an address isn't a single check. It's a stack of checks, each catching a different class of problem. Running all five gives you a verdict that holds up at scale.
1. Syntax validation
- The first pass confirms the address matches RFC 5322 format: a local part, an @, and a domain. This catches obvious typos like user@ or user@@domain.com and invalid characters before you make any network request. Fast and cheap, but not sufficient on its own.
2. Domain resolution
- Confirm the domain actually exists in DNS. name@gmail.con passes a syntax check but won't resolve. A failed lookup ends validation here.
3. MX record lookup
- The MX (mail exchanger) record tells you which servers accept incoming mail for a domain. No MX record means the domain doesn't accept email, regardless of whether the domain itself resolves.
You can check this directly from the command line: dig MX example.com
A domain with no MX records isn't deliverable. One with records moves to the next step.
4. SMTP handshake (without DATA)
- This is where validation gets precise. A standard SMTP delivery sequence works like this:
> HELO validator.example.com
< 250 Hello
> MAIL FROM: <probe@validator.example.com>
< 250 OK
> RCPT TO: <target@theirdomain.com>
< 550 5.1.1 The email account does not exist
> QUIT
< 221 Bye
The key exchange is RCPT TO. The receiving server responds with either acceptance or rejection before any message is transmitted. You disconnect before DATA, so nothing is delivered. The server tells you whether the mailbox accepts mail. You never send a message to find out.
5. Risk signal detection
- SMTP tells you if an address can receive mail. It doesn't tell you if it should receive mail from you. A few additional checks add the context the SMTP handshake can't give you:
- Disposable domain: Addresses from services like Mailinator or Yopmail are created for one-time use and abandoned. They're deliverable at the SMTP layer but worthless for any ongoing communication.
- Role-based address: info@, support@, sales@ addresses are shared inboxes. They generate higher complaint rates, lower engagement, and shouldn't receive personal or marketing mail.
- Catch-all detection: Some servers accept any RCPT TO regardless of whether the mailbox exists. More on this below.
- Quality score: A composite signal derived from the checks above plus domain age, reputation, and provider history.
Why DIY SMTP verification breaks at scale
Running the stack above yourself is reasonable at low volume. For a hundred addresses a day, the protocol works as described. Push it further and you hit four problems that are genuinely difficult to solve without dedicated infrastructure.
Catch-all servers
Some mail servers are configured to accept any RCPT TO address, regardless of whether the mailbox exists. RCPT TO: <doesnotexist@thatdomain.com> returns 250 OK. You have no way to distinguish a valid address from a fabricated one on a catch-all domain, and you will have no warning until your actual send bounces.
Greylisting
Many servers temporarily reject the first connection from an unknown IP with a 451 or 421 response code. This is intentional. Greylisting is a spam-reduction technique: legitimate mail servers retry on a temp-reject, spammers usually don't. The protocol expects the sending server to wait a few minutes and try again, at which point the connection proceeds normally.
A naive verifier doesn't retry. It treats 451 Temporary failure as a verdict and marks the address as invalid. The result is false negatives on real, valid addresses, sometimes a significant percentage of your list, depending on which providers your contacts use. Handling greylisting correctly means tracking which addresses returned a temp-reject, waiting the appropriate interval, and retrying, which adds meaningful complexity to what started as a simple script.
Gmail, Microsoft, and most major providers increasingly reject or ignore SMTP probes from IPs without established sending history. Building that reputation takes consistent, high-volume legitimate mail over months. An IP you spun up for verification gets blocked or silently dropped. Your results degrade in proportion to how many of your target addresses live on those domains, which is usually most of them.
Rate limits
Attempt to verify thousands of addresses from a single IP in a short window and you'll be blocked or
throttled. Distributing across multiple IPs helps, but compounds the reputation problem above.
None of these are fatal at low volume. All of them are fatal at scale.
How Email Validation APIs solve it
An Email Validation API handles the SMTP infrastructure problem so you don't have to. Instead of a single IP running a probe, the request goes through a pool of IPs with years of established sending history, automatic retry logic tuned for greylisting, and accumulated heuristics for catch-all detection. The infrastructure does the work; you get a verdict.
- Skip the SMTP code. Try Email Validation.
Here's what a request and response look like with Abstract's Email Validation. In JavaScript:
const response = await fetch( `https://emailvalidation.abstractapi.com/v1/?api_key=YOUR_KEY&email=richard.hendricks@abstractapi.com`
);
const data = await response.json();
console.log(data.email_deliverability.status); // "deliverable"
Or as a raw HTTP request:
GET https://emailvalidation.abstractapi.com/v1/
?api_key=YOUR_KEY
&email=richard.hendricks@abstractapi.com
Response:
{
"email_address": "richard.hendricks@abstractapi.com",
"email_deliverability": {
"status": "deliverable",
"status_detail": "valid_email",
"is_format_valid": true,
"is_smtp_valid": true,
"is_mx_valid": true,
"mx_records": [
"aspmx.l.google.com",
"alt1.aspmx.l.google.com",
"alt2.aspmx.l.google.com"
]
}
}
Higher-tier plans return additional objects: email_quality (disposable, catch-all, role, quality score), email_sender (name, provider, organization), email_domain (age, registrar, expiry, risky TLD flag), email_risk (address and domain risk status), and email_breaches (breach history). Every layer of the manual stack above, plus the risk signals, in a single request. Full validation response in under 300ms, fast enough for real-time signup flows.
When to call it:
- At signup, on form submit: Real-time validation before the address enters your database. Under 300ms fits inside a standard form submission flow with no perceptible delay.
- Before a marketing send: Batch validate your list. Flag disposable and role-based addresses before they inflate your bounce rate and damage your sender reputation.
- Before importing a list: Third-party lists are rarely clean. Validate before import, not after your first campaign reveals the problem.
Skip the send, trust the handshake
Syntax, MX records, and the SMTP handshake let you verify an address without delivering a message. The protocol was designed to work this way. Catch-all domains, greylisting, and IP reputation requirements make DIY validation unreliable past a few hundred addresses a day.
An API handles the infrastructure, the IP pools, the retry logic, and the edge cases. You get a layered verdict in one request and never touch the SMTP plumbing. For signup forms, that verdict comes back in under 300ms, fast enough that most users never notice the check is happening. For list cleaning and pre-send validation, you get the same accuracy in bulk, without any email infrastructure of your own.
- Skip the SMTP code. Try Email Validation.
- Most teams are live in under 5 minutes.
