Email Validation API: What to Check Before You Store an Address
by EmailGuard Engineering
August 3, 2026engineering7 min read
Share this article
Enjoyed this 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.
What "email validation API" means here
Teams use the phrase for three different jobs:
- Syntax and structure — Is the string a well-formed address?
- Classification — Is it disposable, role-based, a privacy relay, or freemail?
- Mailbox verification — Does the inbox exist on the receiving server right now?
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. The vocabulary fight is unpacked in email validation vs verification.
See also: EmailGuard vs Kickbox, EmailGuard vs ZeroBounce, EmailGuard vs NeverBounce, and EmailGuard vs Mailgun Validate.
The checklist (in order)
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.
1. Syntax validation
Reject addresses that fail RFC-aware parsing, length limits, or TLD checks before you spend time on domain intelligence.
- Deep dive: Email valid syntax
- Free tool: Email syntax checker
Invalid TLDs and malformed local parts are cheap to catch and expensive to clean later.
2. Normalization and subaddressing
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.
- How-to: Normalize plus-addressed emails at signup
- Deep dive: Email normalization and subaddressing
- Free tool: Email normalizer
Keep the original input for support tickets; use the normalized value for uniqueness and enrichment.
3. Disposable / temporary domains
Block throwaway inboxes at signup for most products. Static GitHub blocklists lag; APIs combine curated data with live DNS.
- How-to: Block disposable emails at signup
- Comparison: Disposable blocklist vs validation API
- Deep dive: Disposable email detection
- Free tool: Disposable email checker
Watch detection_source: precomputed vs live_dns. A spike in live DNS often means operators rotated domains your curated set has not ingested yet.
4. Role-based addresses
admin@, support@, and info@ are shared inboxes. Flag them for sales routing; hard-block only when your product requires a named human. For the block / allow / confirm matrix by field, see how to set a role-based email signup policy.
- Definition: What is a role-based email address?
- Deep dive: Role-based email addresses
- Free tool: Role address detector
5. Privacy relay domains
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.
- How-to: Privacy relay vs disposable email
- Deep dive: Privacy relay detection
- Free tool: Relay domain lookup
6. Public / freemail domains
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. When the form itself must require a company hostname, use how to require a work email at signup.
- Deep dive: Public email domains
- Free tool: Public domain checker
One request shape
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.
Integration pattern (signup)
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. Timeout vs 429 vs live DNS: fail open vs fail closed at signup.
Choosing a vendor
| Need | Prefer |
|---|---|
| Signup abuse, role/relay classification, one JSON response | Classification API (EmailGuard) |
| Bulk list hygiene + deliverability scoring before a send | Kickbox / ZeroBounce / NeverBounce-style verifiers |
| Both | Classification at capture + periodic list hygiene |
Hostname repair when syntax fails: catch email typos at signup.
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.
Product surface map
| 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 |
FAQ
Do I need SMTP verification at signup?
Usually no. Disposable and role classification stop most fake and low-quality signups without the latency and catch-all ambiguity of mailbox pings.
How fast should the check be?
Target under ~200 ms added latency at p95 for cached classification. Raise the client timeout toward 400–800 ms if you want live DNS to finish, then fail open if you miss the budget unless abuse risk justifies fail closed. See fail open vs fail closed email validation. Store 2xx flags by normalized address so retries hit Redis, not a second detect call: how to cache email validation API results.
Can I run validation only in the browser?
No for security. Client checks improve UX; attackers POST past them. Enforce on the server.
What plan do I need?
Any plan with API access and the email:detect scope. Start free, then scale with pricing tiers.
Next steps
- Create an API key and call detect against a throwaway domain and a role address.
- Encode your allow / flag / block matrix for disposable, role, and relay.
- Wire a language client from the EmailGuard SDK guide (TypeScript, Go, Python, PHP, Ruby).
- Add integration tests that mock
disposable: trueandrole_address: true. - Bookmark this page as the hub; drill into the linked guides as you implement each signal.