What is email verification?

The layers of an email verification check

Verification isn't one test; it's a stack of them, ordered from cheapest to most revealing. Each layer can rule an address out, and only addresses that survive all of them earn a clean verdict. Understanding the layers tells you what a verdict actually proves — and what it can't.

The ordering is deliberate. Cheap, local checks run first because they catch the obvious failures without touching the network: a malformed address or a domain with no mail records is rejected before any server is contacted. The expensive, network-dependent checks run last, only on the addresses that have survived everything cheaper. This isn't just efficient — it means a clean verdict represents an address that passed every gate, not one that skipped the hard ones.

• Syntax check — confirms the address is well-formed (a local part, an @, a domain). Catches typos and malformed entries before any network call.
• Domain and MX check — confirms the domain resolves and publishes mail-exchange (MX) records, meaning it is set up to receive email at all. No MX, no mailbox.
• Disposable and role detection — flags throwaway domains and shared role addresses (info@, sales@) that behave differently from a person's mailbox.
• SMTP mailbox probe — opens a controlled conversation with the receiving server and asks whether the specific mailbox would accept mail, without delivering anything.
• Catch-all detection — recognises when a server accepts every address, so the result is reported as catch-all rather than a false valid.

Why a good verifier returns a verdict, not a yes/no

Mail servers don't answer in binary, so neither should a verifier. A single deliverability flag forces every uncertain case into either "valid" or "invalid," and both choices are wrong often enough to hurt. Call catch-alls valid and you ship bounces; call them invalid and you throw away reachable contacts. A layered verdict keeps the nuance the server actually gave you.

The deeper reason is that deliverability is genuinely probabilistic, not a fact waiting to be looked up. Some servers greylist a first contact and only respond on a retry. Some rate-limit or temporarily block probes that look automated. Some sit behind security gateways that mask the true mailbox state. A binary verifier has to resolve all of that ambiguity by fiat, and whichever way it leans, it's systematically wrong for a slice of your list. A verdict that includes catch-all and unknown lets the tool admit uncertainty instead of inventing certainty.

This is also why a sky-high "valid rate" is a warning sign rather than a selling point. The honest valid rate for real-world B2B data sits well below 100%, because a real share of every list is catch-all, role-based, or genuinely dead. A tool advertising near-perfect validity is almost always achieving it by relabelling the uncertain cases as valid — moving the failure out of its report and into your bounce log.

Verification is perishable: freshness matters as much as the verdict

An email verdict is a snapshot of one moment. People change jobs, companies deactivate mailboxes, and domains get reconfigured. A "valid" result from eight months ago tells you almost nothing about today — the person may have left, and the address that bounced last week might have been valid the week before they did.

The decay rate is steep. B2B contact data is commonly estimated to go stale at roughly 20–30% per year, driven mostly by job changes. Apply that to a verdict and the math is sobering: a list verified a year ago could be a quarter wrong before you send a single email, and you'd have no way to tell which quarter from the verdict alone. A clean-looking valid is the most dangerous kind of stale data, because it invites confidence it no longer deserves.

This is why we put a verified_at date on every email and re-verify records as they age. A verdict without a date is a half-truth. Treating freshness as part of the verdict is the difference between a list that performs and one that looked great in a spreadsheet and bounced in production. The practical rule that falls out of this: re-verify before each send, and treat any verdict older than about 90 days as a candidate for refresh rather than a fact.

Verify at export: the right moment to check

There are two times you can verify a contact: when it enters the database, and the instant before it leaves for your campaign. The first keeps the dataset healthy; the second is the one that protects your specific send. We do both, and we make the second one the billing event.

Why does the timing matter so much? Because a verdict only describes the moment it was taken, and the moment that matters to you is send time, not collection time. A contact verified valid when it entered the dataset months ago tells you little about whether it will deliver today. Re-checking at export collapses that gap to nearly zero, so the verdict you act on reflects the world as it is when you actually email.

When you export, every address is re-checked, the verdict mix is shown to you, and you are charged only for the contacts that come back usable. Anything that verifies as invalid is refunded automatically. You never pay for a bounce, and you never wonder how stale the verdict was — it was established at the moment you took the data. Tying billing to that moment also aligns the incentives: we have no reason to inflate a valid count, because we only earn on contacts that actually verify.

• Checked at the point of use — verification runs on export, so the verdict reflects the day you send, not the day the record was first collected.
• Verdict mix shown first — you see the breakdown of valid, catch-all, risky, and invalid before you commit a credit.
• Invalids refunded — credits for invalid addresses are returned automatically; you pay for reachable data only.
• Credits never expire — because verification gates the spend, there's no pressure to burn credits on a stale list before a reset.

How accurate is email verification, really?

For mailboxes on servers that answer honestly, verification is highly reliable: a valid means the mailbox exists, and an invalid means it doesn't. The accuracy ceiling isn't the engine — it's the receiving servers that refuse to give a usable answer. Catch-all domains accept everything; some providers greylist or rate-limit probes; a few hide behind security gateways that mask the real mailbox state.

An honest verifier handles those cases by reporting them as catch-all or unknown instead of guessing. Beware any tool that promises near-perfect valid rates across the board — that number is usually achieved by relabelling uncertain addresses as valid, which moves the failure from the verification step to your bounce report.

A useful sanity check: accuracy should be judged by your bounce rate after sending, not by the valid rate the tool reports before sending. The two can diverge sharply. A verifier that calls everything valid posts a beautiful pre-send number and a brutal post-send one. A verifier that's honest about catch-all and unknown posts a more modest pre-send number and a bounce rate that stays low where it counts. The second tool is doing its job; the first is doing yours, badly.

Verification and deliverability are not the same thing

Verification tells you an address can receive mail. Deliverability is whether your message actually reaches the inbox once it does. A clean, verified list is the foundation of deliverability, but it isn't the whole house — you also need authentication (SPF, DKIM, DMARC), a warmed sending domain, relevant content, and a low complaint rate.

Think of verification as the prerequisite. It removes the addresses that would bounce and damage your reputation, which clears the way for the rest of your deliverability work to pay off. Skip it and every other improvement is built on sand. You can have flawless authentication and brilliant copy, and a dirty list will still sink you, because the bounces tell mailbox providers to distrust everything you send.

The relationship runs in one direction: verification protects deliverability, but deliverability never rescues a bad list. That's why the highest-leverage moment to verify is right before send — it's the cheapest possible insurance against the most expensive possible mistake, and it makes every other deliverability investment actually count.

What to look for in an email verification provider

Not all verification is equal, and the differences show up in your bounce report rather than the marketing page. A handful of qualities separate a verifier that protects your sending from one that just makes its own numbers look good.

• Honest verdicts — catch-all and unknown are reported as themselves, not quietly upgraded to valid. A suspiciously high valid rate is a red flag, not a feature.
• A freshness date — every verdict carries the date it was established, so you can tell a current result from a stale one.
• Verify at the point of use — the ability to re-check right before export or send, not just at some earlier moment in the data's life.
• Fair billing on uncertainty — you shouldn't pay full price for an address the verifier couldn't confirm; invalids should be refunded outright.
• Separate flags for role and disposable — shared inboxes and throwaway domains are distinct risks and should be labelled distinctly.
• Suppression respected — verification should never resurface someone who has opted out.

The bottom line on email verification

Email verification is a layered check — syntax, domain, MX, SMTP probe, catch-all detection — that produces a deliverability verdict with a freshness date. The verdict should be honest about uncertainty, the freshness should be visible, and the smartest moment to run it is the instant before a contact leaves for your campaign. That's how we do it, and it's why you only pay for contacts you can actually reach.