Real-Time Email Verification API for Signup Forms

A real-time email verification API helps you catch bad addresses before they enter your product, not after they bounce. For signup forms, the goal is simple: verify the email before signup completes, but keep the form fast enough that good users do not notice the check.

Why Real-Time Verification Matters at Signup

Real-time verification matters because the signup form is where most email data quality problems start.

Bad addresses usually enter your system in a few predictable ways:

• Typos: gmial.com, hotmial.com, yaho.com, missing dots, extra characters.
• Bots: automated signups that use fake or generated addresses.
• Disposable emails: throwaway inboxes used to get a free trial, coupon, asset, or one-time access.
• Low-intent users: people who enter a fake address because they do not trust the form yet.
• Copy/paste mistakes: whitespace, invisible characters, or pasted addresses with labels.

If you accept those addresses, you pay for the mistake later. Verification emails do not arrive. Password resets fail. Sales reps chase dead leads. Lifecycle campaigns bounce. Your sender reputation takes the hit.

Email providers watch how recipients respond to your mail. High hard bounce rates are a negative signal. So are spam complaints and low engagement. A few bad addresses do not ruin a program, but bad collection habits compound quickly when you send at volume.

Real-time email verification gives you a chance to fix the address while the user is still present. That is the key difference.

Pre-submit verification versus batch cleaning

Batch cleaning is still useful. You should clean old lists before major sends, migrations, reactivation campaigns, or cold outreach. But batch cleaning happens after the bad address has already polluted your database.

Pre-submit verification works earlier:

Approach	When it runs	Best for	Limitation
Client-side format validation	While typing or before submit	Catching obvious syntax issues	Cannot prove deliverability
Real-time verification API	During signup submission	Blocking or warning on bad addresses	Needs timeout and fallback handling
Batch list cleaning	Before campaigns or imports	Cleaning existing data	Cannot recover lost signup intent

For signup forms, use all three at the right layer. Check basic syntax in the browser. Verify deliverability on the server. Recheck old or high-risk addresses before large sends.

What a Real-Time Email Verification API Checks

A real-time email verification API checks whether an address is structurally valid, technically reachable, and risky to accept.

The exact signals vary by provider, but a practical API should return more than a yes/no answer. You want a verdict plus supporting reasons so you can make product-specific decisions.

Syntax and normalization

The first layer is basic parsing.

A verification service should catch issues like:

• Missing @
• Empty local part or domain
• Invalid characters
• Consecutive dots where not allowed
• Leading or trailing whitespace
• Domains with illegal format

It should also normalize the value before deeper checks. For example:

"  Jane.Doe@Gmail.com " → "jane.doe@gmail.com"

Do not rely on a complicated regex as your only protection. Email syntax has edge cases, and a syntactically valid address can still be completely undeliverable.

Domain and MX availability

After syntax, the API should check the domain.

Useful domain checks include:

• Does the domain exist?
• Does it have DNS records?
• Does it publish MX records?
• If no MX exists, can the domain receive mail through fallback records?
• Does the domain look parked, inactive, or misconfigured?

An address like person@example.invalid may pass a loose format check. It should fail domain-level verification.

Disposable and burner domain detection

Disposable email detection API features matter when your form grants access, credits, coupons, trials, or gated content.

Disposable domains are used for temporary inboxes. Some are harmless in low-risk contexts. Others indicate low intent or abuse. You should not treat every disposable address the same way across every product.

Common use cases for blocking disposable addresses:

• Free trial abuse
• Promo code abuse
• Community spam
• Marketplace fraud
• Lead gen forms where sales follow-up is expensive
• Products that need long-term account recovery

Bounceable maintains a constantly updated list of tens of thousands of disposable and burner domains, because this category changes often. New throwaway services appear all the time. A static blocklist ages quickly.

SMTP mailbox probing

Mailbox probing attempts to determine whether the specific mailbox can receive mail.

The API connects to the recipient mail server and asks, in effect, whether the address is accepted. This can catch addresses where the domain is valid but the mailbox is not.

For example:

• alex@company.com may exist.
• alxe@company.com may not exist.
• The domain can receive mail, but that specific user does not exist.

SMTP probing is useful, but it is not perfect. Some mail servers block probes. Some greylist. Some accept every address during SMTP and bounce later. Some return temporary failures. This is why you need verdicts like risky and unknown, not only valid and invalid.

Catch-all and unknown handling

Catch-all email detection identifies domains that accept mail for any local part.

For example, a catch-all domain may accept:

john@company.com
notarealperson@company.com
random-string-123@company.com

That does not mean every address is good. It means SMTP cannot confirm the mailbox in the usual way.

Treat catch-all results as a risk signal, not an automatic rejection. Many real businesses use catch-all configurations. If you sell B2B software, blocking all catch-all domains can block legitimate prospects.

unknown is similar. It means the API could not confidently prove deliverability. Reasons can include temporary mail server issues, throttling, network failures, greylisting, or defensive mail infrastructure.

Role account and free provider flags

Role accounts represent teams or functions instead of a person:

• info@
• support@
• admin@
• sales@
• billing@
• hr@

They are not always bad. A small business owner may use info@company.com as their main address. But role accounts often perform differently in lifecycle marketing and sales outreach. They may have lower engagement, multiple readers, or stricter filtering.

Free provider flags identify addresses at providers like Gmail, Outlook, Yahoo, and similar services. Again, this is not bad by itself. Many excellent users sign up with free email addresses. The flag helps you segment and score, not reject by default.

Typo suggestions such as gmial.com to gmail.com

Email typo correction is one of the highest-value signup form improvements because it helps legitimate users.

Good verification APIs suggest corrections for common domain mistakes:

jane@gmial.com → jane@gmail.com
sam@hotnail.com → sam@hotmail.com
lee@outlok.com → lee@outlook.com

This is different from silently changing the address. Do not auto-correct without user confirmation. Show a clear prompt:

Did you mean jane@gmail.com?

That keeps the user in control and avoids changing a valid but unusual domain by mistake.

Where to Place Verification in the Signup Flow

Place verification after the user enters an email, but before you commit the account or send important mail.

You have two main patterns: inline validation while typing and validation on submit.

Inline validation while typing

Inline validation works well for cheap checks:

• Required field
• Basic syntax
• Obvious invalid characters
• Whitespace trimming
• Confirm email fields, if you use them

You can also trigger real-time email verification after the field loses focus, but be careful. Calling an API on every keystroke is wasteful and can create a jumpy user experience.

If you verify inline, use:

• Debouncing
• Minimum length checks
• Request cancellation
• Clear loading states
• A short timeout
• Server-side rate limiting

Inline verification can be helpful when typo correction is central to the UX. For example, you can show “Did you mean gmail.com?” before the user clicks submit.

Validation on submit

Submit-time validation is usually the safest default.

The user fills the form. They click submit. Your backend verifies the email. Then you decide whether to create the account, block the request, or ask for confirmation.

This pattern has several benefits:

• Fewer API calls
• Better control over secrets
• Simpler logging
• Easier abuse protection
• Cleaner fallback behavior

For most signup forms, run browser format checks first, then call the verification API from your server during submit.

When to warn, block, or allow

Your action should depend on the verdict and your product risk.

Block only when you have high confidence that the address is bad. Warn when the address may be deliverable but carries risk. Allow when the result is uncertain and the cost of false rejection is high.

Examples:

• Consumer newsletter: warn on typo, allow unknown, maybe allow disposable.
• Free SaaS trial: block undeliverable, warn catch-all, block or step-up disposable.
• Marketplace seller account: block undeliverable, require confirmation for risky, likely block disposable.
• B2B demo request: do not block catch-all domains by default; request confirmation if needed.

How to avoid slowing down the form experience

Users notice slow forms. Keep the verification path tight.

Use these safeguards:

1. Set a short timeout. Do not let verification hang the signup request forever.
2. Cache repeat checks. If the same address is retried, reuse a recent result where appropriate.
3. Fail with a policy. Decide in advance what happens if the API is unavailable.
4. Log every fallback. You need to know when verification did not run.
5. Avoid client-side secrets. Your API key does not belong in browser code.

A good target is that most users never think about verification. They either continue normally or get one clear, useful correction.

Recommended UX Patterns for Each Verdict

Use the verification verdict to guide the user, not to punish them.

Here is a practical starting point:

Verdict or signal	Recommended action	User-facing message
Deliverable	Accept and continue	No message needed
Undeliverable	Block and ask for correction	“We couldn’t verify this email. Check for typos and try again.”
Risky	Warn or request confirmation	“This email may not receive messages. Please confirm it is correct.”
Unknown	Allow with safeguards	“We’ll ask you to confirm this email before continuing.”
Disposable	Block, warn, or step up based on risk	“Please use a permanent email address.”
Catch-all	Usually allow with safeguards	No hard block unless your risk model requires it
Typo suggestion	Ask user to accept correction	“Did you mean jane@gmail.com?”

Deliverable: accept and continue

If the API returns deliverable, do not add friction. Create the account, start the session, or continue the flow.

You may still want double opt-in for compliance or list quality, but do not show a verification success banner just to show one. Extra messages can distract users.

Undeliverable: block with a clear correction prompt

If the address is undeliverable, block the submission. But keep the message plain.

Good:

We couldn’t verify this email. Check for typos and try again.

Bad:

SMTP RCPT TO failed with mailbox unavailable.

Users do not need protocol details. They need to know what to fix.

If you have a typo suggestion, show it as a one-click option:

Did you mean alex@gmail.com?

Risky: warn, request confirmation, or require double opt-in

Risky means the address may work, but the API found signals that reduce confidence.

Risk signals can include:

• Catch-all domain
• Temporary SMTP failure
• Suspicious domain pattern
• Role account
• Recent disposable classification
• Low confidence mailbox response

You can handle risky addresses in several ways:

• Ask the user to retype or confirm the address.
• Allow signup but require email confirmation before full access.
• Limit high-risk actions until the email is confirmed.
• Add the risk score to your fraud or lead scoring model.

Email risk scoring is most useful when you combine it with your own context. A risky email from a trusted paid acquisition source may deserve different treatment than a risky email from a high-abuse endpoint.

Unknown: allow with safeguards rather than reject by default

Unknown is not the same as bad.

Rejecting all unknown results creates false negatives. You will block real users because their mail server timed out, greylisted the probe, or refused verification attempts.

A better default:

• Allow account creation.
• Require email confirmation before sending sensitive messages.
• Suppress non-essential marketing until confirmed.
• Recheck later before campaign sends.

This protects conversion while still reducing deliverability damage.

Disposable: decide based on product risk and acquisition channel

Disposable emails are a policy decision.

If you run a public documentation site and ask for an email to send a download link, blocking disposable addresses may hurt goodwill. If you run a free trial that can be abused for credits, blocking disposable addresses may be necessary.

You can also vary rules by acquisition channel:

• Paid search trial signup: block or require permanent email.
• Organic newsletter signup: warn only.
• Internal invite flow: allow, but require confirmation.
• Promo campaign: block known disposable domains.

Do not hide the policy behind a vague error. Say what you need:

Please use a permanent email address so you can receive account and security messages.

Developer Implementation Checklist

A robust implementation keeps secrets on the server, sets explicit fallback rules, and stores the result for later use.

Use this checklist as a baseline.

1. Use client-side format checks before calling the API

Start with cheap checks in the browser. This reduces unnecessary API calls and gives instant feedback.

Client-side validation should catch:

• Empty value
• Missing @
• Obvious malformed domain
• Leading or trailing spaces
• Mismatched confirmation field, if present

Keep it simple. Do not try to prove deliverability in JavaScript.

function looksLikeEmail(value) {
  const email = value.trim();
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}

This regex is intentionally basic. It is a first pass, not your source of truth.

2. Call the verification endpoint server-side for security

Your backend should call the real-time email verification API. That keeps your API key private and lets you enforce rate limits.

A typical server-side request looks like this:

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

A useful response should include the verdict and signals:

{
  "email": "jane@gmial.com",
  "normalized_email": "jane@gmial.com",
  "verdict": "undeliverable",
  "risk_score": 92,
  "checks": {
    "syntax": true,
    "domain_has_mx": false,
    "disposable": false,
    "catch_all": false,
    "role": false,
    "free_provider": false
  },
  "suggestion": "jane@gmail.com"
}

The field names will differ by provider. The important part is that your application receives enough detail to make a decision.

3. Set timeout and fallback behavior

Do not let verification become a single point of signup failure.

Set a short timeout and define fallback behavior before launch:

Failure case	Recommended fallback
API timeout	Allow signup, mark verification as not_checked, require email confirmation
API 5xx	Allow or queue for retry, depending on product risk
Rate limit	Fail closed for abusive sources, fail open for trusted flows
Network error	Allow with safeguards and log the error
Malformed API response	Treat as verification failure and alert internally

Failing open can be acceptable. Failing open silently is not. Always log the failure state.

4. Store the verdict and risk signals with the user record

Do not throw away verification results after signup.

Store fields such as:

• Normalized email
• Verification verdict
• Risk score
• Disposable flag
• Catch-all flag
• Role account flag
• Free provider flag
• Typo suggestion shown or accepted
• Verification timestamp
• Provider response version, if available

This data helps other systems make better decisions. Lifecycle marketing can suppress unconfirmed risky users. Sales can prioritize deliverable business addresses. Fraud systems can combine email risk with IP, device, velocity, and payment signals.

5. Recheck stale addresses before high-volume sends

Email data decays. People leave companies. Domains expire. Mailboxes get disabled.

Recheck addresses before:

• Large newsletter sends
• Reactivation campaigns
• Product migrations
• Cold outreach sequences
• Long-delayed onboarding campaigns
• Sending to users who have not engaged in months

Real-time checks protect the signup moment. Batch rechecks protect future sends.

Common Mistakes to Avoid

Most signup verification problems come from treating email quality as a binary field instead of a risk decision.

Avoid these mistakes.

Relying only on regex

Regex can tell you whether an address looks like an email. It cannot tell you whether the domain receives mail, the mailbox exists, or the address belongs to a disposable provider.

Use regex for quick feedback. Use verification for deliverability.

Blocking all free email providers

Free email addresses are not low quality by default.

Many buyers, founders, developers, students, and consumers use free providers. Blocking all free domains can damage conversion and create a bad first impression.

Flag free providers. Segment them. Score them if needed. Do not blanket-block them unless you have a very specific business reason.

Treating catch-all domains as always bad

Catch-all email detection gives you uncertainty, not proof of failure.

Some catch-all domains belong to legitimate companies. If you block them all, you may reject valuable B2B signups.

Better options:

• Allow signup but require confirmation.
• Add a small risk score increase.
• Recheck before sales outreach.
• Combine with domain quality, source, and behavior.

Failing open without logging verification failures

You may decide to allow signups when verification fails. That is fine for many products.

But you need visibility.

Track:

• Timeout count
• API error count
• Fallback allow count
• Fallback block count
• Verification latency
• Verdict distribution over time

If verification stops working and you fail open silently, your bounce rate may climb before anyone notices.

Showing overly technical error messages to users

Your API may return detailed diagnostic reasons. Keep those for logs.

Users should see short, actionable messages:

• “Check for typos and try again.”
• “Did you mean name@gmail.com?”
• “Please use a permanent email address.”
• “Please confirm this email before continuing.”

Do not show SMTP codes, MX details, risk scores, or provider internals in the form.

Measuring the Impact After Launch

Measure both signup conversion and downstream email quality so you can tune the rules without guessing.

Start with a baseline before launch if you can. Then compare the same metrics after rollout.

Track these metrics:

• Signup conversion rate: Did added validation reduce completed signups?
• Email field error rate: How often do users hit a warning or block?
• Typo correction rate: How often do users accept suggested fixes?
• Disposable email rate: Which sources send the most burner addresses?
• Verification email delivery: Are confirmation emails arriving more reliably?
• Confirmation rate: Do more users confirm after typo correction?
• Hard bounce rate: Did bounces drop for onboarding and lifecycle mail?
• Spam complaint rate: Did lower-quality sources produce complaints?
• Unknown and risky rate: Are some domains or regions overrepresented?
• API latency and timeout rate: Is verification affecting form speed?

Compare quality by acquisition source

Do not judge the whole signup funnel as one bucket. Segment by source.

Useful cuts include:

• Paid search campaign
• Paid social campaign
• Affiliate or partner source
• Organic search
• Direct traffic
• Product invite
• API-created account
• Country or region
• Device type
• Form variant

You may find that one channel drives most disposable addresses. Or that a high-volume paid campaign has a typo problem because the landing page attracts mobile users. Or that a partner integration sends malformed emails because it does not trim whitespace.

Those findings help you fix the source instead of over-tightening the form for everyone.

Use results to tune blocking and warning rules

Your first policy will not be perfect. Treat it as a controlled rollout.

A sensible launch plan:

1. Observe mode: Call the API, store verdicts, but do not block. Measure what would have happened.
2. Soft warning mode: Show typo suggestions and disposable warnings. Block only clearly undeliverable addresses.
3. Risk-based mode: Add stricter rules for high-abuse sources, promotions, or trial flows.
4. Ongoing tuning: Review conversion, bounce, complaint, and confirmation metrics monthly.

For many teams, the best default is:

• Block undeliverable.
• Suggest corrections for obvious typos.
• Warn or step up risky.
• Allow unknown with email confirmation.
• Treat disposable based on product risk.
• Do not block catch_all by default.

Bounceable can support this pattern with real-time email verification, disposable domain detection, catch-all handling, typo suggestions, and deliverability verdicts you can store with the user record.