Email Verification API: Real-Time SMTP Validation for Developers [2026]

An email verification API is the endpoint your application calls to confirm an address can receive mail before you write it to a database or send to it. EmailShield has verified 8.19M+ email addresses across 2.09M+ domains using 37.1M+ live SMTP handshakes on self-hosted infrastructure, and the aggregate is blunt: 22.3% of addresses on a typical B2B list are definitively invalid. Based on Q3 2026 EmailShield platform data. That is more than one in five contacts that will bounce, burn sender reputation, and skew every downstream metric if they reach a send.

This guide is for developers who have to run that check inside a product: on a signup form in real time, inside a CRM as leads arrive, and as a nightly bulk cleanup. It covers how a verification API produces a verdict end to end, the exact SMTP mechanics, the single real-time endpoint (sub-2-second) versus webhook-driven bulk jobs, the 10-category verdict taxonomy, and the developer surface: SDKs, OpenAPI 3.0, signed webhooks, idempotent retries, and deterministic cached results. Every performance and list-quality number here comes from EmailShield's own platform, so it reflects what verification looks like at scale rather than a vendor datasheet.

What an email verification API actually confirms

An email verification API confirms three independent facts about an address: that it is syntactically legal under RFC 5321 and RFC 5322, that its domain publishes working MX records, and that the specific mailbox exists on the mail server behind those records. The first two checks are cheap and deterministic. The third requires opening a live conversation with a stranger's mail server, and that is where verification quality is won or lost.

The reason this matters is decay. Corporate email decays roughly 11x faster than personal email: EmailShield platform data shows a 23.0% invalid rate on corporate addresses versus 2.1% on freemail. Based on Q3 2026 EmailShield platform data. People change jobs, companies rename, and domains lapse, so a B2B list rots at 2-3% per month while a consumer list barely moves. A verification API is the mechanism that catches that rot before a campaign, a transactional send, or a signup confirmation trips a mailbox provider's bounce threshold.

A verification verdict is richer than a boolean. EmailShield returns a primary label, a set of tags, human-readable reasons, and a confidence score between 0 and 1 for every address. An explicit "user unknown" rejection carries 0.97 confidence; a mailbox confirmed by two independent probes carries 0.95; a greylisted server that refused a definitive answer carries 0.4. Consuming the confidence score lets your application decide whether to block a signup outright or route a borderline address to a soft warning.

One anonymized case makes the stakes concrete. An outbound team brought a list a legacy verifier had marked 100% valid. The campaign bounced 7%, enough to cross Google's 2% bounce threshold and damage the sending domain. Re-verification through EmailShield reclassified a large slice of that list as catch-all and as Microsoft 365 addresses that SMTP alone could not confirm. The lesson for anyone wiring up an API: an SMTP 250 reply is a server accepting a connection, and treating it as proof of a deliverable mailbox is the single most common false-valid in the industry.

How the verification pipeline produces a verdict

EmailShield runs every address through a layered pipeline where cheap filters run first, so expensive SMTP capacity is spent only on addresses that survive. Based on Q3 2026 EmailShield platform data, the basic validation layer alone benchmarks at 250,000+ emails per second, while the full SMTP-grade path is deliberately paced to respect the mail servers it probes. The order of operations is the product.

Two stages carry most of the accuracy advantage. Catch-all detection happens at the domain level before any individual address is probed: the MX receives up to 5 addresses built from real first names plus random suffixes, engineered to look like genuine typos so the server cannot fingerprint the probe. If the server accepts those fakes, every address on the domain is classified catch-all. The Microsoft 365 API path bypasses Microsoft's SMTP frontends entirely and validates mailbox existence against Microsoft's account-discovery API, because those frontends routinely accept RCPT for dead mailboxes. For a deeper walk through why domain probing beats a DNS lookup, see EmailShield's breakdown of how email verifiers work, SMTP versus DNS.

The write-once-final rule matters for developers specifically. A verdict is only committed after the full retry chain resolves, so your application never sees an "unknown" silently flip to "valid" an hour later. Intermediate attempts go to a separate audit log, which now holds 37.1M+ rows.

The SMTP handshake, step by step

The core of real SMTP verification is a conversation your API opens with the recipient's mail server and then abandons before any message body is transmitted. EmailShield has performed 37.1M+ of these handshakes, averaging 4.5 probe attempts per final verdict, with each retry originating from a different egress IP on a self-hosted rotating proxy fleet. Based on Q3 2026 EmailShield platform data. No third-party verification API sees your data at any point in this path.

The exchange looks like this. The verifier connects to the MX on port 25, greets the server, declares a sender, and asks whether the recipient will be accepted. It reads the response code and disconnects.

220 mx.example.com ESMTP ready
EHLO verify.emailshield.co
250-mx.example.com Hello verify.emailshield.co
250-SIZE 157286400
250-STARTTLS
250 SMTPUTF8
MAIL FROM:<probe@verify.emailshield.co>
250 2.1.0 Sender OK
RCPT TO:<jordan.avery@example.com>
250 2.1.5 Recipient OK
QUIT
221 2.0.0 Closing connection

The transaction stops at QUIT. DATA is never issued, so no email is ever sent, and the recipient sees nothing in their inbox. A 250 at RCPT TO suggests the mailbox exists, a 550 5.1.1 User unknown proves it does not, and a 450 or a timeout signals a temporary state that has to be retried rather than trusted.

The failure modes are what separate a durable verifier from a fragile one. Microsoft 365 frontends often return 250 for mailboxes that do not exist, which is why EmailShield routes those domains to its API path instead of trusting the SMTP answer. Security gateways answer for the real server at the perimeter, so a 250 from a Proofpoint or Mimecast host proves only that the gateway is listening. A tarpit drips the banner slowly to waste a prober's time, so EmailShield caps confidence on slow-banner servers so a suspicious acceptance is never oversold. Handshake discipline is defined by RFC 5321, and every one of these edge cases is a place where a naive implementation reports a false "valid."

Real-time verification: one endpoint, one verdict, under 2 seconds

Real-time verification is a single synchronous call you place at the moment an address enters your system. EmailShield returns a single-email verdict in under 2 seconds through one verification endpoint, which is the latency budget a signup form or a checkout flow can absorb without the user noticing. Based on Q3 2026 EmailShield platform data. The most common integration is a server-side call fired on form blur or on submit, gating the write to your users table.

The request is a single POST. The response is a structured verdict your code can branch on.

POST /v1/verify HTTP/1.1
Host: api.emailshield.co
Authorization: Bearer sk_live_9f2a...
Content-Type: application/json

{
  "email": "jordan.avery@example.com"
}

{
  "email": "jordan.avery@example.com",
  "verdict": "valid",
  "tags": ["smtp_confirmed"],
  "confidence": 0.95,
  "provider": "google_workspace",
  "is_catch_all": false,
  "is_role": false,
  "is_disposable": false,
  "mx_host": "aspmx.l.google.com",
  "reason": "Mailbox confirmed by two independent SMTP probes.",
  "credits_charged": 1,
  "verified_at": "2026-07-14T09:41:07Z"
}

Read verdict and confidence first. A valid verdict at 0.95 confidence is safe to accept; a catch_all or unknown verdict is a signal to warn the user or hold the address for a bulk recheck rather than a hard block. The provider field tells you whether the address sits on Google Workspace, Microsoft 365, a security gateway, or self-hosted infrastructure, which is useful telemetry for understanding your own signups.

Results are deterministic and cached for 48 hours keyed by email and MX host. Call the endpoint twice for the same address inside two days and you get byte-identical answers with no second charge, because durable verdicts are cached while transient states like unknown are deliberately never cached. That property removes a whole class of "why did this address change" support tickets and makes verification idempotent from your application's point of view. One credit covers one email, and syntactically invalid emails and duplicates are free.

Bulk verification: submit, get a job ID, receive a webhook

Bulk verification is asynchronous by design because a single job can carry up to 2,000,000 emails, and no honest verifier can promise a synchronous answer for a list that size. EmailShield processes bulk jobs at up to 100,000 emails per minute of fleet capacity, and its largest single job to date cleaned 342,301 emails in one upload. Based on Q3 2026 EmailShield platform data. You submit the list, receive a job ID, and go do other work.

The pattern that separates a good bulk API from a frustrating one is notification. Polling a status endpoint every few seconds wastes requests and adds latency to your pipeline. EmailShield pushes a signed webhook to your server the moment a job reaches a terminal state, so your worker sleeps until there is something to do.

{
  "event": "job.completed",
  "job_id": "job_7Qd3aE2m",
  "status": "completed",
  "submitted": 342301,
  "processed": 342301,
  "summary": {
    "valid": 182447,
    "accepted": 21690,
    "catch_all": 28753,
    "invalid": 76333,
    "unknown": 28841,
    "role": 1544,
    "disposable": 903,
    "spam_trap": 412,
    "disabled": 1198,
    "inbox_full": 180
  },
  "results_url": "https://api.emailshield.co/v1/jobs/job_7Qd3aE2m/results",
  "credits_charged": 265968,
  "signature": "t=1752486000,v1=6b8f...",
  "completed_at": "2026-07-14T11:12:44Z"
}

Verify the signature header against your webhook secret before trusting the payload, then treat delivery as idempotent by job_id, because EmailShield retries webhook delivery until your endpoint returns a 2xx and you should expect a duplicate rather than assume exactly-once. Notice the credits charged: 265,968 against 342,301 submitted, because invalid and duplicate rows never cost a credit. Every terminal state is guaranteed by a fail-safe wrapper, and recovery sweeps run every 5 minutes, so a job can never strand in "processing" forever.

An anonymized enterprise case shows the economics. That 342,301-email list resolved to roughly a fifth invalid, in line with the platform-wide 22.3% invalid rate. Sent as-is, that share of dead addresses would have pushed bounce rate past 7% and put the sending domain at risk. Removed before the send, the campaign was simply smaller and cheaper, and the sending domain stayed clean. If your team measures the downstream effect, EmailShield's guide to what a healthy email bounce rate looks like maps invalid share to the thresholds mailbox providers actually enforce.

The verdict taxonomy: 10 categories your code should branch on

A verification API is only as useful as the granularity of its verdicts. EmailShield returns a 10-category taxonomy where tag-based categories take priority over the primary label, because the tags carry the most actionable signal for routing an address. Based on Q3 2026 EmailShield platform data. Collapsing this into a boolean throws away exactly the information that keeps a sender out of trouble.

The valid and accepted split exists for honesty. Both mean the mailbox is deliverable, and the difference is provenance: valid was confirmed by an SMTP handshake, while accepted was confirmed through a provider policy path such as the Microsoft 365 account API. EmailShield discloses how each address was confirmed rather than laundering an API result into an SMTP-looking one.

The unknown category is the one most competitors hide. When a server greylists, tarpits, or filters every probe across a full retry chain, the honest answer is that existence could not be proven, and EmailShield issues unknown with a low confidence score rather than guessing valid. Unknown and protected addresses make up 15.6% of a typical B2B list, so a verifier that quietly folds them into "valid" is inflating its own accuracy at the cost of your bounce rate.

Why Microsoft 365 and catch-all domains break naive verifiers

The two hardest verification problems are Microsoft-hosted mailboxes and catch-all domains, and both require infrastructure a DNS-lookup tool does not have. Microsoft 365 hosts 35.9% of B2B mailboxes yet only 51.4% of them verify as valid, versus 90.6% on Google Workspace. Based on Q3 2026 EmailShield platform data. That gap is not a difference in list quality; it is Microsoft's SMTP frontends returning ambiguous answers.

The provider landscape explains where verification accuracy actually comes from.

EmailShield resolves 23.5% of all verdicts through its Microsoft 365 API-level path, which is the single biggest accuracy differentiator on M365-heavy lists. An anonymized SaaS team targeting IT decision-makers, an ICP that skews heavily Microsoft-hosted, watched legacy tools return large blocks of "unknown" and false-valid results on their prospect lists. Routing those domains through the API path resolved mailbox existence where SMTP could not, which turned an unusable segment into a sendable one.

Catch-all domains are the other trap. A catch-all domain accepts every address at the SMTP layer regardless of whether the mailbox exists, so a verifier that reads that 250 as proof reports garbage as valid. EmailShield has fingerprinted 160,845 catch-all domains, which is 7.7% of all business domains it has analyzed, and 30.1% of addresses behind security gateways resolve to catch-all. Classifying these correctly requires the domain-level probe described earlier, and EmailShield's dedicated explainer on catch-all email verification covers how to segment and send to them safely rather than deleting them wholesale.

The developer surface: SDKs, OpenAPI, webhooks, and a narrow API

A verification API lives or dies on its developer experience, and the design goal is a surface small enough to learn in an afternoon. EmailShield exposes one verification endpoint, publishes an OpenAPI 3.0 specification, and ships SDKs for Python, Node.js, and PHP so you can generate a typed client instead of hand-rolling HTTP. Based on Q3 2026 EmailShield platform data. The public surface is deliberately narrow.

The surface stops there on purpose. API keys cannot reach account-admin functions, so a leaked key can verify emails and check a balance but cannot change billing, delete data, or touch dashboard internals. That separation limits the blast radius of a compromised secret to verification usage.

Three behaviors make the API safe to build on. Webhooks are signed, so your endpoint can reject any payload that does not match your secret. Retries are idempotent, keyed by job ID, so a redelivered webhook or a repeated bulk submission never double-charges or double-writes. Results are deterministic for 48 hours, so a retried single verification returns the same verdict without a fresh charge. Together these mean your integration can assume at-least-once delivery and still stay correct, which is the property distributed systems actually need.

Data handling is worth stating plainly for anyone reviewing a vendor. Uploaded lists are processed entirely on EmailShield-owned infrastructure with zero third-party verification calls, and results are never resold or used to build shared suppression lists. EmailShield is GDPR compliant with DPAs available on request, audit logs, an EU data-residency option, and SOC 2-aligned controls. Verification egress runs from a self-hosted rotating proxy fleet where each IP is capped at 80 SMTP probes per minute and new IPs go through a 10-day warmup, the same hygiene discipline a sender applies to a new inbox.

Pricing and credits for an API-first workload

Verification pricing should be predictable per email so you can model cost against signup volume or list size directly. EmailShield charges one credit per email, makes syntactically invalid emails and duplicates free, and starts every account with 40,000 free credits and no card required. Based on Q3 2026 EmailShield pricing. Per-email cost falls from $0.0019 on the entry plan to $0.00018 at the top tier.

Two credit pools exist by design. Subscription credits renew monthly and drain first; purchased top-up credits never expire and keep working even if a subscription lapses. For an API-first workload with spiky volume, that means you can hold a lifetime buffer of top-up credits against traffic surges without paying for a plan tier you only need occasionally. The free-invalid rule compounds the saving: on a list running the platform-average 22.3% invalid, roughly a fifth of the rows cost nothing to verify.

FAQ

What is an email verification API?

An email verification API is an HTTP endpoint your application calls to confirm whether an email address can receive mail before you send to it. It runs syntax parsing, MX resolution, disposable and role detection, catch-all classification, and a live SMTP handshake, then returns a structured JSON verdict with a confidence score. EmailShield returns a single verdict in under 2 seconds and processes bulk jobs up to 100,000 emails per minute across a self-hosted SMTP fleet. Based on Q3 2026 EmailShield platform data.

How does an email verification API work?

The API layers cheap checks before expensive ones. It validates syntax against RFC 5321 and RFC 5322, checks disposable and role-account databases, resolves MX records, classifies the domain as catch-all or gateway-protected, then opens a live SMTP conversation (EHLO, MAIL FROM, RCPT TO) and disconnects before DATA so no message is ever sent. EmailShield performs an average of 4.5 SMTP probes per verdict, each retry from a different egress IP. Based on Q3 2026 EmailShield platform data.

How accurate is SMTP email verification?

SMTP verification is only as accurate as the mail server it probes. Google Workspace addresses return clean answers at 90.6% valid and 0.2% catch-all, while Microsoft 365 addresses verify at just 51.4% valid because Microsoft SMTP frontends accept mail for dead mailboxes. EmailShield states 99.8% verified accuracy and resolves 23.5% of all verdicts through a Microsoft 365 API-level path that bypasses those unreliable SMTP frontends. Based on Q3 2026 EmailShield platform data.

Can an email verification API detect catch-all addresses?

Yes, but only if it probes at the domain level. EmailShield sends up to 5 plausible fake addresses to a domain's MX; if the server accepts them, every address on that domain is classified catch-all rather than reported as valid. EmailShield has fingerprinted 160,845 catch-all domains, which is 7.7% of the 2.09M domains it has analyzed, and 30.1% of security-gateway addresses resolve to catch-all. Based on Q3 2026 EmailShield platform data.

What is the difference between real-time and bulk email verification?

Real-time verification validates one address synchronously during a signup or form submission and returns a verdict in under 2 seconds. Bulk verification processes lists up to 2,000,000 emails per job asynchronously, returns a job ID immediately, and notifies your server through a signed webhook when the job finishes, so you never poll. EmailShield uses the same verification pipeline for both modes. Based on Q3 2026 EmailShield platform data.

How much does an email verification API cost?

EmailShield pricing starts at $19 for 10,000 credits on the Starter plan and drops to $0.00018 per email at Scale Max ($1,797 for 10,000,000 credits). One credit covers one email, and syntactically invalid emails and duplicates are free. Every account starts with 40,000 free credits, no card required. Based on Q3 2026 EmailShield pricing.

Methodology

All platform metrics in this article come from EmailShield production data covering 8.19M+ verified email addresses across 2.09M+ unique domains, produced by 37.1M+ live SMTP handshakes at an average of 4.5 probe attempts per final verdict. List-composition figures (22.3% invalid, 8.4% catch-all, 15.6% unknown), provider valid rates (Microsoft 365 at 51.4%, Google Workspace at 90.6%), and the 160,845 fingerprinted catch-all domains are aggregate, anonymized measurements across all lists processed on the platform during Q3 2026. Performance figures (sub-2-second single verification, up to 100,000 emails per minute bulk, 712,590 verifications in a peak day, 342,301 emails in the largest single job) are measured production values. Pricing reflects published EmailShield plans as of July 2026. The 99.8% accuracy figure is EmailShield's stated accuracy claim rather than an independently audited benchmark. Aggregate list-composition numbers vary by list source, industry, and age; a Google-heavy list verifies far cleaner than a Microsoft-heavy one. External protocol references are RFC 5321, RFC 5322, and the OpenAPI 3.0 specification. Last updated: July 2026.

Written by Pavel Stoletov, CTO at EmailShield. Pavel leads EmailShield's email verification and deliverability engineering, from the self-hosted SMTP proxy fleet and Microsoft 365 API verification path to the OpenAPI-defined developer platform. Author page - LinkedIn