What email verification results actually mean

You upload ten thousand addresses to a verification service and get a spreadsheet back with a status against each one. Most people delete the invalid rows, send to everything else, and are surprised when the bounce rate is still four percent.

The categories are not as simple as they look. One of them is a genuine unknown dressed up as a result, and another is a judgement call that different providers make differently. This guide explains what each verdict is actually derived from, so you can decide what to do with it rather than treating the spreadsheet as gospel.

What a verifier actually does

Verification is a sequence of increasingly expensive checks, each of which can end the process early:

1. Syntax. Is the string a well-formed address? Free, instant, and the only check a pattern matcher can perform. Fails a fraction of a percent of real lists.
2. Domain resolution. Does the domain exist in DNS, and does it publish an MX record saying where its mail goes? A domain with no MX record accepts no mail. This alone removes most typo domains.
3. Known-list matching. Is the domain a disposable mailbox provider? Is the local part a role account? Is either on a list of known traps? Lookups against the provider's own data.
4. SMTP probe. Connect to the mail server and begin a delivery conversation as far as naming the recipient — then stop before sending anything. The server's response to RCPT TO reveals whether it will accept mail for that address.

Step four is where the interesting results come from, and it is unreliable by design. Server operators know it is used for reconnaissance as well as hygiene, and many configure their servers to give nothing away. That is the source of the categories below.

Valid

The domain exists, publishes an MX record, and its mail server accepted the recipient during the probe.

This is a real signal and you should send to these. But note what it establishes: the server said it would accept mail for that address at that moment. It does not establish that a person reads it, that the mailbox is not an abandoned account of someone who left in 2023, or that the address is not a recycled spam trap. It is the best available evidence, not proof.

A well-verified list of "valid" addresses typically bounces below one percent. If yours bounces at five, either the verification is old or the provider is guessing.

Invalid

The domain does not resolve, publishes no MX record, or the server explicitly rejected the recipient with a permanent error.

Delete these. Do not "try them and see" — that attempt is precisely the hard bounce you are paying to avoid, and hard bounce rate is the metric that decides whether providers keep accepting your mail.

Two things worth knowing. Invalid results from typo domains often have an obvious correct form (gmial.com, hotmial.com), and some services will suggest the correction; treat a suggestion as a new unverified address rather than a fix. And a domain that failed to resolve during a network hiccup can come back invalid incorrectly — if an entire company's addresses land in this bucket at once, re-check before deleting them.

Catch-all, accept-all, unknown

This is the category people misread, and it is often twenty to thirty percent of a B2B list.

A catch-all domain is configured to accept mail for every address at that domain, whether or not the mailbox exists, and to sort it out afterwards. Probe such a server with a nonsense address and it accepts that too. So the probe returns no information: the verifier cannot distinguish a real mailbox from an invented one, and reports that honestly as catch-all, accept-all, or unknown depending on the vendor's vocabulary.

Crucially, this is not a verdict about the address. It is a statement that the check could not be performed. The address may be perfectly good — catch-all is common at large enterprises, at companies using certain security gateways, and at organisations that deliberately obscure their directory.

What to do with them, in order of preference. If the address follows the visible convention at that company (first.last@ where everyone else is first.last@), it is probably real. If you can corroborate the person from another source — a signature block, a directory, a conference listing — that is stronger evidence than any probe. Failing both, send to them in a small separate batch and read the bounce rate before releasing more. What you should not do is mix them into a large send with your verified addresses, because if they are bad you will not know until the damage is aggregated.

Risky, disposable and role

Disposable means the domain belongs to a temporary mailbox service — addresses that expire in minutes and exist to get past signup forms. In a B2B prospect list they are noise. In a signup list they tell you something about how that user regards your product. Delete them from outreach.

Role means the local part is a function rather than a person: info@, support@, sales@, abuse@. Usually deliverable, usually a bad idea to mail cold — shared inboxes complain at a much higher rate, and abuse@ is read by exactly the people who report senders. The exception, worth knowing before you delete the column, is very small businesses where info@ genuinely is the owner's inbox.

Risky is a vendor-specific bucket, and you should find out what your vendor means by it before acting. It typically covers full mailboxes, addresses matching known trap patterns, domains with poor reputation, and greylisting servers that deferred the probe. The actions differ enormously — a full mailbox is a real person, a trap pattern is a landmine — so a single "risky" label is not enough to decide on. Any serious provider will give you the sub-reason if you ask for it.

Spam traps, and why no verifier promises to catch them

A spam trap is an address that exists solely to identify senders who did not obtain permission. There are two kinds and they punish different mistakes.

Pristine traps were never valid addresses. They are published somewhere a human would never find them but a scraper will — hidden in page markup, buried in a document. Mailing one is near-conclusive evidence that you harvested the address, and it is treated severely.

Recycled traps were real mailboxes, abandoned by their owners, left to bounce for a period, then reactivated by the provider as traps. Mailing one proves you are sending to a list you have not cleaned in a long time.

Verifiers cannot reliably detect either. A pristine trap is syntactically valid and its server accepts mail; a recycled trap looks identical to any working mailbox. Providers maintain lists of suspected traps and will screen against them, but no honest vendor claims full coverage — publishing a trap list would destroy its usefulness, so the real lists stay secret.

The defence is behavioural rather than technical. Do not scrape addresses from page markup that no human would see. Re-verify lists before reusing them. Remove addresses that have not engaged in a year rather than mailing them harder. Traps punish neglect and harvesting; they do not punish careful sending.

Results decay faster than you think

A verification result is a snapshot, and B2B contact data ages quickly. Roughly a fifth of professionals change jobs each year, and the mailbox usually goes with the job. Companies get acquired and domains get retired. Employees leave and their addresses are disabled or turned into forwarders and later into traps.

The practical consequence: a list verified eight months ago is not a verified list. Treat results as fresh for around three months, acceptable up to six with a rising bounce rate, and stale after that. Re-verifying before a significant send is far cheaper than the reputation damage from a bad one.

This is also an argument against hoarding. A list of 50,000 addresses you never send to costs money to keep current and provides nothing. A list of 3,000 you verify and use is worth more.

Judging a verification service

Accuracy claims in this market are marketing numbers and not comparable between vendors. These questions are more informative:

• Do they charge for catch-all results? Most do. Given the result contains no information about the address, know what fraction of your list it will be before you commit — for B2B it can be a third of the bill.
• Do they give sub-reasons? "Risky" alone is not actionable. "Mailbox full" and "matches trap pattern" are.
• What happens to your uploaded list? You are handing a third party a file of personal data. Retention period, deletion policy, sub-processor location and GDPR posture are the questions, and vague answers are their own answer.
• Do they offer an API as well as uploads? Verifying at the point of capture prevents the problem instead of cleaning up after it.
• Do credits expire? Many packages expire in twelve months, which changes the real price per check considerably.

A pragmatic test: run a few hundred addresses whose status you already know — your own colleagues, plus some deliberately invented addresses at your own domain — through a trial and compare. It tells you more than any published accuracy figure.

Deciding what to send to

A workable default once results are back:

And the point that makes all of it cheaper: run verification last, after deduplication, role removal, domain filtering and subtracting your suppression list. Every address you remove for free is one you do not pay to check. That ordering is set out in how to clean an email list before your first campaign, and the authentication side of getting delivered in why your emails land in spam.