---
title: "Real-Time vs. Bulk Email Verification: When to Use Each | Emvero"
description: "Compare verification at signup with checking an existing list. See how waiting, pending results and uncertainty change your workflow with the same API."
url: https://emvero.io/compare/real-time-vs-bulk/
language: en
updated: 2026-10-08
---

Compared

# Real-time vs. bulk email verification

Check a new address while someone fills in a form, or check stored addresses in your own job. Both use the same API; the difference is the time available and the decision you need to make.

| What you want to know | Real-time verification | Bulk verification |
| --- | --- | --- |
| When you check | During signup, checkout or lead capture | When processing addresses already in a list or database |
| Who waits for the result | A person at your form | Your job or operator, rather than a person filling in a form |
| If the result is pending | Poll within a form deadline, then use your fallback policy | Queue retrieval by identifier and handle it within the job deadline |
| Evidence and results | Four final statuses, with action, checks and reason codes | The same fields; evidence depends on depth and observation time |
| How Emvero is called | One server-side request for the submitted address | One request per address in a loop you run |
| Handling unknown | Keep signup possible behind confirmation where appropriate | Keep unresolved rows separate for review or later checking |

## Choose the moment that fits the decision

Use [real-time verification](https://emvero.io/real-time-email-verification/) when a person can still correct an address at signup, checkout or lead capture. The form needs a bounded wait and a clear next step. A clear format or mail-routing failure can prompt a correction; uncertain evidence should not become a false error.

Use [bulk verification](https://emvero.io/bulk-email-verification/) when addresses are already stored. Your script or application reads each row, calls the API and records the returned fields beside it. Emvero receives one address per request. You manage the input and output; there is no hosted CSV uploader or separate batch endpoint.

## A longer wait does not guarantee a clear answer

Either workflow can receive `pending`. Wait for `retry_after_ms`, then retrieve `GET /v1/verifications/{id}` with the same credential. There are no callbacks. A form sets its own wait deadline; a background job can queue the identifier and retrieve it later.

Background work still needs pacing, retry limits and a deadline. A receiving server may continue to hide recipient information, so even a completed check can be `unknown`. Keep service errors, pending work and final address results separate. The [API page](https://emvero.io/email-verification-api/) explains that contract.

## Choose the verification depth separately

Both workflows offer the same `full` and `domain` depths from the same credit balance. A full check can gather recipient-level evidence; a domain check stops before an SMTP probe and cannot establish an individual mailbox. The [full versus domain comparison](https://emvero.io/compare/full-check-vs-domain-check/) covers this choice.

The returned vocabulary stays the same, but the available evidence can change with depth, time and destination behaviour. Neither workflow guarantees delivery. Read the action and reason codes instead of treating a status as one fixed instruction.

## Use both when the address has a longer life

A check during collection can catch an error while it is easy to fix. A later check can identify changes in a mailbox or domain before you rely on stored contact data. Neither check establishes marketing permission or recipient engagement.

The [signup-form guide](https://emvero.io/guides/signup-form-validation/) explains confirmation and corrections for someone registering now. The [list-cleaning guide](https://emvero.io/guides/cleaning-an-email-list/) explains how to keep unresolved rows separate and review an existing list. Those policies can differ even when the API status is the same.

## Where this shows up in a result

Reason codes from the closed vocabulary in the API response. These are the exact strings an integration writes an `if` against.

|  |  |
| --- | --- |
| `SMTP_GREYLISTED` | Temporary SMTP deferral; a later check may help but does not guarantee a conclusive result. |
| `SMTP_CONNECT_TIMEOUT` | Mail server did not answer in time |

## Related terms

### Greylisting

A receiving-server policy that temporarily defers an unfamiliar SMTP attempt; a later attempt may pass.

### Catch-all domain

A domain that accepts arbitrary recipient names, so an accepted address may have no individual mailbox.

[All comparisons](https://emvero.io/compare/)

## Read a verification result.

See an example of status, recommended action and check evidence. Sign in to check your own address.

See an example check

Start for free