Skip to content

Real-time vs bulk email verification: which one you need

· 4 min read · Email validation

Real-time email verification checks a single address the moment someone enters it, in a signup form, checkout or CRM workflow, so you can fix or reject it before it's saved. Bulk verification checks a whole list at once, usually before a campaign or after an import. Use real-time to keep bad addresses out, and bulk to clean the ones already in. Most teams that send email need both.

The checks underneath are the same: syntax, domain and MX records, disposable-domain lists, and an SMTP conversation with the recipient's server. What differs is who is waiting and what you do with the answer.

The difference at a glance

Real-time Bulk
Input One address A CSV or list, hundreds to millions of rows
Trigger Form field, signup handler, CRM record created Before a campaign, after an import, on a schedule
Who waits A person, for a second or two Nobody, or an ops person for minutes to hours
What you can fix Typos, while the user is still there Nothing at the source; you can only remove or flag
Handling unknown Allow and re-check later Re-run after a delay
Typical integration API call from your backend File upload or a loop over a batch API

Real-time: prevention

The big advantage of real-time verification is that the person who typed the address is still there. A typo like jane@gmial.com can be fixed with one click, and no list cleaning later can recover it, because by then you don't know what the right address was.

Real-time also stops disposable and non-existent addresses before they create an account, a trial or a lead record. That keeps your CRM and product analytics clean, not just your mailing list.

The constraint is latency. An SMTP check depends on a remote mail server, and greylisting servers deliberately refuse the first attempt from an unfamiliar sender (RFC 6647 describes the technique and suggests accepting retries from one minute to 24 hours later). A form can't wait that long. So real-time integrations need a timeout of a few seconds, a decision rule for unknown (let the user through), and a background re-check. We cover the UX side in verifying email at signup without friction.

Bulk: cleanup

Lists rot. People change jobs, companies change domains, and imported data arrives with problems you didn't create. Bulk verification is how you find out before your sending reputation does. See B2B email list decay for why this happens even to lists that were clean.

Bulk jobs are patient. They can retry greylisted addresses after the server's delay, spread load across many recipient domains, and produce a report you can review before mailing anyone. The output is a decision per row: keep, remove, or hold for a cautious send. That suits list imports, quarterly CRM re-checks and the step right before a cold sequence (cleaning a lead list before sequencing walks through it).

What bulk can't do is ask anyone a question. A typo found in bulk is just a dead row.

Why you need both

Real-time alone leaves you with every address collected before you turned it on, plus every address that decayed since. Bulk alone means typos and throwaway addresses keep entering your systems between cleanups, and you pay to remove the same kinds of problems over and over.

A setup that covers both:

  1. Real-time check on every form that collects an email (signup, demo request, newsletter).
  2. A CRM workflow that verifies records created by other routes (imports, integrations, manual entry).
  3. Bulk verification before sending to any segment you haven't mailed in a few months.
  4. Bounce suppression on every sending tool, because no verifier is perfect.

How pingutil handles each

One API covers both modes, with the same statuses everywhere:

  • Real-time: POST /v1/verify with {"email": "..."} returns status (valid, invalid, risky, unknown), reason, a 0-100 score, did_you_mean for provider typos, and a checks object.
  • Bulk via API: POST /v1/verify/batch with {"emails": [...]} takes up to 50 addresses per request and returns results in the same order.
  • Bulk without code: the dashboard accepts CSV uploads of 50 rows at a time and adds the result columns to your file.

The limits are 60 requests a minute and 300 verifications a day per account, shared across all three, so pingutil fits real-time checks and small-to-medium list cleaning rather than a multi-million-row backlog. No message is ever sent: the SMTP check stops after RCPT TO and disconnects. Catch-all domains return risky / accept_all and greylisting returns unknown, in both modes, rather than a guess.

The verify API reference has the request and response details, and the email verification page lets you try both kinds of answer. If you're weighing providers for high-volume bulk work, the comparison of verification providers is a good place to start.

Questions people ask

Is real-time email verification slower than bulk?
Per address, the work is the same: DNS lookups and an SMTP conversation with the recipient's server. Real-time feels slower because a person is waiting on it, so it needs a short timeout and a fallback. Bulk jobs can wait minutes for greylisting servers and retry.
Can I use a real-time API to clean a list?
Yes, if you respect its rate limits. Loop over the list, call a batch endpoint where one exists, back off on 429 responses, and spread large lists across the daily quota.