Every email verification service advertises a single accuracy figure — 97%, 98%, 99% — and that number is close to meaningless, because email verification averages together checks whose reliability differs by an order of magnitude.
Some of what email verification does is deterministic. Whether a domain publishes MX records is a fact; you look it up and you know. Whether a specific mailbox exists behind those records isn't a fact you can establish from outside, and at the largest providers it isn't establishable at all.
Knowing which layer produced a given verdict is the difference between using email verification well and trusting it blindly. This article breaks the checks into what they genuinely prove, what they merely suggest, and where the whole idea stops working.
Why Bounce Rate Is the Whole Game
Receiving providers judge a sender largely by how many messages they send to addresses that don't exist. A high hard-bounce rate is the clearest possible signal of a list acquired rather than earned, and it's one of the fastest routes to having your mail filtered at every large mailbox provider at once.
The generally accepted danger threshold is a hard-bounce rate above 2%, and Google's sender guidelines treat sustained failure rates as strong evidence of a bad list. What makes this expensive is that the damage outlives the campaign: reputation is scored over a rolling window, so one bad send poisons the following weeks of ordinary transactional mail — invoices, password resets, order confirmations.Email verification is cheap insurance against that. It isn't a growth tactic and it doesn't improve your copy. It stops one bad list from taking down everything else you send. For the broader picture, see what your bounce rate is telling you.
Three Tiers of Certainty in Email Verification
Sort the checks by how much you can rely on them, and the picture gets much clearer.
Tier 1: deterministic
These are lookups. The answer is a fact and it's either right or the DNS is lying to you.
| Check | What it establishes |
|---|---|
| Syntax | The address is a legal address per the RFC |
| Punycode / IDN | The domain isn't a homograph of a real one |
| MX records | The domain can receive mail at all |
| Routable MX IP | The MX doesn't point at a private range such as 10.x or 127.x |
| Disposable domain | The domain is on a list of 5,000+ known temporary-mail providers |
| DNSBL listing | The domain appears on Spamhaus DBL or SURBL |
| Bounce suppression | This address has already hard-bounced for your account |
A failure at this tier is conclusive. No MX means no mail, ever, and no probe is needed to establish it. This tier alone removes most of the garbage in a typical list.
Tier 2: probabilistic
The SMTP mailbox probe: connect to the receiving server, begin a message, ask whether it will accept this recipient, and disconnect before sending anything. A clean 550 at RCPT TO is good evidence the mailbox doesn't exist.
Evidence, not proof — and its reliability varies enormously by receiver. Which brings us to the next section.
Tier 3: heuristic
Signals that correlate with bad addresses without establishing anything:
| Signal | Effect on the score |
|---|---|
| Gibberish local part | −15 |
| Missing SPF record | −10 |
| Missing DMARC record | −10 |
| Domain registered under 30 days ago | −10 |
Plus-addressing (user+tag@) | −5 |
| Custom domain with MX, SPF and DMARC all present | +5 |
Role address (info@, support@) | 0 — flagged, not penalised |
| Free provider (Gmail, Yahoo) | 0 — neutral |
Likely typo (gmial.com) | 0 — informational, with a suggested correction |
Two of those deserve comment because other vendors get them wrong.
Role addresses aren't penalised. info@ and sales@ are how businesses actually receive mail. Marking them risky by default is a habit inherited from cold-outreach tooling, where a role address means you never had a relationship with a person — a legitimate concern for that use case and irrelevant for everyone else. The address is flagged so you can filter on it if it matters to you, and it costs no score.
Free providers are neutral. A Gmail address isn't lower quality. Most of the world's real people use one.
The SMTP Probe, and Where It Stops Working
The probe is the check people imagine when they think of email verification, and it's the one with the largest gap between reputation and reality.
It works well against ordinary business domains — a company's own mail server, a hosting provider, most self-hosted setups. Ask about a nonexistent recipient and you get a rejection at RCPT TO. That's a solid answer.
It doesn't work against the large free providers. Gmail, Yahoo, Outlook.com, iCloud, and AOL accept every recipient during the SMTP conversation regardless of whether the mailbox exists, and reject invalid ones later by generating a bounce. They do this deliberately, precisely to stop outsiders from enumerating which of their addresses are real. Probing a Gmail address tells you nothing beyond what you already knew from the MX lookup.
This is why deep email verification of a free-provider address is billed at the quick rate here — one credit, not two. The extra check can't run, so charging for it would be charging for nothing. The split is shown before you submit a job and returned in the API response.
The honest summary: for business domains the probe adds real confidence. For Gmail and its peers, nobody can tell you whether a mailbox exists, and any vendor claiming otherwise is selling you a guess with a confident label on it.
Catch-All Domains Break Email Verification Entirely
A domain configured to accept mail for every address, whether or not a mailbox exists, is unverifiable by construction. Ask about anything@catchall-domain.com and the server says yes, because it says yes to everything.
Any address on such a domain lands in the risky bucket, and it's genuinely risky: it might reach a person, it might reach an unattended sink, and it might be a spam trap. There's no test that distinguishes them from outside.
This is one of the less obvious costs of running a catch-all on your own domain — you become invisible to email verification, so everyone who legitimately wants to check your address gets an inconclusive answer. It's worth reading alongside how catch-all mail actually behaves, which covers the rest of the trade.
Quick and Deep
| Quick | Deep | |
|---|---|---|
| Checks run | 22 | 25 |
| SMTP mailbox probe | No | Yes, business domains only |
| Spam-trap heuristic | No | Yes |
| Credits per address, business domain | 1 | 2 |
| Credits per address, free provider | 1 | 1 |
| Roughly, for 10,000 addresses | 1–5 minutes | 5–15 minutes |
| Use for | Routine hygiene, re-verification of a known list | Purchased or inherited lists, high-stakes campaigns |
The practical rule: quick for a list you built yourself and are keeping clean, deep when you didn't build it and can't vouch for where it came from.
Reading the Statuses
Each address gets a status and a trust score from 0 to 100.
| Status | Score | What to do |
|---|---|---|
| Safe | 90–100 | Send |
| Valid | 60–89 | Send; watch bounces on these |
| Risky | 20–59 | Exclude from cold outreach; fine for transactional mail to people you know |
| Invalid | 0–19 | Remove from the list |
| Unknown | — | A timeout or transient failure. Re-verify later; treat as risky meanwhile. |
The distinction that matters most is between risky and invalid. Invalid is a fact — send to it and you get a bounce. Risky is an absence of information, and the right treatment depends on context. A risky address on a list you bought should be dropped. The same status on a customer who has been paying you for two years means their domain runs a catch-all, and you should absolutely keep sending their invoices.
Verification can't make that distinction for you. It doesn't know your relationship with the address; you do.
Lists Decay, So Email Verification Is Maintenance
Email lists rot at roughly 2% a month — people change jobs, companies fold, addresses are abandoned. A list verified eighteen months ago is around a quarter wrong today, which is comfortably past the threshold that damages sender reputation.
So email verification is maintenance, not a one-time cleanup:
- At capture. Verify a single address at signup and you catch the typo —
gmial.com— while the person is still on the page to fix it. This is the highest-value verification you'll ever run. - Before any large send. Especially to a segment you haven't mailed in months.
- Quarterly for active lists. Keeps decay below the threshold that matters.
- Always for an inherited list. Every list that arrives with an acquisition, a merger, or a departing colleague's spreadsheet.
Doing This Properly
Verify at the point of capture, not after the fact. Catching a typo at signup recovers a subscriber. Catching it six months later recovers nothing, because the person is long gone.
Suppress rather than delete. Keep invalid addresses in a suppression list instead of removing them, or they will be re-imported by the next CSV someone uploads.
Don't buy lists. Verification tells you whether an address exists. It can't tell you whether the person agreed to hear from you, and consent is the part that determines whether you end up in a spam folder or a regulator's inbox. A verified purchased list is a list of real people who will report you.
Warm up gradually after a big clean. If you haven't sent in a while, ramping volume slowly matters more than the cleaning did. See improving deliverability.
Email verification isn't a fix for bad sending. It removes one specific failure — nonexistent recipients. It does nothing for missing SPF, DKIM, or DMARC, and those are the checks the receiving server runs before it ever looks at your list quality.
Frequently Asked Questions
Can email verification tell me whether a Gmail address exists?
No, and neither can anyone else. Gmail accepts every recipient during the SMTP conversation and bounces invalid ones afterwards, specifically to prevent address enumeration. A Gmail address that passes email verification has passed syntax, MX and reputation checks — not an existence check.
Why does deep email verification cost less for Gmail addresses?
Because the extra check deep email verification performs can't run against those providers. Free-provider addresses are billed at the quick rate even inside a deep job, and the split is shown before you submit.
What is a catch-all result and should I send to it?
It means the domain accepts mail for every address, so existence can't be tested. Send if you've a real relationship with the recipient. Don't send as part of cold outreach.
Are role addresses like info@ bad?
No, and they aren't penalised in the score. They are flagged so you can filter them out if your use case calls for it — cold outreach usually does, transactional mail never does.
Does email verification hurt my sending reputation?
No. The probe opens an SMTP conversation and disconnects before sending anything, so no message is transmitted and nothing reaches an inbox. Probes are throttled per receiving host, because hammering one server from one address looks like enumeration and gets the probe blocked.
How often should I re-verify?
Quarterly for active lists, before any large send, and always for a list you inherited. Decay of roughly 2% a month means eighteen months of neglect is enough to push a clean list past the danger threshold.
Can I run email verification through the API?
Yes — single addresses and bulk jobs both, with job status and results retrievable programmatically. See the verifier API reference.
What does the trust score actually mean?
It starts at 100 and is reduced by risk signals, with a bonus for domains that have proper authentication in place. Hard failures set it to zero outright. It's a summary of the checks below it, not an independent measurement — read the individual flags when a decision matters.
