Email Validation API: How It Works and Why It Matters

An email validation API is a service your application calls to assess whether an email address is correctly formatted, connected to a domain that can receive mail, and likely deliverable. It returns structured results that let you block obvious bad addresses, flag uncertain ones, and protect sending reputation before messages create hard bounces.

What is an email validation API?

An email validation API is a programmatic address-checking service. Instead of asking a person to inspect a spreadsheet or relying only on a browser form field, an application sends an address to an API and receives a machine-readable response about that address.

The response commonly separates several questions that are easy to confuse:

• Is the address written in a plausible email format?
• Does the domain exist?
• Does that domain publish DNS records that indicate it accepts email?
• Can the receiving mail system provide a meaningful signal about the mailbox?
• Is the address disposable, role-based, temporary, catch-all, risky, or otherwise uncertain?

That distinction matters because an address can pass a basic format check and still be a poor destination for email. For example, person@example lacks a valid-looking domain structure and should fail early. person@company-that-no-longer-exists.com may look properly formatted but fail when its domain is checked. info@realcompany.com may be syntactically sound and deliverable, yet it can still be a shared role inbox that deserves different treatment in a sales or marketing workflow.

An API makes these checks available at the point where an address enters your system. That could be during account signup, a lead-import job, a checkout flow, a CRM sync, or immediately before a campaign audience is created. The goal is not to promise that every accepted address will result in an inbox placement. The goal is to make better, earlier decisions about address quality and to prevent clearly avoidable failures.

Why email validation matters for deliverability

Deliverability is the ability to reach a recipient's inbox or at least a recipient's mail system successfully. Address validation is only one part of deliverability, but it is a foundational one: sending mail to addresses that do not exist creates avoidable negative delivery signals.

A hard bounce occurs when a receiving system permanently rejects a message, often because a mailbox or domain does not exist. Repeatedly sending to invalid recipients wastes volume, reduces the quality of campaign data, and can make a sender look less careful to mailbox providers. An email validation API helps intercept likely invalid records before they become hard bounces in production.

This is especially important for bulk sends. A transactional application might send a password reset to one typoed address and learn from the resulting bounce. A campaign sent to 100,000 old or purchased contacts can create thousands of failures at once. The scale changes both the operational cost and the potential reputation impact.

Mailbox providers also expect senders to follow sound sending practices. Gmail's sender guidance emphasizes authentication, avoiding unwanted mail, and giving recipients an easy way to unsubscribe; its tools expose spam-rate, authentication, reputation, and delivery-error information. Address validation does not replace those requirements, but it supports the same broader discipline: send wanted mail to people who can receive it, maintain clean lists, and investigate delivery failures rather than repeatedly retrying them.

Validation improves data quality before sending

The earliest validation point is often the most valuable. If a user mistypes gmial.com instead of gmail.com while registering, catching the issue before creating the account can prevent a failed verification email, a support ticket, and an unreachable customer record.

For lead forms, validation can reduce the amount of junk data that enters a CRM. For product emails, it can reduce failed invitations, abandoned onboarding flows, and billing-notice failures. For newsletters, it can make engagement reporting more meaningful because fewer messages are counted against an audience that was never reachable.

It does not replace permission or relevance

A valid address is not permission to email someone. An email validation API cannot prove that the address owner subscribed, wants your message, recognizes your brand, or will find the message relevant.

That means validation should sit alongside consent capture, suppression management, authentication, clear unsubscribe handling, segmentation, and content quality. A clean list can still generate complaints if it was collected improperly. Conversely, a properly permissioned list can deteriorate over time as people change jobs, abandon inboxes, or switch providers.

How an email validation API works

Validation services usually combine several layers of evidence. The exact checks, data sources, result labels, and confidence rules vary by provider, so your application should treat the API response schema as the contract rather than assuming every service uses the same labels.

1. Syntax and normalization checks

The first layer checks whether an address resembles a usable mailbox address: a local part, an @ symbol, and a domain portion that can be interpreted under email-address rules. This catches common input errors such as spaces, missing separators, doubled punctuation in the wrong position, or an empty local part.

Normalization may also remove leading and trailing whitespace or standardize the domain for lookup. It should not blindly rewrite the local part. Local-part behavior can be mailbox-provider-specific, and changing it without a documented reason may send to a different recipient or create incorrect records.

A syntax pass is useful, but it is a low bar. hello@not-a-real-domain.example can be structurally valid even though it cannot receive production email. That is why syntax validation alone should be described as format validation, not deliverability validation.

2. Domain and DNS checks

Next, the service checks whether the domain can be resolved and whether it appears configured to receive email. Mail delivery normally relies on DNS information, including MX records that identify mail exchangers. If no usable mail route can be found, the address is unlikely to be deliverable.

A domain-level result is stronger than a format result, but it still does not confirm a mailbox. A company can operate mail for company.com while alex@company.com does not exist. Domain checks are therefore useful for filtering broken domains, expired domains, and obvious entry mistakes, but they cannot settle every address-level question.

3. SMTP-level mailbox signals

Some validation systems attempt to obtain a response from the recipient domain's mail infrastructure using SMTP behavior. SMTP is the protocol used for mail transfer, and recipient acceptance is associated with the RCPT TO stage of an SMTP conversation.

This is not a simple universal mailbox lookup. Many receiving systems intentionally limit or obscure mailbox-verification responses to reduce directory harvesting, abuse, and privacy risks. A server may accept a recipient provisionally and decide later, defer a response, rate-limit the connection, or use policies that prevent a validation provider from reaching a definitive conclusion.

For that reason, a responsible email validation API returns uncertainty when the evidence is incomplete. A result such as unknown, unverifiable, or accept-all is not necessarily a bad address. It means the service cannot safely classify it as a confirmed deliverable mailbox based on the available signals.

4. Catch-all or accept-all detection

Some domains accept mail for virtually any local part. These are commonly called catch-all or accept-all domains. If random-name@domain.com receives the same acceptance behavior as a known address, an API may identify the domain as catch-all.

Catch-all status complicates validation. An address at that domain may be real, but SMTP acceptance alone cannot verify it. A sender should not automatically label all catch-all addresses invalid. Instead, handle them as a separate risk category and choose a policy that matches the message type, audience source, and cost of a possible bounce.

For a password reset, sending to a catch-all address that the user supplied may be reasonable. For a high-volume cold outreach campaign, you may decide to exclude catch-all records, send them in a small monitored segment, or require additional evidence before mailing them.

5. Risk and classification signals

Many services add classifications beyond deliverability. Common examples include disposable-email domains, role accounts, free-mail domains, and addresses associated with abuse-risk patterns. These classifications are useful context, not automatic verdicts.

A disposable address may be unsuitable for a long-term customer relationship but entirely legitimate for a privacy-conscious user evaluating a product. A role account such as support@, sales@, or admin@ may be inappropriate for a person-level nurture sequence, yet it may be the correct operational contact for a vendor relationship. Your policy should reflect the use case instead of treating every non-personal address as inherently bad.

What an email validation API can and cannot tell you

An effective implementation begins with realistic expectations. The API is a decision-support layer, not an oracle that can see inside every recipient mailbox.

An email validation API can often help you identify:

• Malformed addresses and obvious typographical errors.
• Domains that do not resolve or do not appear able to receive mail.
• Addresses with strong evidence of mailbox rejection.
• Temporary or disposable address domains.
• Role-based addresses that may need separate handling.
• Catch-all domains and other cases where mailbox status is uncertain.

It cannot reliably guarantee all of the following:

• That a person currently reads the inbox.
• That the mailbox owner consented to your emails.
• That a message will reach the inbox rather than spam.
• That the recipient will open, click, purchase, or respond.
• That a mailbox that was valid today will remain valid next month.
• That an address at a catch-all domain belongs to the intended person.

This limitation is important for both product design and reporting. Do not call an address “verified” in a customer-facing interface if the system only checked its syntax and domain. Prefer precise language such as “address format accepted,” “domain can receive mail,” “likely deliverable,” or “unable to verify mailbox,” depending on the result you actually have.

Email validation API results and decision policies

The best operational use of a validation API is not merely storing a score. It is mapping results to a clear action. That action should be different for an account-registration form, a transactional message, and a marketing import.

A practical result model

Although result fields differ among providers, your own application can normalize them into a small internal policy model:

This model is intentionally simpler than any provider's raw response. It gives product, CRM, and sending teams a shared vocabulary while preserving the detailed response for troubleshooting.

Policies by use case

For a signup form, block clearly malformed and undeliverable addresses. For a risky or unknown result, consider allowing registration but requiring an email-confirmation step before enabling high-value features. This reduces friction while still ensuring the user can receive account messages.

For transactional mail, do not block necessary messages solely because a result is unknown. A customer may need an invoice, security alert, receipt, or reset link, and unknown is not the same as invalid. Instead, send when appropriate, record the result, and use bounce events to update the record afterward.

For a marketing import, use more caution. Exclude undeliverable addresses, honor existing suppressions, and consider quarantining risky and unknown records until you can validate their source, recency, and consent. If the list is old, validate in bulk before creating the audience rather than discovering problems during the campaign.

How to integrate an email validation API

Integration should be intentional. Calling a validation endpoint from every keystroke can create unnecessary latency, cost, and confusing form behavior. Calling it only after a campaign has begun is too late. The right pattern usually combines lightweight client-side checks with a server-side validation decision.

Validate at the right moments

Common integration points include:

1. Form submission: Run basic browser checks first, then validate server-side after the user submits the form.
2. Account creation: Validate before creating an active customer profile, then confirm ownership through a verification message.
3. CSV or CRM import: Submit addresses in a bulk process, store the results, and show the operator what will be excluded or held.
4. Pre-send campaign hygiene: Revalidate older records before a large campaign, especially when the list has not been mailed recently.
5. Webhook and bounce processing: Update an address record when actual delivery events provide stronger new evidence than an earlier validation result.

A REST-based validation product may expose a route similar to GET /v4/address/validate for single-address checks, but endpoint paths, request parameters, authentication, and output fields are provider-specific. Do not hard-code an assumed schema from a blog post. Use the provider's current API reference and keep your integration layer isolated so you can update it without changing every signup form or campaign workflow. For implementation guidance on connecting validation and sending workflows, consult the email API reference and setup guides.

For example, Mailgun documents its single-address validation at /v4/address/validate (GET with a query parameter or POST with form data), returning a result of deliverable, undeliverable, do_not_send, catch_all or unknown, a risk level, and an optional did_you_mean typo suggestion. (documentation.mailgun.com) Other providers use different labels for similar ideas, which is why the internal result model above is worth having.

Local syntax checks before the API call

You don't need an API for the cheapest layer. Most languages have a maintained library that checks syntax and normalizes the address; in Python, the email-validator package exposes a validate_email function:

from email_validator import validate_email, EmailNotValidError

def normalize_signup_email(raw: str) -> str | None:
    try:
        # check_deliverability=True also queries DNS to confirm the domain can receive mail.
        info = validate_email(raw.strip(), check_deliverability=True)
        return info.normalized
    except EmailNotValidError as e:
        print(f"Rejected {raw!r}: {e}")
        return None

The library checks syntax and, optionally, whether the domain has MX (or fallback A/AAAA) records; by design it never contacts an SMTP server. (pypi.org) A local check like this filters out malformed input before you spend an API call, and an API adds disposable-domain, role-account and other signals on top.

Keep validation server-side

Do not expose secret API credentials in client-side JavaScript. The browser can perform inexpensive checks such as required-field validation and a basic email input constraint, but the actual API call should generally be made by your backend or a secure server-side function.

Server-side handling also lets you rate-limit requests, deduplicate repeated checks, apply your own policy, log decisions, and avoid revealing too much about whether a specific mailbox exists. That last point matters: a public endpoint that reveals granular mailbox status can be abused to probe addresses.

Store the decision context

Save more than a single Boolean field such as email_valid = true. A useful record includes the normalized address, validation category, reasons or flags, validation timestamp, provider response identifier where available, source of the address, consent status, and actual post-send events.

That history allows better decisions later. For example, an address previously classified as unknown may later receive several transactional messages successfully. A once-deliverable work address may hard-bounce six months later after an employee leaves. Validation is a time-bound observation, not a permanent identity attribute.

Measuring email list quality and validation impact

“Email validation API” is not itself a rate or metric. However, the results it produces should feed measurable list-quality and sending-performance metrics.

Useful calculations

Invalid-address rate measures the share of submitted or imported records that your validation policy classifies as undeliverable:

invalid-address rate = undeliverable addresses ÷ addresses checked × 100

Validation coverage measures whether you are actually checking the addresses that enter a workflow:

validation coverage = addresses validated ÷ new addresses collected × 100

Hard-bounce rate measures permanent delivery failures after a send:

hard-bounce rate = hard bounces ÷ delivered attempts or sent messages × 100

Your sending platform may define the denominator differently, so use one definition consistently and label it clearly in reporting. Most importantly, compare like with like: campaign mail against campaign mail, signup source against signup source, and pre-validation periods against comparable post-validation periods.

Worked numeric example

Assume a team imports 50,000 email addresses for a re-engagement campaign. The email validation API returns 2,000 undeliverable addresses, 1,500 risky addresses, 1,000 unknown addresses, and 45,500 deliverable addresses.

The invalid-address rate is:

2,000 ÷ 50,000 × 100 = 4%

If the team suppresses the 2,000 undeliverable records, it has 48,000 remaining records. It then decides to mail the 45,500 deliverable addresses first and hold the risky and unknown groups for review.

Suppose 45,500 messages are sent and 91 produce hard bounces. The hard-bounce rate for that validated segment is:

91 ÷ 45,500 × 100 = 0.2%

That result does not prove the API caused every avoided bounce, because list source, message type, and recipient-provider mix also matter. But it provides a concrete baseline. The team can compare it with prior sends from the same audience type and investigate whether the held risky and unknown groups are worth mailing later.

Avoid vanity interpretation

A high “valid” percentage is not automatically good news. A list with 99% deliverable addresses can still perform poorly if recipients did not consent or if the content is irrelevant. Likewise, a list with a noticeable risky segment may be usable if those addresses come from recent, confirmed customers and are handled carefully.

The best measurement connects validation results to downstream outcomes: hard bounces, temporary deferrals, complaints, unsubscribes, successful confirmations, conversions, and long-term engagement. That gives you evidence for adjusting policy rather than relying on a universal cutoff.

Common causes of poor address quality

Address problems are created throughout the customer lifecycle. Understanding the source is more useful than simply suppressing the final bad record.

Typing and form-design mistakes

People mistype domains, paste trailing spaces, use a work address they no longer control, or enter a made-up address to access gated content. Forms that provide unclear error messages or make correction difficult can worsen the issue.

Improve the form before relying on a cleanup job. Use clear labels, preserve user input when returning an error, avoid punishing users for legitimate uncommon domains, and ask for confirmation only when it is proportionate to the action being taken.

Email typos: gmial.com, hotmial.com and "did you mean?"

Most email typos are in the domain: gmial.com, gmail.co, hotmial.com, yaho.com, outlok.com. They are worth catching for two reasons. The user never gets their confirmation email and assumes your product is broken, and some typo domains are registered by spam-trap operators, so repeatedly mailing them hurts your reputation. Spamhaus counts typo domains as a trap type, though it says they aren't "pure" spam traps, carry a lot of real mail, and are weighted accordingly. (spamhaus.org)

The standard fix is a "did you mean?" suggestion: compare the domain against a list of common mailbox domains, and if it is one or two characters away from a well-known one, ask "Did you mean ada@gmail.com?" before the form submits. Some validation APIs return this suggestion for you, such as Mailgun's did_you_mean field. Two rules keep it safe:

• Suggest, never auto-correct. gmai.com is almost certainly a typo, but small or regional domains can look like misspellings of big ones. Let the user confirm.
• You can't catch local-part typos. jhon@gmail.com is a perfectly valid address that may belong to someone else. Only a confirmation email proves the user typed their own address.

More form patterns are in email typo prevention for signup forms.

Spam traps and honeypot traps

"Honeypot trap" means two different things in email, and both matter here.

Spam traps (honeypots for senders). These are addresses that exist to catch senders who mail people without permission. Spamhaus lists several types: pristine addresses never given to anyone, seeded addresses planted where scrapers will find them, typo domains, dead addresses and domains reactivated as traps, and live or role addresses (such as postmaster or abuse contacts) whose owners use unsolicited mail for blocking decisions. Spamhaus also says spam traps are never revealed by their owners and that hunting for them treats the symptom, not the problem. (spamhaus.org) So no validation API can reliably flag pristine traps: they are valid, deliverable addresses. What validation can do is remove dead domains and some role addresses, which reduces exposure. The real protection is collecting addresses directly, using confirmed opt-in, and suppressing addresses that have stopped engaging. See spam traps.

Honeypot form fields (traps for bots). On your own signup form, a honeypot is a hidden input that people never see or fill in but simple bots do. If the field has a value, discard the submission before it reaches your validation API or your list. It costs almost nothing, stops the simplest bots, and should sit alongside rate limiting rather than replace it.

Old lists and natural list decay

Email addresses change over time. Employees leave companies, schools deactivate alumni mailboxes, organizations close domains, and consumers abandon accounts. An address that was deliverable when collected may not be deliverable now.

This is why a list should not be treated as permanently clean after one validation pass. Revalidate records based on risk and age, particularly before a major campaign to contacts that have not received or engaged with mail recently.

Third-party or low-intent acquisition

Purchased, scraped, co-registered, or weakly sourced lists frequently contain stale, mistyped, automated, and non-consensual records. Validation may remove some technically bad addresses, but it cannot convert a poorly sourced list into a permissioned audience.

The better fix is to improve acquisition. Collect addresses directly, document consent, make the value exchange clear, use confirmed opt-in where appropriate, and keep source metadata. That creates better deliverability conditions than any cleanup tool can provide after the fact.

Application and integration defects

Sometimes bad data is generated internally. A CRM sync can map the wrong field, append a domain twice, overwrite a confirmed address with an empty string, or import legacy suppressions incorrectly. These failures can create a sudden rise in invalid results even when customer behavior has not changed.

Monitor validation outcomes by source system, form version, partner, country, campaign, and import date. A spike in undeliverable records from one source is often an integration incident that needs engineering attention, not merely a list-cleaning exercise.

How to improve results after validation

Validation works best as part of a closed-loop hygiene process. The immediate action is to prevent known bad addresses from being mailed. The longer-term action is to make sure the same bad data does not repeatedly enter the system.

Build a suppression policy

When an address has strong evidence of permanent failure, add it to a durable suppression list for the relevant sending identity or account. Do not keep retrying it in future campaigns just because it appears in another import.

Suppression handling must be precise. A hard bounce from a non-existent mailbox is different from a temporary mailbox-full condition or a provider deferral. Do not permanently suppress a recipient solely because of a transient failure. Use the response category and your email provider's delivery-event information to distinguish durable failures from retryable ones.

Use confirmation to establish ownership

Address validation assesses technical plausibility. Confirmation establishes that the person accessing the address can receive a message there and take an action. A confirmation email with a time-limited link is especially valuable for account creation, subscription signups, and changes to a customer's primary email address.

This combination is stronger than either method alone. Validation can catch obvious errors before you send the confirmation. Confirmation then provides evidence that the mailbox is accessible to the user who entered it.

Segment risky records instead of flattening them

Do not treat all non-deliverable classifications as identical. Create segments for disposable domains, role accounts, catch-all domains, unknown records, and recently confirmed customers. Then choose rules suited to each segment.

For example, you might permit disposable addresses for a free trial but require confirmation before enabling paid features. You might allow a role inbox for a support contact but exclude it from a person-specific product sequence. You might send catch-all addresses only when they originate from a signed-in customer and not from a cold imported lead list.

Revalidate selectively

Continuous revalidation of every record can be unnecessary and expensive. Prioritize records that are old, never confirmed, imported from a weak source, about to receive high-volume marketing mail, or associated with prior delivery uncertainty.

Consider the cost of being wrong. A single invoice recipient may justify sending despite uncertainty because the message is operationally necessary. A marginal prospect in a large campaign may not justify the same risk. This is a business-policy decision informed by validation data, not a purely technical threshold.

Email list cleaning services vs an email validation API

An email list cleaning service (also sold as list hygiene, list scrubbing or mailing list validation) runs the same kinds of checks as a validation API, but as a batch job over a list you already have: you upload a CSV or connect your CRM, and get back the list split into keep, remove and review. An API checks one address at a time, at the moment it enters your system.

Most teams need both: the API keeps new data clean, and periodic cleaning catches decay in old data. Whichever you use, a cleaning pass should cover more than validation results:

1. Deduplicate after normalizing whitespace and domain case.
2. Apply your own suppressions first: past hard bounces, complaints and unsubscribes. No outside service knows these.
3. Run validation and remove undeliverable results; hold catch-all, unknown and disposable results for a decision.
4. Flag role addresses for B2B lists that should reach people.
5. Segment by last engagement and send a short re-engagement sequence to long-inactive contacts before mailing them normally, or suppress them.

What no cleaning service can do is add consent to a list that never had it, or reliably detect spam traps. For the broader process, see email list hygiene; for why a "valid" result can still bounce, see email verification accuracy and catch-all email verification.

Email validation versus email verification

The terms are often used interchangeably, but they describe different activities.

Email validation evaluates the address itself: formatting, domain configuration, mailbox signals, and risk indicators. It is generally performed by an API or validation service without requiring the mailbox owner to take action.

Email verification usually asks the recipient to prove control of the inbox, such as by opening a confirmation link or entering a code. It establishes a stronger relationship between the entered address and the user who completed the action.

A high-quality signup flow may use both. It validates to catch immediate errors and reduce wasted confirmation mail, then verifies to confirm access and intent. A campaign-import workflow may rely heavily on validation and consent evidence, because sending confirmation messages to every historical contact may not be appropriate.

Do not confuse either process with authentication. SPF, DKIM, and DMARC help receiving providers assess whether a sender is authorized to use a domain. They are important deliverability controls, but they answer a sender-identity question, whereas email validation answers a recipient-address-quality question.

Two more terms get mixed into this:

• Verification codes. The one-time code or link in a sign-up email ("Your verification code is 482913") is how email verification is usually done. Those messages are transactional email and need fast, reliable delivery; examples and security rules are in magic link and OTP emails.
• Domain verification. When an email provider asks you to "verify a domain," it means proving you control your sending domain by publishing DNS records, usually alongside SPF and DKIM setup. That has nothing to do with checking recipient addresses; see how to verify a domain.

Choosing an email validation API

The right service depends on your volume, integration pattern, privacy obligations, geographic requirements, result detail, and workflow needs. Price matters, but a low per-check cost is not useful if the service cannot provide the categories your product needs or if your implementation does not act on the results.

Evaluate an API against practical criteria:

• Single and bulk workflows: Can it support real-time form checks as well as large imports?
• Result transparency: Does it provide clear categories and reasons rather than an unexplained score?
• Unknown handling: Does the response distinguish uncertainty from a definite invalid result?
• Latency and reliability: Is it suitable for synchronous user flows, or should it run asynchronously?
• Security: Does it support secure authentication and avoid requiring API secrets in the browser?
• Data handling: Are retention, processing location, and privacy terms compatible with your obligations?
• Integration fit: Can your team easily connect results to your CRM, signup flow, suppression logic, and sending platform?
• Cost model: Is pricing aligned with single checks, bulk checks, and the volume you expect? Review email sending plans and usage costs alongside the operational cost of bounces and list cleanup.

Run a controlled evaluation with addresses from known outcomes where permitted. Include valid personal addresses, corporate addresses, known hard bounces, role accounts, disposable domains, and catch-all cases. Compare the result categories with actual delivery events over time, but do not create artificial test traffic that could violate provider policies or disturb recipients.

Best practices for developers and senders

An email validation API should improve a user's experience and protect infrastructure without becoming an opaque obstacle. The following practices keep the implementation useful:

• Perform inexpensive format checks locally, but make authoritative API decisions server-side.
• Avoid validating on every character typed; validate on submit or at a deliberate workflow step.
• Explain actionable errors in plain language, such as asking the user to check the spelling of an address.
• Do not reveal detailed mailbox-existence results publicly.
• Treat unknown and catch-all results as policy decisions, not automatic failures.
• Store validation timestamps because address status changes.
• Combine API results with confirmation, consent records, suppressions, and actual bounce events.
• Monitor outcomes by acquisition source to find broken forms, bad imports, or weak partners.
• Never use technical validity as a substitute for permission to send marketing email.
• Revisit thresholds after measuring downstream bounces, engagement, and support impact.

The strongest implementations also maintain an audit trail. When a sales or support team asks why an address was blocked or excluded, you should be able to identify whether the reason was malformed syntax, a failed domain check, a known hard bounce, a disposable-domain policy, missing consent, or an uncertain result that was held for review.

How Volanea handles email validation

Volanea's API includes an email validation endpoint, POST /v1/verify, available on every plan including the free one. It reports four checks: syntax, MX records (whether the domain has servers that receive mail), disposable domain, and role account. It also returns the normalized address and an overall valid verdict:

const res = await fetch("https://api.volanea.com/v1/verify", {
  method: "POST",
  headers: {
    Authorization: "Bearer " + process.env.VOLANEA_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ email: "ada@example.net" }),
});
const result = await res.json();
// { email, valid, checks: { syntax, mx, disposable, roleAccount } }
if (!result.valid) {
  // Ask the user to check the address before creating the account.
}

checks.mx is "unknown" rather than false when the DNS resolver is unavailable, so treat that as the Unknown class above, not as invalid. Use the individual checks for your own policy (for example, allow role accounts on a B2B contact form but not on a personal trial sign-up). None of the four checks confirms that the mailbox itself exists, so keep sending a confirmation email for sign-ups.

Two related pieces: GET /v1/suppressions/check tells you whether an address is already on your project's suppression list, and why, before you send, and the free email verifier runs the same kind of check on a single address in the browser, no signup needed. Request and response details are in the verify API reference.

Conclusion

An email validation API gives sending systems a practical way to evaluate address quality before email is sent. By checking format, domain readiness, mailbox-level signals where available, and risk classifications, it helps reduce preventable bounces and makes customer data more reliable.

Its value comes from how it is used. Treat clear failures as suppressions or correction opportunities, manage catch-all and unknown results with context, confirm ownership when it matters, and use post-send delivery events to improve your rules. Combined with permission-based collection, authentication, relevant content, and careful list management, validation becomes a meaningful part of durable email deliverability.

FAQ

Is an email validation API the same as checking email syntax?

No. Syntax checking only evaluates whether an address is written in a plausible form. An email validation API can also inspect the domain, mail-routing signals, mailbox-level responses when available, and risk factors such as disposable or catch-all behavior.

Can an email validation API guarantee inbox placement?

No. Validation can indicate whether an address is likely reachable, but inbox placement also depends on sender authentication, reputation, recipient engagement, content, complaints, and mailbox-provider policies.

Should I reject catch-all email addresses?

Not automatically. A catch-all result means the domain accepts mail for many or all local parts, making mailbox existence hard to determine. Handle it as a risk category and base your decision on the message type, address source, consent, and potential cost of a bounce.

How often should email addresses be revalidated?

Revalidate based on risk rather than a single universal schedule. Prioritize older records, addresses from unconfirmed or weak sources, inactive contacts, and lists about to receive a large campaign. Always update your records when real bounce events provide new evidence.

Does validation prove that a recipient opted in?

No. Technical deliverability and marketing permission are separate. Keep consent records, honor unsubscribes and suppressions, and send promotional email only to recipients who have an appropriate relationship and permission basis.

How do I catch email typos like gmial.com?

Check the domain against a list of common mailbox domains and suggest a correction, such as "Did you mean ada@gmail.com?", before the form submits. Some validation APIs return a suggestion field for this. Never auto-correct, and remember that typos in the part before the @ can only be caught by a confirmation email.

What is a honeypot trap?

In deliverability, a honeypot or spam trap is an address that exists to catch senders mailing without permission; owners never reveal them, so validation can't reliably detect pristine traps. On signup forms, a honeypot is a hidden field that only bots fill in, used to discard automated sign-ups. Both are reasons to collect addresses directly and use confirmed opt-in.

What is an email list cleaning service?

It is a batch version of email validation: you upload an existing list and get back which addresses to keep, remove or review, usually with duplicates, invalid domains, disposable and role addresses flagged. Apply your own bounce, complaint and unsubscribe suppressions as well, because the cleaning service doesn't know them.

Is there a free email verification API?

Several providers offer free tiers or trial credits. Volanea's POST /v1/verify endpoint is available on every plan, including the free plan with no card, and the free email verifier checks single addresses in the browser without signup.

Is domain verification the same as email validation?

No. Domain verification proves to an email provider that you control your sending domain, by publishing DNS records. Email validation checks the quality of a recipient's address. They solve different problems and you usually need both.