How to Choose an Email Verification Service: 12 Questions

To choose an email verification service, ask how it treats addresses it cannot confirm, whether its SMTP checks really reach recipient servers, how it handles catch-all domains, what happens to your data, and whether its pricing fits your yearly volume. Then test it on a small file of addresses whose answers you already know.

Most buyer's guides for this category are ranked lists with an affiliate link at the top. This is a checklist instead: twelve questions you can send to any vendor's support team, what a good and a bad answer sound like, and a short protocol for checking whether the answers are true.

Why the questions matter more than the feature list

Every verifier advertises the same features: syntax check, MX check, SMTP check, catch-all detection, disposable detection, an API. The differences that cost you money are in how each tool behaves when it cannot get a clear answer, and that never appears on a feature grid.

So the questions below focus on behaviour, not features. Group them into three areas: the result itself, the infrastructure that produces it, and the commercial terms.

Questions about the result

1. What do you return when you cannot confirm a mailbox?

This is the most important question on the list. A good answer is a separate status, usually called risky, unknown or accept-all, that is never counted as valid. A bad answer is any version of "we use proprietary signals to determine validity" without a separate uncertain bucket.

Our post on how to tell if your verifier is lying explains why: a tool that defaults to valid when its check fails looks most confident exactly when it knows least.

2. How do you handle catch-all domains?

A catch-all domain accepts mail for every address, so SMTP verification cannot distinguish a real mailbox from a made-up one. A good answer admits this and returns catch-all as its own status. Some vendors offer additional scoring for catch-all rows; ask what that score is based on and whether they will tell you how often it is wrong. If they cannot, treat it as a guess.

3. What do your statuses map to?

Vendors name statuses differently: valid, deliverable, ok; invalid, undeliverable; risky, unknown, accept-all, do-not-mail. Ask for the full list and a one-line definition of each. You will need this when you import results into your CRM or sending tool, and a vague mapping is a sign the vendor has not thought about it either. Our guide to verification statuses has a vendor-by-vendor map.

4. Do you flag role, disposable and free-provider addresses separately?

These are not invalid, and a tool that marks them invalid is deleting real people. They are decisions for you to make. Ask whether they come back as separate flags alongside the main status, and how often the disposable domain list is updated.

5. What does your accuracy figure mean?

If the vendor advertises an accuracy percentage, ask three things: accurate against what ground truth, measured on which list, and audited by whom. Accuracy claims in this category are generally the vendor's own and unaudited. Our article on what "99% accurate" means goes through why a single number cannot describe the hard cases. A vendor that answers these questions plainly, even with an unflattering answer, is more trustworthy than one with a bigger number.

Questions about the infrastructure

6. Do your SMTP checks run from servers that can reach port 25?

Mailbox checks need an outbound connection on port 25, and most cloud providers block it by default. A verifier running on blocked infrastructure cannot complete a single SMTP check. The good answer is a plain yes and a description of where checks run. If the answer dodges, combine it with question 1: blocked infrastructure plus a default-to-valid fallback means nothing is being verified.

7. Do you send any email to the addresses?

The answer should be no. Verification uses the SMTP RCPT TO step of a conversation and disconnects before any message is sent. Our explainer on checking an address without sending shows the exchange.

8. How do you handle greylisting and rate limits?

Some servers return a temporary failure the first time they see a sender (greylisting), and large providers throttle repeated connections. Ask whether the tool retries later, and what it returns if retries also fail. The right final status for a check that never completed is unknown or risky, never valid.

9. What is your throughput, and what are your file limits?

Ask for addresses per minute or per hour and the maximum rows per upload. A tool that takes a day to process a large file is fine if you know in advance and a problem if you planned to send tomorrow. Also ask whether the API has its own rate limits, separate from the bulk upload.

Questions about the commercial terms

10. Do credits expire?

This changes the real price more than the headline rate does. Credits that never expire make pay-as-you-go strong for occasional users; DeBounce, for instance, sells credit packs from 5,000 for $15 that do not expire. Monthly allowances that reset make subscriptions expensive if your volume is irregular. Ask whether unused allowance rolls over.

11. Do you charge for duplicates, unknowns and re-checks?

Ask whether duplicates in an upload are removed before charging, whether you are charged for rows that come back unknown, and whether re-checking an address within a short window uses another credit. These details decide your cost per useful result, which is the number that matters. Price your expected volume on the verification cost calculator once you have the answers.

12. What happens to my list after verification?

Ask how long uploaded files and results are kept, whether they can be deleted on request, where data is processed, and whether addresses are used for anything else, such as building a database. If you mail people in the UK or EU this is not a formality; see our posts on GDPR and B2B cold email and whether collecting business emails is legal. This is not legal advice, but a vendor that cannot answer the retention question clearly is a risk you are taking on.

Good and bad answers at a glance

Question	Good sign	Warning sign
1. Unconfirmed mailboxes	Separate risky/unknown status	Everything ends up valid or invalid
2. Catch-all	Own status, honest about limits	"We verify catch-alls" with no method
3. Status names	Full written mapping	Vague or changes by channel
4. Role/disposable	Separate flags	Marked invalid
5. Accuracy	Defines ground truth and test set	A number with no method
6. Port 25	Plain yes, describes setup	Avoids the question
7. Sending mail	Never sends	Unclear
8. Greylisting	Retries, then unknown	Times out to valid
9. Throughput	Published figure	"Fast"
10. Credit expiry	Clear terms	Allowance resets silently
11. Billing edge cases	No charge for duplicates	Charges every row
12. Data retention	Stated period, deletion on request	No answer

A one-hour test protocol

Answers from a sales team are claims. You can check most of them yourself in about an hour, using free trial credits.

1. Build a known-answer file. Use the six-row file from our verifier testing post: a fabricated address at a provider that rejects unknown mailboxes, your own real address, a broken address, a disposable address, a domain with no mail server and a role address. Add a fabricated address at a domain you know is catch-all; it should come back catch-all or risky, not valid.
2. Add a real sample. Take 200 to 500 random rows from a list you actually plan to send to.
3. Run the same file through two or three shortlisted tools. Same file, same day.
4. Score the known rows. Any tool that marks the fabricated address valid is out, whatever else it does well.
5. Compare the disagreements on the real sample. Where tools disagree, look at the rows. If one tool turns another's risky rows into valid, ask it how (see question 2).
6. Check the operational details. Time how long the file took, check whether duplicates were charged, and export the results to see whether the statuses map cleanly into your sending tool.
7. Ask the retention question in writing and keep the reply.

The test does not tell you which tool is "most accurate", because nobody has a perfect ground truth for the uncertain rows. It tells you which tools guess and which admit they do not know, and that is the property that protects your bounce rate.

Matching the answers to your use case

The right tool depends on your volume pattern more than on anything else. A rough guide:

Your situation	What to weight most
One-off clean of an old list	Credit expiry and per-1,000 price (Q10, Q11)
Steady monthly outbound	Monthly cost at your real volume, throughput (Q9)
Signup-form checks	API latency, rate limits, fail-open behaviour
Mostly B2B lists	Catch-all handling (Q1, Q2)
UK/EU data	Retention and processing location (Q12)

On price alone, published rates already show the trade-offs. DeBounce is cheaper for one-off cleans; EmailListVerify ($16/month for 5,000, or $6.99 for 1,000 pay-as-you-go) is cheaper for small monthly volumes. Our comparison hub lays out the rest neutrally.

Disclosure — our product

SimpleVerifier is an email verification service run by the publisher of this article. It costs $29.99/month flat, with no credits, and returns anything it cannot confirm as risky rather than valid; throughput is 45 addresses per minute and uploads are capped at 100,000 rows. It is not the cheapest option for one-off cleans or for low monthly volumes, as the section above notes.

Takeaway

Send the twelve questions to every vendor on your shortlist, then run the known-answer file through each one. The answers to questions 1, 2 and 6 tell you whether a tool verifies anything at all; questions 10 and 11 tell you what it will really cost. Choose on those, not on the accuracy percentage at the top of the homepage.