Real-time vs. bulk verification: when to use each

The question comes up often: "do I need real-time or batch verification?" The correct answer is "both, and they do not do the same thing".

Real-time verification and batch verification solve different problems at different moments in the data's lifecycle. Operating only one of them leaves a specific hole through which the base degrades. This text details what each one does, in which scenario to use it, and how to combine them without rework.

The difference, in one sentence

Real-time verification acts on entry. Batch verification acts on stock.

Real-time is the function that runs when the subscriber types their address into a form and clicks "submit". In milliseconds, the API verifies what needs to be verified and returns a response that decides whether that lead enters the base or not.

Batch is the function that walks through an existing list, address by address, and classifies each one as valid, invalid, or inconclusive. It is an asynchronous, time-consuming, scheduled operation.

The two solve different parts of the same problem: keeping the base clean. But the defense real-time offers, batch does not. And the work batch does, real-time cannot do.

Real-time verification, in detail

Real-time is an API call. The form sends the address to an endpoint, gets a classified response, and decides what to do. Typical checks include:

• Syntax (valid RFC format).
• Domain (DNS resolves, MX record exists).
• Mailbox (SMTP server responds that that specific address exists, without sending an actual message).
• Disposable domain (Mailinator, Guerrilla, 10minutemail, dozens of others).
• Accept-all domain (server accepts any address, usually a corporate domain).
• Typo suggestion (gmial.com returns a suggestion of gmail.com).
• Role-based (contact@, sales@, noreply@).

Typical latency on a decent API: 200 to 600 milliseconds. Enough to run before the subscriber clicks "submit" without any perception of slowness.

Where real-time is irreplaceable

• Lead capture form (landing page, popup, blog).
• SaaS product account creation.
• E-commerce checkout (especially where email is the key for cart recovery).
• Loyalty program signup.
• Gated content download.
• New user invitation in a multi-tenant product.

In all of these scenarios, real-time offers three things that batch never will:

Correction suggestion. The subscriber typed gmial.com. Real-time returns "did you mean gmail.com?". The subscriber confirms. Lead recovered. In batch, that lead never existed in the base because they believed the signup worked.

Bot and disposable blocking at the moment. Real-time stops trash from entering. Batch has to clean trash that already entered.

Clean experience. The subscriber does not sign up with an error, get frustrated by missing welcome emails, and abandon with a bad brand impression.

Batch verification, in detail

Batch walks through an entire list and classifies each address. It accepts a file (CSV) or direct connection to a database/ESP, processes in hours or days depending on volume, and returns a result per address.

Batch cannot prevent anything from entering. The address is already in the base. Batch tells you what to do with each one: keep active, suppress, or reengage carefully.

Where batch is irreplaceable

• Initial cleanup of an inherited base (you took over the ESP from another agency or previous agency).
• Pre-campaign for large volume (Black Friday, launch, inactive reactivation).
• Tool migration (new ESP, new CRM, new automation platform).
• Periodic audit of base quality.
• Investigation of a sudden drop in metrics (figuring out whether the drop is from accumulated bad data or from something else).
• Company acquisition (you inherited the marketing base from an acquired company).

In all of these scenarios, batch offers what real-time cannot: retroactive visibility over data that entered before you installed real-time, or at moments when real-time failed.

The division of labor

The way to think about it is to treat real-time as immune system and batch as routine checkup.

The immune system stops the problem from entering. The routine checkup detects problems that slipped past the immune system or developed internally (natural decay).

Operating only the immune system means everything that entered before the immune system existed was never verified. And it means that natural decay (subscribers who changed jobs, abandoned accounts, discontinued domains) is never detected.

Operating only the routine checkup means every bad piece of data enters the base, stays until the next pass, and during that window is consuming quota, burning reputation on any send it receives, and contaminating your metrics.

Suggested cadence by sector

The ideal batch frequency depends on your base's churn profile.

• B2B with long cycle. Quarterly is enough. The base changes slowly.
• B2B with active SDR. Bimonthly. Volume of new contacts is higher, and the chance of a prospect mistyping during a call grows.
• Seasonal e-commerce. Monthly in the weeks before big dates (Black Friday month, Mother's Day), quarterly outside those windows.
• B2C SaaS. Monthly. Volume of new signups and abandonment is high.
• Education and courses. Monthly during enrollment season, quarterly outside it.

Regardless of sector, an extra batch pass is worth running at three moments: 30 days before any send that will break habitual volume; after any detected bot attack on a form; after any platform migration.

The cost of operating poorly

The favorite math of anyone selling a verification tool is "X% of your base is invalid, and you are paying the ESP for X% that returns nothing". The math is correct, but it is the smallest of the three bills.

The second bill is reputational. Every send to an invalid or trap is a vote against your sender reputation. Bad reputation affects delivery to the good subscribers. The cost shows up as a drop in open rate and a drop in revenue, but it has no clear label on the financial spreadsheet.

The third bill is a decision bill. When 20% of the base does not respond because the addresses do not exist, your apparent open rate is lower than the real one. You optimize subject lines, send times, and copy against the wrong denominator. A/B tests lose power. Heatmaps get biased. Product roadmap decisions based on "which segment engages most" start reflecting not preference, but technical address quality.

A well-operated combination of real-time + batch is not a saving. It is the minimum condition for any later optimization to have a solid base.

Concrete implementation, in three steps

Step 1. Install real-time verification on every public form. No exceptions. Landing page, exit intent popup, blog, checkout, product signup. Every form without verification is an entry door for trash.

Step 2. Run a batch verification of the entire base now. Before any campaign optimization. Identify the invalid portion, move it to suppression, and establish the baseline from that clean base.

Step 3. Calibrate batch cadence to your sector (the table above is a starting point) and create a recurring job. Do not depend on someone remembering.

From there, you start operating with data of known quality. Marketing decisions begin to reflect reality, and infrastructure stops being a source of silent risk.

How Email Intelligence helps

Email Intelligence executes this logic continuously inside your ActiveCampaign account. The fields materialize per-subscriber verification status (valid, disposable, role-based, accept-all, risk) and keep the base classified without you having to run manual processes. Combined with AC automations, they become a segmentation rule instead of a cleanup spreadsheet.

We are opening access to the free beta.

I want beta access →