Email Verification API: How Real-Time Checks Work

An email verification API lets your product ask a verifier about one address at the moment it appears: on a signup form, at checkout, inside a CRM workflow, or in a script that processes new leads. You send the address, you receive a status, and your app decides whether to accept the record, ask the person to correct it, or store it with a flag. That is real-time email verification: the database never has to inherit a typo just because a form accepted any string with an @.

This article explains how those live checks work at a high level, where teams place the call, and what to look for when you pick an API. kukudze has no public API today. On kukudze you check one address or a list on the site, so this guide is general advice for whichever API you choose.

For the product category around the API, see the tool explainer. A later comparison of live checks versus file jobs will help you pick a mode per workflow.

What you are asking the API to do

A live call answers a narrow question: given this string, what do we know about it right now? The verifier typically:

1. Looks at the shape of the address
2. Resolves the domain’s mail routing data
3. Contacts the receiving server when that server will talk
4. Returns a status plus any risk flags it supports

Hunter’s public description of the checks its Email Verifier performs is a useful independent picture of that pipeline. Hunter writes that it talks to the destination mail host without dispatching a message, and that it marks an address as blocked when that host refuses the test.

RFC 5321, the specification for the Simple Mail Transfer Protocol, is the reason this kind of check is possible at all. It describes how a client opens a conversation with a server, names a recipient, and receives a reply that the address was accepted or rejected. A verification API is not an SMTP client you operate yourself. It wraps that kind of conversation (and the DNS lookup that precedes it) so your application only has to handle a status code.

Two cautions follow from that model:

• Some servers refuse mailbox probes or answer so slowly that the result is unknown. Your app should expect that outcome and not treat it as “valid.”
• A “valid” status is a snapshot. The mailbox can disappear later. Live checks reduce bad data at the door; they do not freeze an address in time.

Where a live check belongs

Place the call as close as you can to the moment an address enters your world. Common insertion points:

Signup and account creation

The person is still on the page and can fix a typo. Showing “this address does not look deliverable” is cheaper than sending a confirmation message into a void and losing the user. Google’s sender guidelines already ask you to confirm the mailbox before adding someone to a list. A verification API supports that habit by catching impossible strings before the confirmation message is even queued.

A dedicated form guide will stay on this use case in signup form checks. Whichever API you pick, call it from your server-side form handler, not from code in the browser, so no key ends up in the page.

Checkout and customer accounts

Stores collect mail for receipts and shipping updates. An invalid address here creates support tickets, not only weak marketing metrics. A live check at account creation or guest checkout keeps transactional mail pointed at a mailbox that at least existed when the order was placed.

CRM and automation writes

Sales and success tools often create or update contacts from imports, syncs, and other automated jobs. A verification step before the record is marked “mailable” stops a bad enrichment or a pasted column from poisoning a sequence. Run the check when the address is new or when it changes, not on every harmless field edit.

Internal tools and support consoles

Support agents type addresses by hand. A verify-on-blur action in the admin screen prevents a ticket reply from bouncing because of a transcription error.

Live calls and file uploads do different jobs

A real-time email validation API is the wrong tool for last year’s newsletter export. You would issue tens of thousands of individual requests, wait on each server, and risk timeouts. That workload belongs to a file-based cleaning pass.

Use the API when:

• A human is present and can correct the value
• A workflow needs an answer before it writes to the database
• New addresses arrive one at a time throughout the day

Use a bulk job when:

• You already hold a file
• You are cleaning a CRM before a campaign
• You want a single labeled export to review as a team

Many teams run both: the API guards the front door, and a scheduled bulk job re-checks records that have aged. Some APIs also let you collect the result later when a check cannot finish within a single HTTP request. Ask how the vendor handles slow servers before you build on it.

What the response usually contains

Field names differ by vendor, so read the docs of the API you choose rather than inventing JSON. Most responses carry fields like these:

• The address you submitted, echoed back so you can match it
• A primary status (valid, invalid, unknown, and similar)
• Zero or more flags (disposable, role-based, accept-all, and similar)
• A suggestion when the domain is close to a typical typo, if the vendor offers one

Your application logic should be explicit:

• Reject or ask for a correction on invalid syntax and on mailboxes the server denied
• Warn or block by policy on disposable inboxes if your product cannot tolerate throwaway users
• Allow with a review flag on unknown and accept-all, unless the campaign type forbids them
• Log the raw status so you can audit why a record was accepted six months later

Do not hide unknown behind a green checkmark. That teaches the rest of the stack to trust a guess.

What to look for in an email verification API

Read the vendor’s docs before you write code. A good API makes these points easy to find:

• Public docs. Endpoints, sample requests, and sample responses, written down where you can read them before you sign up.
• Key handling. Keys you can create, rotate, and revoke per app, so one leaked key does not force you to change every integration.
• Clear limits. A stated number of requests per second or per month, and a clear error when you go over.
• Honest statuses. Unknown stays unknown. The response should say when a server refused to answer.
• Slow-server handling. A timeout you can set, or a way to fetch the result later, so a slow mail server does not freeze your form.
• Data handling. A plain statement of whether the addresses you send are stored, and for how long.

If a vendor cannot show you these points in writing, do not hard-code guessed paths or keys. Treat the API as unfinished and keep your own fallback ready.

kukudze has no public API today. There are no API keys, endpoints, or integrations to connect. On kukudze you sign up for a free account, confirm your email, and check one address or a list on the site, then download the results as a CSV. Every plan on the pricing page runs the same format, domain, mailbox, and accept-all checks. If your workflow needs checks inside your own app, use an API from a vendor that documents the points above.

A practical rollout sequence

You can ship a safe integration without waiting for every feature:

1. Pick the events. Start with account signup or the first time a contact’s email is written. Add checkout or CRM sync later.
2. Call from the server. Keep any secret material off the browser page. The form can post to your backend; your backend talks to the verifier.
3. Decide the hard rules. Invalid is usually a hard stop. Disposable may be a hard stop for a consumer app and a warning for a B2B form. Write those rules down.
4. Fail open or closed on errors. If the verifier is unreachable, choose a documented fallback: queue the address for a later check (fail open, with a flag) or ask the user to try again (fail closed). Silent acceptance with no flag is the option that recreates the original problem.
5. Store the status and the time of the check. You will want both when you debug a bounce.
6. Add a bulk backfill. Addresses collected before the API existed still need a file pass.
7. Review the first week of flags. Look at how often you see unknown and disposable results. Adjust copy on the form so people understand a rejected typo.

That sequence is enough to verify email via API without inventing a client library. Where the vendor offers official examples, use them in place of your own glue code.

Keep a short internal runbook next to the integration: which events call the API, which statuses block a write, who owns the fallback when the verifier is unreachable, and how long cached statuses may be reused. That document will save you from rediscovering those decisions after a form change or a new teammate ships a second integration.

One more design choice is how you spend your request allowance. A form that retries the same address on every keystroke can burn through a monthly cap without producing new information. Cache the last status for a short period (a few minutes is usually enough while someone corrects a typo) and only send a fresh request after the value changes or that cache expires. Log failures from your side separately from “invalid” results returned by the verifier, so a timeout in your network is not stored as proof that the mailbox does not exist.

If several applications share one verifier account, give each app its own key when the vendor allows it, and its own identifier in your logs. That way a noisy integration can be spotted without pausing every other form. Follow the authentication method the vendor’s docs describe rather than a convention you made up.

FAQ

Is a regular-expression check on the form enough?

No. A pattern can reject strings that are missing an @, and that is worth doing as a first client-side hint. It cannot see whether the domain has mail servers or whether the mailbox exists. RFC 5321 is about transporting mail, not about a local pattern match.

Does a live check deliver mail to the person?

Reputable verifiers describe the mailbox step as a conversation with the server that stops short of delivering mail. Hunter’s help page states this directly for its own product. kukudze works the same way: the mail server is asked if it accepts the address, and no email is sent. Never substitute a live campaign for a verifier just to harvest bounce notices.

What happens if the check is too slow for my form?

Set a timeout that feels acceptable to a person filling the form, show a clear waiting state, and fall back to your documented error policy. For jobs that can finish later, put the address in a queue and check it in the background rather than blocking a page for a long time.

Can I use the API to check a purchased list?

You can submit any address you already hold. You should not mail a list you purchased. Google’s sender guidelines warn against purchasing contact lists, and a clean technical status does not create permission.

Does kukudze have an email verification API?

No. kukudze has no public API today. You check one address or a list on the site after you sign up for a free account. The Free plan gives 100 checks a month and lists up to 50 rows, and every plan runs the same format, domain, mailbox, and accept-all checks. For checks inside your own app, pick a vendor that documents its API.

Wrapping up

A real-time email verification API moves the quality check to the moment an address is born in your system. The application sends one value and receives a status; your rules then decide whether that value is allowed to become a contact, a subscriber, or an order receipt recipient. Pair those live calls with periodic bulk cleaning, and new junk stops arriving while old junk gets a scheduled review.

To check an address or clean a list on the site today, use the kukudze product page and see the plans on the pricing page. For page-level guidance, continue with signup form checks.