Email Verification API: Features, Checks, and Setup

An email verification API checks whether an address is likely to receive mail before you send to it. It does more than confirm name@example.com has the right shape. A good API tests domain records, mailbox signals, disposable domains, catch-all behavior, and bounce risk in real time.

What Is an Email Verification API?

An email verification API is a service your application calls to check whether an email address is valid, deliverable, and safe to use.

You send an address to the API. The API returns structured data about that address. That response may include:

• Format validity
• Domain validity
• MX records
• Mailbox reachability
• Disposable domain status
• Catch-all status
• Role account status
• Free provider status
• Typo suggestions
• Bounce risk
• A final verdict such as deliverable, risky, undeliverable, or unknown

That makes it different from simple email validation.

Regex validation answers one narrow question:

Does this string look like an email address?

An email validation API or verification API answers a better question:

Should you accept, store, or send to this address?

Those are not the same.

For example, these addresses can all pass a basic format check:

• sarah@gmial.com
• test@temporary-mail-example.com
• sales@company-that-has-no-mx-records.com
• random-address@catchall-domain.com

But each one carries a different risk. One may be a typo. One may be disposable. One may be undeliverable. One may be impossible to confirm because the domain accepts all mail.

You can run verification anywhere you collect or process email addresses:

• Signup forms
• Checkout pages
• Trial creation flows
• Demo request forms
• Newsletter forms
• Lead capture pages
• CRM imports
• Sales engagement tools
• Data enrichment workflows
• Outbound prospecting systems

There are two common modes.

Real-time verification checks one address during a user action. This is best for forms, account creation, checkout, demos, and trials.

Bulk verification checks a list before you send, import, migrate, or sync it. This is best for old databases, newsletter lists, event leads, and cold outreach prep.

Most teams need both. Real-time checks keep bad data out. Bulk checks clean the data you already have.

How an Email Verification API Works

An email verification API combines several checks into one decision.

No single check is enough. The API builds confidence by testing the address from multiple angles.

Syntax and format validation

The first step checks whether the address follows valid email syntax.

This catches obvious failures like:

• Missing @
• Missing domain
• Spaces in the address
• Invalid characters
• Broken domain structure
• Empty local part

Examples:

Address	Format result	Why
alex@example.com	Pass	Valid structure
alex.example.com	Fail	Missing @
alex@	Fail	Missing domain
alex@company	Usually fail or risky	No valid public domain structure

Syntax validation is fast and useful. But it only removes the worst input. It cannot tell you whether mail will deliver.

Domain and DNS validation

Next, the API checks the domain.

For alex@example.com, the domain is example.com.

A verification service will usually check:

• Does the domain exist?
• Does DNS resolve?
• Does the domain have MX records?
• If no MX records exist, does it have fallback A records?
• Are DNS responses valid and stable?

MX records matter because they tell senders where to deliver mail for that domain.

If a domain has no mail servers, the address cannot receive normal email. That is a strong undeliverable signal.

SMTP mailbox probing

SMTP email verification goes one step deeper.

The API connects to the domain’s mail server and asks whether a specific mailbox appears to be accepted. It does this without sending an actual email.

A simplified SMTP flow looks like this:

1. Find the domain’s MX records.
2. Connect to the mail server.
3. Start an SMTP conversation.
4. Present a sender address.
5. Ask whether the recipient mailbox is accepted.
6. Interpret the server response.

This can produce strong signals. But results vary by provider.

Some mail servers clearly reject invalid recipients. Some accept all recipients first and filter later. Some use rate limits, greylisting, tarpits, or anti-abuse behavior. Some hide mailbox existence to prevent directory harvesting.

That is why a serious email deliverability API should not pretend every result is binary. Sometimes the correct answer is unknown.

Catch-all email detection

A catch-all domain accepts mail for any local part.

For example, if company.com is catch-all, the server may accept all of these:

• jane@company.com
• notarealperson@company.com
• x9fzz-test@company.com

Catch-all email detection helps you identify that pattern.

Catch-all does not mean the address is bad. It means the API cannot confirm the specific mailbox through normal SMTP behavior. The address may belong to a real person, or it may not.

Treat catch-all results as risk signals, not automatic failures.

Disposable domain detection

Disposable email detection API checks compare the domain against known burner, throwaway, and temporary email providers.

These addresses often look valid. They may even receive mail for a short time. But they are poor long-term contact points.

Disposable addresses can hurt:

• Free trial quality
• Product-led growth analytics
• Fraud controls
• Referral programs
• Lifecycle email performance
• CRM hygiene

Because disposable services appear and disappear constantly, this data needs frequent updates. A stale disposable list will miss newer burner domains.

Role account and free provider checks

Role accounts represent a function, not a person.

Common examples:

• info@
• support@
• sales@
• admin@
• billing@
• hello@
• contact@

Role accounts are not always bad. But they behave differently.

They may go to shared inboxes. They may have lower engagement. They may create ownership problems in B2B sales workflows.

Free provider checks identify domains like Gmail, Outlook, Yahoo, and similar mailbox providers. These are usually valid consumer addresses, but they can matter for segmentation. A B2B demo request from a free provider may need different handling than one from a company domain.

Risk scoring and verdicts

Good APIs return a final verdict plus supporting signals.

A typical response may look like this:

{
  "email": "sarah@gmial.com",
  "verdict": "undeliverable",
  "risk_score": 92,
  "checks": {
    "syntax": "valid",
    "domain": "invalid",
    "mx_records": "not_found",
    "disposable": false,
    "catch_all": false,
    "role": false,
    "free_provider": false
  },
  "suggestion": "sarah@gmail.com"
}

The exact schema varies by provider. The important part is transparency.

You want enough detail to decide what to do next.

The Checks That Matter Most

The highest-impact checks are the ones that prevent hard bounces and low-quality signups.

If you need to prioritize, start here:

1. Domain and MX validation
2. SMTP mailbox probing
3. Disposable domain detection
4. Catch-all detection
5. Typo correction
6. Role account detection
7. Free provider detection

1. Domain and MX validation

Invalid domains and missing MX records are strong bounce predictors.

If the domain cannot receive mail, you should not send. This is one of the cleanest decisions an API can make.

2. SMTP mailbox probing

Mailbox probing helps separate valid domains from valid recipients.

A domain may receive mail, but that does not mean john@thatdomain.com exists. SMTP checks can catch many invalid mailboxes before you send.

The limitation: some providers block or obscure this signal. That is why SMTP results should feed a verdict, not act as the only rule.

3. Disposable email detection

Disposable addresses are especially damaging in free trials, freemium products, gated content, referral programs, and abuse-prone flows.

They create fake users who never become reachable customers. They also distort funnel metrics.

You may see:

• Inflated signup volume
• Lower activation rates
• Poor trial-to-paid conversion
• More fake accounts
• Weak lifecycle email performance

For many product-led teams, blocking disposable domains at signup is reasonable. For content downloads, you may choose to accept them but mark them as low quality.

4. Catch-all detection

Catch-all domains need careful handling.

In sales workflows, a catch-all address may still be worth pursuing if other signals look strong. For example, a verified company domain, a known employee name, and strong enrichment data may justify outreach.

In marketing workflows, you may want to suppress catch-all addresses from high-volume campaigns until they engage or pass a later check.

A practical approach:

Result	Recommended action
Deliverable, not catch-all	Accept and send normally
Deliverable, catch-all	Accept, but segment as higher risk
Risky, catch-all	Use lower-volume sending or manual review
Undeliverable	Block or suppress
Unknown	Retry later before deciding

5. Typo suggestions

Email typo correction catches common domain mistakes.

Examples:

• gmial.com → gmail.com
• gamil.com → gmail.com
• hotmial.com → hotmail.com
• outlok.com → outlook.com

This is one of the easiest wins in a form.

Instead of rejecting the user, show a soft prompt:

Did you mean sarah@gmail.com?

You reduce bounces without adding friction.

6. Role account detection

Role accounts matter because they affect routing, ownership, and engagement.

For B2B sales, alex@company.com is usually better than info@company.com. For billing, accounts@company.com may be exactly right.

Do not treat role accounts as universally bad. Treat them based on workflow.

Real-Time vs Bulk Email Verification

Real-time verification prevents bad addresses from entering your systems. Bulk verification cleans addresses already inside them.

Both solve deliverability problems, but they fit different points in the data lifecycle.

When to use real-time checks

Use a real-time email verification API when the user is still on the page.

Good use cases:

• Signup forms
• Account creation
• Checkout
• Trial starts
• Demo requests
• Contact forms
• Newsletter signups
• Partner applications
• In-app invite flows

The goal is to catch mistakes while the user can fix them.

A simple form flow:

1. User enters email.
2. Your app calls the email verification REST API.
3. API returns verdict and reason codes.
4. You accept, warn, or block based on your policy.

Example request sketch:

curl -X POST "https://api.your-verification-provider.com/verify" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"sarah@gmial.com"}'

Use this as a pattern, not a copy-paste endpoint. Each provider uses its own URL and schema.

When to use bulk checks

Use bulk verification when you already have a list.

Good use cases:

• CRM cleanup
• Newsletter migration
• Cold email preparation
• Event lead imports
• Partner lead uploads
• Data warehouse audits
• Re-engagement campaigns
• Suppression before a large send

Bulk verification reduces risk before you hit send. This matters most when the list is old, purchased, scraped, merged, or collected from offline sources.

Old addresses decay. People change jobs. Domains shut down. Mailboxes get abandoned.

A list that performed well last year may be risky today.

How to combine both

The best setup uses both modes.

• Verify new addresses in real time.
• Re-verify old addresses before major sends.
• Re-check risky and unknown results later.
• Store verification timestamps.
• Suppress addresses that become undeliverable.
• Feed bounce and complaint data back into your CRM or data warehouse.

This keeps your list clean over time instead of treating verification as a one-time project.

How to Evaluate an Email Verification API

Evaluate an email verification API by accuracy, transparency, speed, reliability, and fit with your workflow.

Do not buy only on the cheapest per-check price. A cheap false positive can cost more than the verification itself.

Accuracy and verdict quality

Look for providers that explain their results.

A weak response looks like this:

{
  "valid": true
}

That is not enough.

A useful response includes:

• Final verdict
• Risk score
• Syntax result
• Domain result
• MX result
• SMTP result
• Disposable flag
• Catch-all flag
• Role account flag
• Free provider flag
• Typo suggestion
• Reason codes
• Timestamp

You need these fields to build sane rules.

For example, you may block undeliverable, warn on typo, accept deliverable, and route risky to a lower-volume sequence.

Speed and timeout behavior

Real-time form checks need fast responses.

If the API takes too long, users wait. That hurts conversion.

Ask how the provider handles:

• Slow mail servers
• DNS timeouts
• Greylisting
• Temporary SMTP failures
• Provider rate limits
• Unknown results

A good API should return a useful response instead of hanging your form.

Uptime and reliability

Verification often sits in signup, checkout, or lead capture paths. Treat it like production infrastructure.

Check for:

• Clear status page
• Sensible API timeouts
• Retry guidance
• Stable authentication
• Rate limit documentation
• Webhook or batch status support, if relevant

Your application should also fail gracefully. If the verification provider is unavailable, decide whether to accept the address, queue it for later verification, or show a temporary warning.

Documentation and developer experience

Good docs save engineering time.

Look for:

• Clear authentication examples
• Request and response examples
• Error codes
• SDKs or simple REST examples
• Testing guidance
• Sandbox or free tier
• Copy-paste examples for common stacks

A clean REST API is usually easiest to integrate across product, RevOps, and data workflows.

Pricing and workflow fit

Compare pricing against how you will use the API.

Questions to ask:

• Do you need real-time checks, bulk checks, or both?
• Are credits consumed for unknown results?
• Are there monthly minimums?
• Can you start without a contract?
• Can non-developers use integrations?
• Does the plan fit expected signup or import volume?

Also check integration support. Zapier, Pipedream, Apify, and REST API support make it easier to connect forms, CRMs, spreadsheets, scraping workflows, and outbound systems without custom engineering for every use case.

Disposable data freshness

Disposable detection is only as good as the data behind it.

New burner domains appear constantly. Ask whether the provider continuously updates disposable and throwaway domain data.

If that list is stale, your trial and signup defenses will leak.

Implementation Best Practices

Implement verification as a decision system, not a blunt gate.

You want fewer bad addresses without blocking good users unnecessarily.

Validate at the point of capture

Run real-time checks while the user can still correct the address.

Good places:

• Email input blur
• Form submit
• Account creation step
• Before sending magic links
• Before creating CRM leads

Avoid validating on every keystroke. That wastes API calls and can create noisy UX. Validate when the address looks complete.

Use soft warnings where possible

Not every risky result should block the user.

Use soft warnings for:

• Typo suggestions
• Catch-all domains
• Unknown SMTP responses
• Role accounts in some workflows
• Free providers on B2B forms

Example:

We could not confirm this mailbox. You can continue, but please check that the address is correct.

For typo correction:

Did you mean alex@gmail.com?

Let the user fix the issue with one click.

Block clear failures

Some results are safe to block.

Consider blocking:

• Invalid syntax
• Nonexistent domains
• Domains with no mail records
• Known disposable addresses in signup or trial flows
• Confirmed undeliverable mailboxes

Your policy should match the risk of the workflow.

A SaaS free trial may block disposable emails. A newsletter signup may accept them but segment them out of core lifecycle reporting.

Store verification metadata

Do not store only the final verdict.

Store useful fields such as:

• Verification verdict
• Risk score
• Reason codes
• Disposable flag
• Catch-all flag
• Role flag
• Suggested correction
• Verification timestamp
• Source form or import name

This helps with segmentation, auditing, debugging, and future re-verification.

For example, if a campaign has elevated bounces, you can inspect whether those addresses were catch-all, old, unknown, or imported from a specific source.

Retry unknown results later

unknown is not the same as undeliverable.

Unknown can happen because of temporary SMTP behavior, DNS issues, greylisting, or anti-abuse controls.

A good pattern:

1. Accept or hold the address based on workflow risk.
2. Store the unknown result.
3. Retry later.
4. Suppress only if later checks or send results show clear risk.

This protects conversions while still managing deliverability.

Common Mistakes to Avoid

Most verification failures come from over-trusting one signal or using old data.

Avoid these mistakes.

Relying only on regex validation

Regex catches malformed input. It does not catch bad domains, dead mailboxes, disposables, or catch-all risk.

Use regex as the first check, not the full strategy.

Blocking all catch-all domains automatically

Catch-all domains are ambiguous. Some belong to real companies and real buyers.

If you block them all, you will reject valid leads.

Segment catch-all addresses. Apply lower-risk sending patterns. Use enrichment, engagement, and campaign behavior to decide what to do next.

Using stale verification results forever

Verification has a shelf life.

An address that was deliverable six months ago may not be deliverable today. This is common in B2B lists because people change jobs and companies change mail systems.

Re-verify before major sends, especially for older or inactive segments.

Failing to verify imported lists before sending

Imported lists are risky because you did not capture the address in the current context.

Before you send to an imported list, verify it.

This applies to:

• Event lists
• Webinar exports
• Partner leads
• CRM merges
• Newsletter migrations
• Cold outreach lists
• Old customer databases

One bad import can spike bounces and damage sender reputation.

Ignoring deliverability signals after verification

Verification happens before sending. Deliverability continues after sending.

Keep watching:

• Bounce rates
• Complaint rates
• Opens and clicks
• Spam trap indicators
• Unsubscribes
• Provider-specific deferrals
• Engagement by source

If a source produces verified addresses but poor engagement and high complaints, reduce volume or stop using it.

When to Use Bounceable

Use Bounceable when you need a real-time email verification and deliverability API that developers can add to forms, CRMs, and outbound workflows without heavy setup.

Bounceable verifies whether an address is deliverable before you send to it. It checks syntax, domains, MX records, disposable domains, catch-all behavior, mailbox signals, role accounts, free providers, typo suggestions, and bounce risk.

It returns clear deliverability verdicts such as:

• deliverable
• risky
• undeliverable
• unknown

That gives you enough context to build practical rules instead of relying on a black-box yes/no result.

Bounceable is a good fit when you want to:

• Stop obvious fake or broken signups
• Detect disposable and burner addresses
• Flag catch-all domains before outreach
• Reduce bounces before campaigns
• Clean CRM and list imports
• Suggest email typo fixes at signup
• Route risky leads differently
• Connect verification through REST, Zapier, Pipedream, or Apify

Start with a policy that matches your workflow:

Workflow	Suggested policy
SaaS signup	Block disposable and undeliverable. Warn on typos.
Demo request	Block undeliverable. Warn on free providers or role accounts if needed.
Newsletter form	Correct typos. Suppress clear failures. Segment risky addresses.
Cold outreach	Verify in bulk first. Exclude undeliverable. Treat catch-all as higher risk.
CRM import	Verify before sync. Store verdicts and timestamps.

You can start on the free tier with no credit card required, then move to Growth or Scale when verification volume grows.