Email Validation vs Verification
by EmailGuard Engineering
Unsplash
September 5, 2026engineering9 min read
Share this article
Enjoyed this article?
More notes on building products, infrastructure, and teams.
Email validation vs verification is not a standard split. IETF never defined those two product names. Ranking glossaries still disagree about what each word includes. Some put MX records under validation. Some put them under verification. Some put disposable detection in both columns. Buy jobs, not vocabulary: syntax, classification, and mailbox ping. EmailGuard does the first two. SMTP probing is a different product, with different latency and a harvest-shaped traffic pattern.
This page is the terminology companion to the email validation API checklist. It is not another signal-by-signal implementation guide.
TL;DR: which job to buy
| If you need | Job | Network | Who sells it |
|---|---|---|---|
Reject not-an-email before insert | Syntax | None | Every library, plus EmailGuard syntax_validation |
Block throwaways, flag info@, relays, freemail | Classification | Lists and DNS, not RCPT | EmailGuard detect |
| Guess whether this mailbox will accept mail today | Mailbox ping | SMTP (VRFY or RCPT, stop before DATA) | Kickbox, ZeroBounce, NeverBounce, and peers |
Pick syntax plus classification for signup. Add SMTP only if you accept unknown rates on Gmail/Microsoft 365 and you are willing to send probe traffic that looks like directory harvest. Prove a mailbox you care about with a confirmation email.
The IETF never named this fight
RFC 5322 specifies Internet Message Format, including addr-spec (local-part @ domain). That is a format rule. It does not say the inbox exists.
RFC 5321 specifies SMTP. A probe that runs MAIL FROM / RCPT TO and stops before DATA is a vendor practice, not a named "verification API." Two protocol facts the glossaries skip:
- §5.1: if there is no MX, clients fall back to A/AAAA as implicit MX. "No MX means undeliverable" is oversimplified.
- §7.3 / §3.5:
VRFYandEXPNleak usernames. Sites may disable them and must return 252, not a fake 250.RCPT TOcan leak the same existence oracle, or leak nothing if the server defers validity until after DATA.
RFC 7208 (SPF) authorizes sending hosts. It is not a recipient check. RFC 6647 describes greylisting as a temporary 4yz. IMAP (RFC 3501) lists folders on a server you already authenticated to. It is not a public "does user@other-domain exist?" API.
When a vendor page says "validation is RFC, verification is SMTP," they are marketing a layer cake. The RFCs do not use those labels.
How ranking pages disagree
Fetched 2026-09-01. Same query, different columns.
| Page | "Validation" | "Verification" | Where MX sits | Where disposable sits |
|---|---|---|---|---|
| Mailbeam glossary | Syntax only | MX + SMTP + catch-all + disposable + score | Verification | Verification |
| BounceCheck (2026-08-12) | Syntax + domain + address type | MX + SMTP + accept-all | Verification (again) | Validation (type analysis) |
| LeadMagic comparison | Syntax + DNS/MX + domain lists | SMTP handshake + catch-all resolve | Both | Both |
| MailCop architecture | The whole stack, including SMTP | Word used for the SMTP layer | Validation layer 2 | Flags on the "validation" response |
| Mailthentic | Working convention | Deeper SMTP evidence | Mixed | Mixed; they say there is no industry rule |
Mailthentic is the only one that admits the split is not a standard. Everyone else is refereeing a word they invented, then selling the layer they put in the "verification" column.
Classification (disposable, role, relay, public domain, normalization) is the orphan. It migrates between columns depending on who is selling. That is the gap. Signup abuse lives there. Bounce prediction does not.
Three jobs, in order
1. Syntax
Is this an addr-spec you can store? Parse, length, TLD, IDNA. No network. Fail closed. Details: syntax knowledge base and the syntax checker.
Syntax-only is too weak for signup. notareal@gnail.com can pass a naive regex. You still want DNS-aware classification, not an SMTP session, to catch that class of junk.
2. Classification
What kind of address is it? EmailGuard returns disposable, role, relay, public domain, normalized form, and detection_source from one GET. No RCPT. Policy examples: block disposables, role-based signup policy, require a work email, relays vs disposables.
A disposable domain can have a mailbox that accepts SMTP. A 250 on RCPT TO does not mean "good user." Classification answers a different question than a ping.
3. Mailbox ping
Did this MX accept RCPT TO from these IPs, today? Latency is commonly 500 ms to 3 s per address in MailCop's 2026 architecture guide (vendor figure; treat as a range, not a lab you ran). Greylisting (RFC 6647) turns the first attempt into a deferral measured in minutes.
Hyperscalers often will not give you an honest mailbox-level RCPT:
- Microsoft 365: Directory-Based Edge Blocking can reject invalid recipients at the edge (
550 5.4.1) when the accepted domain is Authoritative. If the domain is Internal relay (hybrid/migration), DBEB is off. "M365 is always catch-all" is false. "M365 is never catch-all" is also false. It is tenant config. - Gmail / Workspace: Google documents catch-all routing for unknown local-parts. Gmail sender guidelines require RFC 5322 formatting and a spam rate under 0.3% in Postmaster Tools. They tell you to reduce volume if messages bounce. They do not publish the "2% hard bounce and Gmail shuts you off" number that verification blogs repeat. Do not treat that 2% as Google policy.
Exchange documents tarpitting on recipient lookup because a 250/550 split is a directory harvest oracle. Default delay is 5 seconds on Receive connectors. Running that traffic from your app IPs is an ops decision. Spamhaus has argued for years that SMTP existence probes are hostile to postmasters.
IMAP does not save you. It is not a third-party existence check.
Pick X if / pick Y if
Pick syntax + classification (EmailGuard) if you are storing addresses at signup, blocking throwaways, scoring info@, allowing privacy relays, or requiring a work domain. You want a fast server-side call and a timeout policy, not a mailbox oracle. See fail open vs fail closed.
Pick SMTP verification (Kickbox, ZeroBounce, NeverBounce, and peers) if you are about to send a campaign to a purchased or aged list and you accept unknown / accept-all as a first-class outcome. Compare vendors on our alternatives pages. We do not pretend to be them.
Pick both if you classify at capture and run list hygiene before a blast. Those are two checkpoints, not one API with two names.
A concrete split that holds up in production:
- Register. Syntax fail closed. Disposable fail closed. Role and public domain per policy. Timeout fail open. No SMTP.
- First privileged action (invite teammates, add a card). Confirmation email if
email_checkwas skipped, or if you never confirmed. - Marketing send or CSV import. If the list is aged or purchased, a verifier's SMTP pass is the job. Budget seconds, not hundreds of milliseconds. Expect
unknownon a slice of Microsoft 365 and Gmail. Do not block signups on that pass.
Pick confirmation email if the account can reset a password or spend money. That is the only existence proof that does not look like harvest. WorkOS makes the same point in their regex-is-not-validation post: domain checks inline, mailbox proof by mail.
Where SMTP genuinely wins: you are about to send to tens of thousands of rows you did not collect yourself, and a 550 now is cheaper than a hard bounce in the campaign. Where classification genuinely wins: a human is waiting on a form, and a throwaway or info@ is the actual problem.
Honest limits
Classification will not predict a hard bounce on a corporate catch-all. We do not return catch-all. If that is the buying criterion, you want a verifier, and you will still get unknowns.
SMTP verification will not tell you the address is a human you want. Disposables with live SMTP and role inboxes both "verify." If that is the buying criterion, you want classification.
Neither job is consent. List hygiene is not a substitute for permission. A verified address can still be someone who never opted in.
EmailGuard is not cold-email inbox placement. Other products use the EmailGuard name for that. This product classifies addresses at emailguard.co.
FAQ
What is the difference between email validation and email verification?
There is no IETF definition. Vendors use validation for syntax (sometimes plus MX) and verification for SMTP. Classification (disposable, role, relay, public domain) gets parked in whichever column the vendor sells. Ask which of the three jobs you need.
Should I validate at signup and verify before send?
Yes as a workflow: classify at capture, and only SMTP-probe (or confirm by email) if bounce prediction is the job. Do not SMTP-probe every signup. You will pay latency and harvest-shaped risk for a signal Gmail and many M365 tenants will not give you honestly.
Is MX lookup validation or verification?
Both camps exist on page one. MX is DNS. RFC 5321 also allows A/AAAA fallback. Put MX with classification/DNS, not as proof the named mailbox exists.
Does verification catch spamtraps?
Not reliably. BounceCheck's 2026 comparison is unusually honest about that. A trap can look like a normal mailbox at RCPT time.
Does EmailGuard check if the inbox exists?
No. We parse and classify. We do not SMTP-probe. For signup abuse, disposable and role flags usually matter more than a 250. Confirm the mailbox with email when existence is the account-recovery path.
Is a 2% bounce rate Gmail's cutoff?
Not in current Gmail sender guidelines (fetched 2026-09-01). Google publishes a 0.3% spam-rate threshold in Postmaster Tools and tells you to reduce volume on bounces. Treat "2%" as ESP folklore until you can cite Google.
Next steps
- Write down which of the three jobs each form actually needs.
- Implement syntax plus classification with the detect API.
- Keep SMTP, if you use it, off the signup thread.
- Start from pricing for classification volume. Use a deliverability vendor when the job is a send.