Real-Time Email Verification API
Real-time verification means checking an address synchronously, as part of the request that submits it — a signup form, a checkout flow — rather than in a background batch job. The right mode depends on your latency budget: fast mode (cache-only, no live network calls) for the tightest budgets, standard mode (live DNS) for most signup forms, and full mode (adds a live SMTP handshake) only where the extra few hundred milliseconds to a few seconds is worth the stronger deliverability signal.
Why the mode choice is the real-time question
The API always returns synchronously for a single-address check — there's no async job for /v1/email/check itself. The thing that actually varies with latency is how much real work happens before that response comes back, and that's controlled entirely by the mode parameter.
| Mode | What it does | Typical latency profile |
|---|---|---|
| fast | Reads only cached DNS/domain-age data, never performs a live lookup | Lowest and most consistent — no network round-trip to a third party |
| standard | Live DNS resolution for MX/SPF/DMARC and domain age if not cached | Usually fast, but bounded by DNS resolver response time on a cache miss |
| full | Everything standard does, plus a live SMTP handshake to the mail server | Slowest and least predictable — depends on a third-party mail server's response time, with its own timeout budget and circuit breaker |
Picking a mode for a real-time flow
- Autocomplete or as-you-type feedback on a form field — fast mode, or skip the API call entirely and rely on client-side syntax validation until submission
- Standard signup form submission — standard mode is the usual default; live DNS lookups are cached afterward, so repeat checks of the same domain (common — many users share popular providers) are fast
- High-value action where a bad address is costly (a paid checkout, a critical transactional flow) — full mode is worth the extra latency, since the SMTP-confirmed result is the strongest deliverability signal available
- Bulk import or backlog scoring — not a real-time case at all; use the bulk endpoint instead of looping single checks synchronously
Why caching matters more than it looks like it would
DNS and domain-age results are cached server-side with a TTL, and SMTP results are cached separately by a hash of the address. In practice, a large share of real-world signup traffic clusters on a small number of popular domains (Gmail, Outlook, and similar), so after initial warm-up, most standard-mode checks resolve from cache rather than hitting live DNS at all — the live-lookup cost is mostly paid once per domain, not once per request.
If you do use full mode in a real-time flow
- Set a client-side timeout and a fallback path (e.g. treat a slow response as "proceed with standard-mode confidence" rather than blocking the user indefinitely)
- Expect full mode to occasionally return unknown or blocked rather than a definitive result — a circuit breaker may have paused probing against that specific domain, or the mail server simply didn't respond in time
- Don't run full mode on every keystroke or repeated submission attempt — it's the most expensive mode for both you and the receiving mail server
A typical real-time signup check
const result = await fetch("https://api.emailriskradar.com/v1/email/check", {
method: "POST",
headers: { Authorization: `Bearer ${process.env.EMAIL_RISK_API_KEY}`, "Content-Type": "application/json" },
body: JSON.stringify({ email, mode: "standard", context: "signup" }),
}).then((r) => r.json());
// Standard mode is fast enough to block the signup response on directly -
// no async job, no polling needed for a single address.
if (result.decision === "block") return reject();FAQ
No — /v1/email/check is always synchronous. For genuinely asynchronous processing (large batches), use the bulk endpoint instead.
It varies — full mode adds a live network round-trip to a third-party mail server, which is inherently less predictable than a DNS lookup. Cached SMTP results return quickly; a fresh probe against a slow or unresponsive server is the worst case.
No — match the mode to what the decision actually needs. Most signup forms are well served by standard mode; reserve full mode for genuinely high-value actions.
Both — mode controls how much evidence is gathered, which affects the confidence value attached to the risk score, not just latency. A fast-mode score is the same scale but carries lower confidence than a full-mode score for the same address.