Email Deliverability API: What to Check Before Sending

An email deliverability API helps you decide whether an email address is safe to accept or send to before you send anything. That matters because bad addresses hurt sender reputation, waste sales effort, and pollute product data.

You need more than a yes/no validator. You need pre-send signals your product, CRM, and marketing systems can act on.

What an Email Deliverability API Does

An email deliverability API evaluates whether an address is safe to accept, store, or send to before email is sent.

It usually combines several checks:

• Is the address formatted correctly?
• Does the domain exist?
• Does the domain accept mail?
• Does the mailbox appear reachable?
• Is the address disposable, role-based, typoed, or risky?
• Should you send, block, prompt, or review?

This is different from adjacent email tools.

Tool type	What it answers	When you use it
Email deliverability API	“Is this address safe to accept or send to?”	Before signup, import, outreach, or campaign send
Email verification API	Often used interchangeably, but may focus more narrowly on validity checks	Before accepting or mailing an address
Email sending API	“Can I send this message?”	During message delivery
Inbox placement tool	“Did my mail land in inbox, spam, or promotions?”	During deliverability testing and monitoring
DMARC monitoring platform	“Who is sending mail as my domain, and is authentication aligned?”	Ongoing domain protection and authentication monitoring

The line between an email verification API, email validation API, and email deliverability API can blur. In practice, technical buyers should look at the signals returned. A simple regex checker is not enough. A useful API gives you a deliverability verdict, risk context, and reason codes you can automate against.

Common use cases include:

• Signup forms: stop fake, disposable, and typoed addresses before account creation.
• Onboarding: make sure activation, password reset, and billing emails can arrive.
• CRM enrichment: clean leads before sales reps spend time on them.
• Cold outreach prep: reduce bounces before sending from sales engagement tools.
• List imports: score old or third-party lists before campaign upload.
• Marketplace and community products: reduce abuse from throwaway inboxes.

The goal is not to reject every imperfect address. The goal is to make a better decision before you risk a bounce, failed activation, or low-quality account.

Core Checks an Email Deliverability API Should Return

A good API returns layered checks, not one fragile answer.

Syntax and formatting validation

Syntax validation checks whether the address follows email formatting rules.

It catches obvious failures:

• alexexample.com
• alex@
• alex@@example.com
• alex@example
• spaces or invalid characters in the wrong place

This is the cheapest check. It should happen first. But it only tells you whether the address could exist, not whether it does exist.

Domain and MX record checks

Domain checks answer two questions:

1. Does the domain exist?
2. Is it configured to receive mail?

The API should check DNS and MX records. If a domain has no valid mail exchange path, your message cannot be delivered.

Examples:

• user@real-company.com with valid MX records: possible.
• user@expired-domain-example.test: not deliverable.
• user@landing-page-only-domain.com with no mail setup: risky or undeliverable.

Some domains receive mail through fallback records even when MX records are missing, but that is less common. The API should expose enough DNS detail so you know why it reached its verdict.

SMTP mailbox probing where appropriate

SMTP email verification checks the mail server conversation to determine whether a mailbox appears to exist.

A typical flow may include:

• Connect to the recipient mail server.
• Identify the sender.
• Ask whether the recipient address would be accepted.
• Stop before sending an actual message.

This can improve accuracy, but it has limits. Some mail servers block probes. Some rate-limit verification attempts. Some always say “yes” to avoid address harvesting. Others behave differently depending on sender reputation, IP, or timing.

So SMTP signals should feed a risk model. They should not be the only input.

Disposable, throwaway, and burner domain detection

A disposable email detection API identifies domains used for temporary inboxes.

These addresses often work briefly. Then they disappear. They create problems when you rely on email for:

• Account recovery
• Billing notices
• Security alerts
• Lifecycle messaging
• Abuse prevention
• Community moderation

A strong provider maintains a large, frequently updated disposable domain list. This matters because burner domains change constantly. Static lists go stale fast.

You do not always need to block disposable addresses. For a downloadable guide, you may allow them. For a financial app, SaaS trial, marketplace, or fraud-sensitive workflow, you may block or challenge them.

Catch-all and accept-all domain detection

Catch-all domains accept mail for any local part.

For example, these might all be accepted:

• alex@company.com
• not-a-real-person@company.com
• random-string-9281@company.com

That does not mean every mailbox exists. It means the domain accepts mail broadly.

This creates catch-all risk. SMTP probing may confirm that the domain accepts the address, but not that a real person owns it. Your API should flag this clearly.

Treat catch-all addresses as “risky,” not automatically bad. Many legitimate companies use catch-all routing. But you should send carefully, especially for cold outreach and imported lists.

Role-account, free-provider, and typo detection

Useful APIs also identify address characteristics that affect routing and business rules.

Look for:

• Role accounts: info@, support@, admin@, sales@, billing@
• Free providers: Gmail, Outlook, Yahoo, iCloud, and similar domains
• Typo domains: gmial.com, gmai.com, hotnail.com, outlok.com
• Suggested corrections: jane@gmial.com → jane@gmail.com

Role accounts are not invalid. But they often represent teams, queues, or aliases. They may be poor targets for lifecycle emails or sales personalization.

Free-provider flags are also not bad by default. They are useful for segmentation. A B2B SaaS may treat person@company.com differently from person@gmail.com.

Typo detection is high leverage. It prevents avoidable activation failures while keeping the user in control.

Deliverability verdicts

A practical API should return a clear deliverability verdict, such as:

• deliverable
• risky
• undeliverable
• unknown

The exact labels vary by provider. What matters is that they map to actions.

Verdict	Meaning	Typical action
deliverable	Address appears safe to accept or send to	Accept and send normally
risky	Address may work, but has risk signals	Accept with caution, throttle, or verify further
undeliverable	Address is likely invalid or cannot receive mail	Block, suppress, or ask for correction
unknown	API could not determine confidently	Allow with fallback, retry later, or queue for review

Bounce risk scoring adds more nuance. A score helps you rank addresses when you need thresholds, not just labels.

Why Syntax Validation Is Not Enough

A properly formatted address can still be fake, inactive, disposable, typoed, or risky.

These all pass basic syntax checks:

• alex@gmial.com
• test@temporary-inbox-provider.example
• asdfasdf@company-with-catchall.com
• former.employee@real-company.com
• sales@legitimate-company.com

But each has a different operational meaning.

alex@gmial.com is probably a typo. You should prompt for a correction.

test@temporary-inbox-provider.example may receive mail today and disappear tomorrow. You may block it for account creation.

asdfasdf@company-with-catchall.com may pass SMTP checks because the domain accepts everything. You should treat it as higher risk.

former.employee@real-company.com may have valid syntax and a real domain, but the mailbox may no longer exist.

sales@legitimate-company.com may be deliverable, but it is a role account. It may not belong to the person filling out your form.

This is why “valid” and “invalid” are too coarse. Teams need risk context.

A good email validation API tells you:

• What passed.
• What failed.
• What could not be confirmed.
• Why the final verdict was assigned.
• What action your system should take next.

How to Use API Verdicts in Your Product Flow

API verdicts should change what your product does in the moment.

Accept deliverable addresses normally

If the API returns deliverable, let the user continue.

Common actions:

• Create the account.
• Send activation or confirmation email.
• Add the contact to CRM.
• Allow campaign upload.
• Mark the email as verified at the current timestamp.

You should still track bounces later. Pre-send verification reduces risk, but it cannot guarantee inbox placement or future mailbox status.

Prompt users to correct likely typos

If the API suggests a correction, show it before submission or immediately after.

Example copy:

Did you mean jane@gmail.com?

Give users a clear choice:

• Accept the suggestion.
• Keep the original.
• Edit manually.

Do not silently rewrite email addresses. You can create account takeover and support problems if you change a user’s identifier without consent.

Block or challenge disposable addresses

If your product depends on durable identity, block or challenge disposable email addresses.

Options:

• Block the address and ask for a permanent email.
• Require additional verification.
• Allow signup but restrict sensitive actions.
• Route the account into fraud or abuse review.

Your policy should match the workflow. A newsletter may tolerate burner addresses. A payments product should not.

Route risky or catch-all addresses carefully

Risky does not mean useless. It means you should lower your blast radius.

For risky or catch-all addresses, you can:

• Send a double opt-in email.
• Throttle initial sends.
• Exclude from high-volume campaigns.
• Use a lower-risk sender pool.
• Require confirmation before sales outreach.
• Send to a suppression review queue if the lead source is weak.

For cold outreach, catch-all risk deserves special care. A catch-all domain can accept invalid addresses, which hides quality problems until engagement stays low or delayed bounces appear.

Store verdict and reason codes

Store the verification result with the address.

At minimum, keep:

• Normalized email
• Verdict
• Risk score or confidence
• Reason codes
• Disposable flag
• Catch-all flag
• Role flag
• Suggested correction
• Verification timestamp
• Provider response version, if available

This helps with auditability. It also prevents endless arguments between marketing and engineering. Everyone can see why an address was accepted, challenged, suppressed, or retried.

Implementation Patterns for Developers

A real-time email verification API works best when you place it at the decision point, not only during cleanup.

Real-time verification on signup and lead forms

Real-time checks are best for:

• Account registration
• Demo requests
• Contact sales forms
• Waitlists
• Checkout flows
• Newsletter signup, if list quality matters

Keep the user experience fast. Run lightweight client-side syntax checks first. Then call your backend, and let your backend call the verification provider. Do not expose provider API keys in browser code.

A simplified flow:

1. User enters email.
2. Browser performs basic format check.
3. Backend calls verification API.
4. Backend maps the verdict to product action.
5. UI accepts, prompts, blocks, or challenges.

Illustrative request sketch:

curl -X POST "https://api.example.com/verify" \
  -H "Authorization: Bearer $EMAIL_VERIFICATION_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"jane@gmial.com"}'

Illustrative response shape:

{
  "email": "jane@gmial.com",
  "normalized_email": "jane@gmial.com",
  "suggested_correction": "jane@gmail.com",
  "verdict": "risky",
  "risk_score": 72,
  "checks": {
    "syntax": "pass",
    "mx": "pass",
    "smtp": "unknown",
    "disposable": false,
    "catch_all": false,
    "role": false,
    "free_provider": true
  },
  "reason_codes": ["possible_typo", "smtp_unknown"]
}

Use the structure, not the exact field names, as your design target.

Batch verification before campaign upload

Batch verification fits list imports and campaign prep.

Use it when you have:

• Old newsletter lists
• Event lists
• CRM exports
• Purchased or partner-sourced data
• Cold outreach files
• Product user lists that have not been mailed recently

A good batch workflow:

1. Upload or stream the list.
2. Normalize and deduplicate.
3. Verify addresses.
4. Suppress undeliverable addresses.
5. Segment risky addresses.
6. Export clean fields back to the CRM or sending platform.

Do not wait until send time for a large, stale list. Clean it before it reaches your ESP.

Workflow automation

Not every team wants to write custom glue for every workflow.

Look for integrations through tools like:

• Zapier
• Pipedream
• Apify
• Internal jobs
• CRM enrichment pipelines
• Data warehouse sync jobs

Bounceable, for example, supports a REST API plus Zapier, Pipedream, and Apify integrations. That lets engineering own the core logic while RevOps and marketing automate routine checks.

Caching and re-verification

Verification results age.

An address that was deliverable six months ago may bounce today. A disposable domain may appear after your last check. A company may change mail providers. An employee may leave.

Use caching, but set re-verification rules.

Common patterns:

• Reuse fresh results for repeated form submissions.
• Re-verify before large sends.
• Re-verify stale contacts after a set age.
• Re-verify risky contacts more often than deliverable contacts.
• Re-verify after a hard bounce if the address later re-enters a workflow.

Avoid calling an API repeatedly for the same email in the same session. Cache short-term results to reduce latency and cost.

Handling timeouts and unknown results

Your product should not fail hard because a verification provider timed out.

Plan fallback behavior:

• Use a short timeout for real-time forms.
• Return unknown or “verification pending” internally.
• Allow low-risk flows to continue.
• Queue high-risk flows for retry.
• Do not block password resets only because verification is unavailable.
• Log provider failures without exposing unnecessary personal data.

Some recipient mail servers limit SMTP probes. Others tarpitted connections or return ambiguous results. Your application should treat unknown as a first-class result, not an error you forgot to handle.

Data Fields to Look For in API Responses

Strong API responses give you fields that both developers and marketers can act on.

Here is what to look for.

Normalized email and suggested correction

Normalization removes avoidable variation. It may trim spaces, lowercase domains, and return a canonical representation.

Suggested correction catches likely typos.

Example:

{
  "email": " Jane@Gmial.com ",
  "normalized_email": "jane@gmial.com",
  "suggested_correction": "jane@gmail.com"
}

Do not over-normalize provider-specific behavior unless you know the rules. For example, dot handling and alias handling vary by provider and should be handled carefully.

Deliverability status and risk score

Look for both a verdict and a score.

The verdict supports simple branching. The score supports thresholds and ranking.

Example:

{
  "verdict": "risky",
  "risk_score": 68,
  "confidence": "medium"
}

The API should document what higher or lower scores mean. Your team should define thresholds for each workflow.

Disposable domain flag

This should be a direct boolean or reason code.

{
  "disposable": true,
  "reason_codes": ["disposable_domain"]
}

For abuse-sensitive products, this field often drives immediate action.

Catch-all flag

Catch-all handling should be explicit.

{
  "catch_all": true,
  "verdict": "risky",
  "reason_codes": ["accept_all_domain"]
}

Do not bury this only inside an SMTP message. Marketers and sales teams need to understand it too.

Role-account flag

Role accounts affect personalization and consent quality.

{
  "role": true,
  "role_type": "support"
}

Use this to route B2B leads, support contacts, and billing contacts differently.

Free-provider flag

Free-provider detection helps with segmentation and scoring.

{
  "free_provider": true,
  "provider": "gmail"
}

Avoid treating this as a negative signal by default. Many excellent users use free providers.

MX and SMTP details

Developers need diagnostic detail.

Useful fields include:

• MX found or missing
• Mail server hostname
• SMTP status
• Timeout flag
• Temporary failure flag
• Mailbox accepted, rejected, or unknown
• Provider-specific limitation, if known

This helps you debug false positives, provider downtime, and domain-specific behavior.

Reason codes

Reason codes make the result operational.

Good reason codes are stable, documented, and readable:

• invalid_syntax
• domain_not_found
• mx_not_found
• mailbox_not_found
• smtp_timeout
• accept_all_domain
• disposable_domain
• role_account
• possible_typo
• temporary_failure

Reason codes should drive workflows. The human-readable message can change. The machine code should remain stable.

Security, Privacy, and Reliability Considerations

Treat email addresses as personal data and production infrastructure as failure-prone.

Reduce unnecessary exposure

Avoid logging full email addresses unless you need them.

Safer options:

• Log domain only.
• Log a hash of the full address.
• Redact the local part: j***@example.com.
• Store full responses only where access is restricted.
• Set retention periods for verification logs.

Be especially careful in frontend analytics, session replay tools, error trackers, and debug logs. Email addresses leak into these systems easily.

Use standard API security controls

Your integration should use:

• HTTPS
• Server-side API calls
• API keys stored in secret management
• Least-privilege access
• Rate limits
• Alerting on unusual usage
• Key rotation

Never call a verification provider directly from browser JavaScript with a secret key. Put your backend between the user and the provider.

Plan fallback behavior

Verification is part of your acceptance path. That makes reliability important.

Define behavior for:

• Provider timeout
• Provider error
• Network failure
• Rate limit response
• Partial result
• unknown verdict
• Degraded SMTP checks

For low-risk forms, you may allow submission and verify asynchronously. For high-risk account creation, you may show a retry or require email confirmation.

Understand data freshness

Disposable domain detection depends on current data. Ask providers how they update their disposable and burner domain intelligence.

You do not need a marketing claim. You need confidence that new throwaway domains are added continuously and stale entries are reviewed.

The same applies to typo detection and domain intelligence. The internet changes. Verification data should change with it.

How to Evaluate Email Deliverability API Providers

Evaluate providers with your data, your latency needs, and your operating model.

Compare the practical criteria

Use this checklist when you compare options:

Criterion	What to check	Why it matters
Accuracy	Results on known good, bad, disposable, catch-all, and typo samples	Prevents false confidence
Speed	Real-time response time under normal and peak load	Protects signup and form conversion
Verdict clarity	Clear statuses, scores, and reason codes	Makes automation easier
SMTP handling	Sensible use of SMTP email verification and unknown states	Reduces brittle decisions
Disposable coverage	Frequently updated burner-domain data	Stops low-quality accounts
Catch-all detection	Explicit accept-all flag and risk handling	Helps sales and marketing route leads
Documentation	Clear examples, field definitions, and error handling	Speeds implementation
Integrations	REST API plus workflow tools	Supports engineering and operations
Pricing model	Fits real-time checks, batch jobs, and growth	Avoids surprises
Trial or free tier	Lets you test before committing	Reduces vendor risk

Build a test set

Do not evaluate only with random emails.

Create a small labeled set:

• Known deliverable addresses you control
• Invalid domains
• Valid domains with fake mailboxes
• Disposable addresses
• Catch-all company domains
• Role accounts
• Free-provider addresses
• Common typo domains
• International or uncommon but valid formats, if your product accepts them

Then compare:

• Final verdict
• Reason codes
• Suggested corrections
• Latency
• Unknown rate
• False blocks
• False passes
• Developer experience

Pay close attention to how the provider handles ambiguity. An honest unknown is often better than a confident wrong answer.

Test the workflow, not just the endpoint

A provider may look good in a single API call but fail your actual process.

Test:

• Signup form behavior
• CRM field mapping
• Batch file handling
• Retry logic
• Rate limits
• Error responses
• Webhook or automation behavior
• Reporting for marketers
• Audit needs for support

If marketing cannot understand the output, they will create side spreadsheets. If engineering cannot trust the reason codes, they will hard-code fragile exceptions. Choose an API that works for both groups.

Bounceable is built for this kind of pre-send decisioning: real-time verification, disposable domain detection, catch-all flags, SMTP probing, typo suggestions, role and free-provider detection, bounce risk scoring, and clear verdicts through a clean REST API.

Choose based on actionability

The best provider is not the one with the longest feature list. It is the one that helps you decide what to do.

For each verdict and reason code, you should know the next action:

• Accept
• Prompt
• Block
• Challenge
• Suppress
• Retry
• Review
• Send at lower volume

That is the real job of an email deliverability API. It turns uncertain address quality into consistent pre-send decisions.