Email Validation API: What to Check Before You Store an Address
by Francis Baker
August 3, 2026engineering6 min read
Loading article…
Share this article
Enjoyed this article?
More notes on building products, infrastructure, and teams.
by Francis Baker
Loading article…
More notes on building products, infrastructure, and teams.
Before you store an email address, validate syntax, normalize aliases, and classify disposable, role, relay, and public-domain characteristics—ideally in one API call on your server. That is what an email validation API should do for signup, checkout, and CRM sync. Mailbox existence checks (SMTP ping) are a different product category; most abuse and lead-quality problems are solved by classification signals, not inbox probing.
This guide is the hub for EmailGuard's detection stack. It maps each signal to a product decision and links to deeper docs, free tools, and integration patterns.
Teams use the phrase for three different jobs:
EmailGuard focuses on (1) and (2). We intentionally do not claim SMTP mailbox verification. If you need catch-all probing and bounce prediction for bulk sends, evaluate deliverability-oriented vendors (Kickbox, ZeroBounce, and peers). If you need clean signup data and abuse reduction, classification is usually enough—and faster.
See also: EmailGuard vs Kickbox and EmailGuard vs ZeroBounce.
Run these checks server-side when the form is submitted, before you insert a user or lead row.
| Step | Signal | Fail closed? | Why |
|---|---|---|---|
| 1 | Syntax | Yes | Garbage strings should never become rows |
| 2 | Normalization | n/a | Deduplicate aliases before unique constraints |
| 3 | Disposable | Usually yes | Throwaway domains pollute analytics and abuse systems |
| 4 | Role address | Optional | Shared inboxes hurt account ownership |
| 5 | Relay domain | Rarely | Privacy relays are legitimate users |
| 6 | Public domain | Scoring only | Freemail vs corporate for ICP filters |
EmailGuard returns all of these from one GET /api/v1/emails/detect request. Full field list: detect email characteristics. Overview of the pipeline: email detection signals.
Reject addresses that fail RFC-aware parsing, length limits, or TLD checks before you spend time on domain intelligence.
Invalid TLDs and malformed local parts are cheap to catch and expensive to clean later.
Users create duplicates with jane.doe+promo@gmail.com vs janedoe@gmail.com. Normalize first; store the canonical form if your product deduplicates by mailbox.
Keep the original input for support tickets; use the normalized value for uniqueness and enrichment.
Block throwaway inboxes at signup for most products. Static GitHub blocklists lag; APIs combine curated data with live DNS.
Watch detection_source: precomputed vs live_dns. A spike in live DNS often means operators rotated domains your curated set has not ingested yet.
admin@, support@, and info@ are shared inboxes. Flag them for sales routing; hard-block only when your product requires a named human.
Apple Hide My Email, Firefox Relay, SimpleLogin, and similar services forward mail while masking the real inbox. They are not disposables. Hard-blocking them rejects privacy-conscious customers.
gmail.com and peers are fine for consumer products. For B2B ICP filters, store public_domain and score leads—do not confuse freemail with disposable.
curl -sS \
-H "Authorization: Bearer YOUR_KEY" \
"https://emailguard.co/api/v1/emails/detect?email=admin%2Bpromo%40passmail.net"You get syntax, normalized form, subaddressing, role, public domain, relay provider, disposable status, and detection source together. Authenticate with a key that includes email:detect. Respect rate limits.
Try the full stack in the browser: free email validator.
parse email
→ detect API (timeout 200–500 ms)
→ syntax fail → 422 "fix the address"
→ disposable true → 422 "permanent email required"
→ role true → allow + flag (or soft-block per policy)
→ relay true → allow + flag
→ create user / lead
→ on timeout / 5xx → fail open, log, queue recheckDetails and Node/Go samples: server-side disposable blocking guide.
| Need | Prefer |
|---|---|
| Signup abuse, role/relay classification, one JSON response | Classification API (EmailGuard) |
| Bulk list hygiene + deliverability scoring before a send | Kickbox / ZeroBounce-style verifiers |
| Both | Classification at capture + periodic list hygiene |
Honest comparisons:
EmailGuard is not a cold-email deliverability monitor. Other products use the "EmailGuard" name for inbox placement tooling—we validate addresses at capture time on emailguard.co.
| Goal | Start here |
|---|---|
| See every signal | Features |
| Call the API | Detect reference |
| Create a key | Creating API keys |
| Browse signal docs | Knowledge base |
| Price by volume | Pricing |
| Interactive checks | Free tools |
Usually no. Disposable and role classification stop most fake and low-quality signups without the latency and catch-all ambiguity of mailbox pings.
Target under ~200 ms added latency at p95. Set a short timeout and fail open if you miss the budget—unless abuse risk justifies fail closed.
No for security. Client checks improve UX; attackers POST past them. Enforce on the server.
Any plan with API access and the email:detect scope. Start free, then scale with pricing tiers.
disposable: true and role_address: true.