Email Deliverability API: What It Checks Before Send

An email deliverability API checks an address before you send to it. It helps you reject bad signups, clean CRM data, reduce bounce rates, and protect sender reputation without building verification logic yourself.

What is an email deliverability API?

An email deliverability API is a service that tells you whether an email address looks deliverable before you send mail to it.

You send an address to the API. It returns a result with checks like syntax validity, domain status, mailbox reachability, disposable domain status, catch-all behavior, typo suggestions, and a final deliverability verdict.

That makes it different from three related tools:

Tool type	What it does	When you use it
Email deliverability API	Checks if an address is valid or risky before sending	Signup, lead capture, CRM hygiene, outbound prep
Email sending API	Sends transactional or marketing email	Password resets, receipts, campaigns, sequences
Inbox placement tool	Tests whether mail lands in inbox, spam, or promotions	Diagnosing reputation, authentication, content, and placement issues

A sending API can still send to a bad address. It will just return a bounce later.

An inbox placement tool helps you understand where good mail lands. It does not validate every recipient address in your CRM.

A real-time email verification api sits earlier in the flow. It helps you avoid sending to addresses that are malformed, fake, disposable, inactive, or too risky.

That matters because bounces are reputation signals. Mailbox providers watch how recipients and servers respond to your mail. If you send to too many invalid addresses, you look careless or abusive. That can hurt future delivery, even to valid recipients.

Common use cases include:

• Signup forms: catch typos like gmial.com before the user leaves.
• Lead capture: block disposable or fake addresses from gated content forms.
• CRM cleanup: verify old contacts before a campaign or sequence.
• Outbound prospecting: reduce hard bounces before sales engagement tools send mail.
• Fraud control: flag burner domains and suspicious signup patterns.

Core checks a deliverability API should run

A useful deliverability API should check the address at multiple layers, because no single test tells the full story.

Syntax and DNS validation

Syntax validation answers a basic question: “Can this string be an email address?”

It catches obvious problems:

• Missing @
• Invalid characters
• Empty local part
• Spaces
• Broken domain format
• Consecutive dots in the wrong place

Syntax checks are fast. They are also incomplete. alex@example.com may have valid syntax and still be undeliverable.

DNS validation checks whether the domain can receive mail. A good email validation api should inspect mail-related DNS records, especially MX records. If a domain has no valid mail exchanger, there is usually nowhere to deliver the message.

DNS checks can catch:

• Domains that do not exist
• Domains without mail handling
• Misconfigured mail records
• Parked or inactive domains

You should treat syntax and DNS as the floor. Not the full verification.

Mailbox and SMTP-level verification where possible

SMTP email verification goes deeper. The API connects to the recipient mail server and checks whether the mailbox appears to exist.

This can improve accuracy, especially for business domains. But SMTP verification has limits.

Some servers disclose whether a mailbox exists. Others do not. Some accept every address during the SMTP conversation and bounce later. Some use greylisting, rate limits, tarpits, or anti-harvesting protections.

A good API handles this carefully. It should not overstate certainty when the receiving server refuses to give a clear answer.

You want response fields that separate:

• Domain validity
• MX availability
• SMTP connection status
• Mailbox-level confirmation
• Catch-all behavior
• Final verdict

That separation helps your application make better decisions.

Disposable and temporary email domain detection

Disposable addresses come from throwaway providers. Users create them to bypass signup gates, trials, lead forms, or abuse controls.

A disposable email detection api should compare the domain against a fresh and broad dataset. This is not a “set it once” check. Burner services appear, disappear, and rotate domains often.

Disposable domains are common in:

• Free trial abuse
• Fake account creation
• Low-quality lead capture
• Promo code abuse
• Scraped or purchased lists
• Bot-driven signup flows

For most commercial workflows, you should block disposable addresses or require an alternate email.

There are exceptions. A privacy-focused consumer product may choose to allow them. But you should make that decision knowingly, not because your validation missed them.

Catch-all domain detection and risk handling

Catch-all domains accept mail for any local part.

For example, a catch-all domain may accept all of these:

• sarah@company.com
• sales@company.com
• not-a-real-person@company.com
• x9281-test@company.com

Catch-all email detection matters because SMTP may say “accepted” even when the individual mailbox does not exist. That creates uncertainty.

Do not treat catch-all as automatically good or bad. Treat it as a risk condition.

A strong API should detect catch-all behavior and still probe the mailbox where possible. It should then return a verdict that reflects the uncertainty.

For example:

• A known business domain with a catch-all setup may be acceptable for outbound.
• A random catch-all domain from a low-quality source may deserve review.
• A catch-all address from a signup form may need email confirmation before account activation.

Role account, free provider, and typo detection

Role accounts belong to functions, not individuals. Examples include:

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

They can be valid. But they behave differently from personal inboxes.

For B2B sales, role accounts may convert poorly. For product notifications, they may be shared by a team. For admin alerts, they may be exactly what you want.

Free provider detection identifies addresses at domains like Gmail, Outlook, Yahoo, and similar consumer mailbox providers. That can help with lead scoring, fraud signals, and routing.

Typo detection is one of the highest-ROI checks on signup forms. A user who types gmial.com probably meant gmail.com. A good API should suggest a correction instead of forcing you to write and maintain typo rules.

Example result shape:

{
  "email": "alex@gmial.com",
  "verdict": "undeliverable",
  "risk_score": 92,
  "checks": {
    "syntax": "valid",
    "dns": "invalid_mx",
    "disposable": false,
    "catch_all": false,
    "role": false,
    "free_provider": false
  },
  "suggestion": "alex@gmail.com"
}

Understanding API verdicts and risk scores

A good API verdict summarizes what you should do next, but it should not hide the underlying reasons.

Most providers use verdicts similar to these:

Verdict	Typical meaning	Common action
deliverable	The address appears valid and safe to send	Accept and send normally
risky	The address may work, but signals add uncertainty	Challenge, confirm, throttle, or review
undeliverable	The address is invalid or very likely to bounce	Block or suppress
unknown	The API could not determine enough with confidence	Use a fallback rule based on business risk

A single true/false result is often too simple.

Email verification is probabilistic once you move beyond syntax. Receiving servers can hide mailbox status. Catch-all domains blur the signal. Temporary network issues can prevent a clean SMTP response. Greylisting can make a valid address look uncertain.

That is why bounce risk scoring helps. A score lets you tune behavior by workflow.

For example:

• A newsletter signup can reject high-risk addresses.
• A SaaS signup can allow a risky address but require verification before full access.
• A sales team can send to some risky business domains but avoid high-risk consumer or disposable addresses.
• A fraud system can combine email risk with IP, device, and velocity signals.

The verdict gives you the default action. The risk score gives you control.

Here is a simple way to map results:

API signal	Signup form	Marketing list	Sales outbound
Deliverable	Accept	Keep	Send
Typo suggestion	Ask user to confirm fix	Correct only with consent or review	Review
Disposable	Block or challenge	Suppress	Suppress
Catch-all	Accept with confirmation	Segment or test carefully	Allow if ICP fit is strong
Risky	Require confirmation	Suppress or re-permission	Review or throttle
Undeliverable	Block	Suppress	Suppress
Unknown	Allow with verification email	Hold	Review

Where to integrate the API

You get the best results when you verify addresses at the point where bad data enters or before mail goes out.

Inline signup validation with user-friendly correction messages

Inline validation catches mistakes while the user can still fix them.

Use it for:

• Account signup
• Checkout email fields
• Demo request forms
• Newsletter forms
• Gated content forms
• Trial forms

Keep the message helpful. Do not expose technical details like “MX lookup failed” to the user.

Good messages:

• “Did you mean alex@gmail.com?”
• “This email address does not look valid. Please check it.”
• “Please use a permanent email address.”
• “We could not verify this email. Try another address or continue with email confirmation.”

Bad messages:

• “SMTP verification failed.”
• “Your domain is risky.”
• “Invalid lead quality.”

You want fewer fake addresses without frustrating real users.

Backend checks before creating accounts or sending verification mail

Frontend checks improve user experience, but backend checks enforce the rule.

Run verification server-side before:

• Creating an account
• Sending a magic link
• Sending a verification email
• Issuing a coupon
• Starting a trial
• Pushing a lead into your CRM
• Triggering a sales sequence

This protects you from skipped JavaScript, bots, and direct API abuse.

An illustrative request might look like this:

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

Do not hard-code secrets in frontend code. Keep API keys on the server.

CRM enrichment and list hygiene jobs

Old CRM data decays. People change jobs. Domains expire. Companies rebrand. Mailboxes close.

Use verification jobs before:

• Large newsletter sends
• Product announcements
• Re-engagement campaigns
• Sales outbound imports
• Customer lifecycle migrations
• Data warehouse syncs

For existing contacts, avoid silently changing addresses based only on a typo suggestion. Log the suggestion and review it, or ask the contact to confirm.

For suppression, store the reason. “Undeliverable” is useful. “No MX record” or “disposable domain” is better.

Zapier, Pipedream, Apify, and other workflow automation patterns

You do not always need custom code.

Workflow automation works well when the volume is moderate or the process spans several tools.

Patterns that work:

• Verify new Typeform or Webflow leads before creating a CRM contact.
• Check HubSpot or Salesforce records before enrolling them in a sequence.
• Clean rows in Google Sheets before upload.
• Verify emails collected by an Apify scraper before outbound.
• Use Pipedream to add custom branching based on verdict and risk score.

Bounceable supports a REST API plus Zapier, Pipedream, and Apify integrations, which makes these patterns easier to deploy without waiting on a full engineering sprint.

Developer evaluation checklist

Pick an API you can operate safely in production, not just one that returns a green checkmark in a demo.

REST API clarity

An email verification rest api should be easy to call and easy to reason about.

Look for:

• Clear authentication
• Simple request shape
• Stable response fields
• Documented verdict meanings
• Machine-readable reasons
• Separate fields for each check
• Example responses for edge cases
• Consistent error handling

You should know the difference between “the email is unknown” and “the API request failed.”

Those are not the same condition.

Latency, uptime, and rate limits

Real-time form checks need low latency. Batch hygiene jobs need throughput and predictable limits.

Ask:

• Can the API support your peak signup traffic?
• What happens when rate limits are hit?
• Are there retries or backoff recommendations?
• Can you set a timeout and fallback behavior?
• Does the provider publish uptime or operational status?

For inline validation, set a sensible timeout. If verification takes too long, do not freeze the user.

For backend enforcement, decide whether the safe fallback is “allow and verify by email” or “hold and retry.” The right choice depends on your risk tolerance.

Data privacy and safe handling

Email addresses are personal data in many contexts.

Check how the provider handles:

• Data retention
• Logging
• Access controls
• Encryption in transit
• Subprocessors
• Regional requirements
• Deletion requests
• Use of queried addresses

You should also minimize what you send. The API needs the email address. It usually does not need the user’s name, phone number, company revenue, or internal lead score.

Freshness of disposable domain data

Disposable domain detection gets stale fast.

Evaluate:

• How broad the disposable domain dataset is
• How often it updates
• Whether new burner domains are added quickly
• Whether the API distinguishes disposable from free providers
• Whether you can see the reason in the response

A stale disposable list creates a false sense of safety.

Webhook, batch, and automation support

Your first use case may be a signup form. Your next one may be CRM cleanup.

Look for support that matches your roadmap:

• Real-time API calls
• Bulk or batch verification
• Webhooks or async workflows
• CSV or list processing
• Zapier integration
• Pipedream integration
• Apify integration
• Clear export fields for CRM updates

You want one verification layer that can support multiple teams.

Example decision rules

Good decision rules are simple, explicit, and logged.

Start conservative. Then adjust with real bounce data, conversion data, and abuse patterns.

Accept deliverable addresses automatically

If the API returns deliverable, accept the address and continue.

For example:

• Create the account.
• Send the verification email.
• Add the lead to the CRM.
• Allow marketing opt-in.
• Enroll the prospect if they meet other rules.

Still log the result. A deliverable address today can become stale later.

Suggested log fields:

• Email hash or normalized email, depending on your privacy model
• Verdict
• Risk score
• Disposable flag
• Catch-all flag
• Role flag
• Free provider flag
• Timestamp
• Source form or workflow
• Action taken

Challenge or review risky and catch-all addresses

Risky does not always mean bad. It means you need another control.

For signup flows, you can:

• Require email confirmation before access
• Delay high-risk actions
• Limit free trial abuse paths
• Ask for a work email
• Route suspicious signups to review

For sales outbound, you can:

• Keep strong-fit business domains
• Remove weak-fit risky contacts
• Send at lower volume
• Prioritize contacts with additional confirmation signals
• Avoid adding risky contacts to shared sequences automatically

For catch-all domains, combine API output with context. A catch-all address at a known target account may be worth a careful send. A catch-all address from a scraped source may not be.

Block disposable or undeliverable addresses

Undeliverable addresses should not receive mail. Suppress them.

Disposable addresses usually deserve a hard block in commercial workflows, especially when the user receives value before proving identity.

Example rules:

function decideEmailAction(result) {
  if (result.verdict === "undeliverable") return "block";
  if (result.checks?.disposable === true) return "block";
  if (result.verdict === "deliverable") return "accept";

  if (result.checks?.catch_all === true) return "challenge";
  if (result.verdict === "risky") return "challenge";
  if (result.verdict === "unknown") return "verify_by_email";

  return "review";
}

Keep the rule readable. Your support, growth, and security teams should understand it.

Log results for deliverability monitoring and fraud analysis

Verification is not just a gate. It is also telemetry.

Track trends by source:

• Which forms produce the most undeliverable addresses?
• Which lead vendors send the most disposable domains?
• Which campaigns collect the most typo corrections?
• Which outbound sources create the most bounces?
• Which signup paths show suspicious velocity?

This gives you leverage. You can fix bad forms, cut poor data sources, and tune fraud controls.

You should also compare API results with downstream outcomes:

• Hard bounces
• Soft bounces
• Verification email confirms
• Spam complaints
• Trial abuse
• Sales replies
• Unsubscribes

That feedback loop helps you tune thresholds. It also keeps teams honest. The goal is not to block the most addresses. The goal is to block the right ones before they damage sender reputation or pollute your systems.

A deliverability API works best when you treat it as infrastructure. Put it where email data enters. Use the full verdict and risk context. Log the result. Then adjust your rules based on real outcomes.