Start free

Where Email Verification Fits in Your Workflow

The same verification call behaves very differently depending on where you put it. These fifteen scenarios are grouped by when verification runs in the workflow, from the signup form to the hour before a campaign goes out.

A mistyped address is cheap to fix in the second before a form submits and expensive to fix at any point afterwards. In that second you can show the person a correction and they will usually take it. An hour later the record is already in your database, the welcome message has already failed, and the best you can do is mark the row dead. A year on it is still being counted as a contact, quietly weighing down the open rates you report and the sending reputation you depend on. The fifteen pages below are arranged around that widening gap, and none of them is a step-by-step tutorial: each covers where a check sits in a real system, the specific failure it prevents, and what should happen to the record once a result comes back.

Timing is the decision that actually shapes the work. Verification at the point of capture runs synchronously, on a single address, with a person waiting on the other side of a form, so it has to answer in a fraction of a second and it has to fail open, because a timeout must never cost you a customer. Verification as maintenance runs across hundreds of thousands of stored records with nobody waiting, so it can be slow, thorough and scheduled, and the enemy it fights is decay rather than typos. Pre-flight verification is narrower still: you check the specific segment you are about to mail, shortly before you mail it, because the list you cleaned six months ago is not the list you are sending to today.

These three moments are not alternatives to each other, and a mature setup runs all of them. Only capture-time checking can fix a typo, because it is the single moment when the person who made the mistake is still on the page and can be asked to correct it. Only scheduled bulk verification catches decay, meaning addresses that were genuinely valid when you collected them and stopped working when someone changed jobs or let a domain lapse. And only a pre-flight pass covers the gap between the two, including the records that arrived through an import, a partner feed or a legacy system and never passed through a form at all.

If you are deciding where to start, start where addresses enter. Adding a check to the form is cheaper than cleaning up what the form let through, which makes signup form validation the highest-leverage first move for most teams. If you have inherited a list of unknown provenance, run a one-time database cleanup first so you know what you are actually holding before you commit to a cadence. One thing worth understanding before you build anything: verification returns more than valid and invalid, and the ambiguous results, such as catch-all domains, role addresses and unknowns, need a different answer at each moment. At capture you can ask the person again; in bulk you cannot, so you suppress or segment instead of deleting.

At the Point of Capture: Accounts and Checkout

These scenarios run verification inside the submit handler, where the address is effectively a credential: it becomes the login, the receipt destination and the account recovery path. A bad address here does not merely bounce later, it produces an account nobody can get back into or an order nobody can be contacted about, so these pages spend most of their time on how strict to be without turning away real people.

At the Point of Capture: Registrations and Opt-Ins

The same moment in the request, with different stakes. Here the address is a promise of a message you will send later, such as a ticket, a set of survey results or a confirmation link, so the person who mistypes it usually never finds out and neither do you until the send fails. These pages cover verifying at collection time precisely because there is no second chance to reach someone whose only contact detail is wrong.

Pre-Flight: The Window Before a Send

Verification done deliberately ahead of one specific campaign or outbound sequence, close enough to the send that the results are still true. Reach for these when you are mailing a list you did not collect yourself, waking up a segment that has been dormant, or protecting a sending reputation you cannot afford to spend on addresses that quietly stopped working months ago.

On a Schedule: Working Against Decay

Recurring maintenance on databases that are constantly being added to and constantly going stale. Nothing triggers this work except the calendar, so these pages focus on cadence, on matching results back to the right records after processing, and on what to do with a contact you are not yet ready to delete.

One-Time Sweeps With a Deadline

Projects with a clear start and end, usually because something else forced the issue. Both scenarios share a useful property: you are already exporting and re-importing the entire dataset, so verification becomes one extra step rather than a project of its own, and you come away with a one-off measurement of how healthy your data really is.

Always-On: Pipelines and Obligations

The two concerns that cut across every timing above. One is mechanical, wiring verification into your own systems so it happens without anyone remembering to run it, and the other is regulatory, since keeping stored personal data accurate is a standing obligation rather than something you do in the week before a campaign.

Whichever moment you decide to start with, the quickest way to understand what a verification result actually contains is to run one address through the free email verifier and read the full response before you design around it.

Run a test address

Use Cases FAQ

Yes, because the two catch different problems and only one of them is recoverable. A quarterly sweep will correctly mark jane@gmial.com as invalid, but by then Jane is long gone and there is no way to ask her what she meant to type. Verification at the point of capture is the only moment when the person who made the mistake is still in front of you, which is why signup form validation recovers subscribers that scheduled cleaning can only delete. Scheduled cleaning still earns its place, because it is the only thing that catches addresses that were valid when you captured them and went bad afterwards.

There is no fixed shelf life, but the useful mental model is that a verification result describes a mailbox at one instant, and mailboxes get abandoned continuously. For a segment you mail often and prune for bounces, an older result stays reliable for a long time; for a dormant segment, or a purchased or scraped list, verify shortly before the send rather than trusting a pass you ran at some earlier point. In practice that means running pre-campaign list cleaning against the exact segment you are about to mail, not against the whole database months ago. Elapsed time since you last successfully reached someone is a better trigger than the calendar.

No. At the point of capture the correct default is to fail open: if the check cannot complete, accept the submission and flag the record for a later pass rather than losing the order or the registration. Reserve hard rejection for definitive results such as malformed syntax, a domain with no mail exchanger, or a known disposable provider, and treat ambiguous results as a prompt rather than a wall by offering a correction the user can accept or dismiss. The pages on checkout validation and preventing fake signups cover where to draw that line on revenue-critical forms versus free account signups.

Verify Your Email List Free

Get 100 daily free verifications. No credit card required.