The Hunter Email Verifier: What Its Checks Prove, and What They Cannot
Hunter publishes the eight checks its verifier runs and prices a verification at half a credit. What each check establishes, and where accept-all domains stop it.
Hunter's verifier runs eight published checks, covering address syntax, disposable and webmail domains, MX records and SMTP presence, a per-address SMTP conversation, and accept-all detection. A verification costs half a credit against a full credit for a search, and the free plan covers 100 verifications a month.
Key takeaways
- The eight checks split into three groups: syntax and pattern checks that prove nothing about delivery, domain checks that prove the organisation is reachable, and the SMTP check that speaks to the individual mailbox.
- Hunter claims a proprietary method for verifying accept-all addresses with several major providers, which is scoped, undescribed and unverifiable from outside.
- A verification costs half a credit against a full credit for a search, and Hunter's higher-volume packs separate the two into distinct currencies entirely.
- The status taxonomy, any confidence score and the verifier's API rate limit are not published on the page, which matters when integrating rather than clicking.
Reviewed and updated August 14, 2026
Hunter's email verifier runs eight named checks on an address, and it charges half a credit to do it against one full credit for a search. That pricing decision is a statement about the relative cost of the two operations, and it is one of the few places in this category where a vendor prices verification below finding rather than bundling both into one indistinguishable unit.
This page covers what those eight checks establish, what Hunter says about accept-all domains and how much weight that claim can carry, what the free allowance actually is, and how the verifier fits alongside a bulk verification step. For the category comparison across verification vendors, see our guide to email verification tools, which this page deliberately does not rebuild.
The eight checks
Hunter publishes exactly what the verifier tests, which is more than most vendors do.
| Check | What it establishes |
|---|---|
| Valid format | The address is syntactically well formed |
| Gibberish email address | The local part looks machine-generated rather than human |
| Disposable email address | The domain belongs to a temporary-mailbox service |
| Webmail email address | The address is a consumer mailbox rather than a company one |
| Presence of MX records | The domain publishes mail exchange records |
| Presence of SMTP server | A mail server answers at that domain |
| SMTP check | The server responds to a conversation about that specific address |
| Accept-all domain | The server accepts mail to every address on the domain |
Those eight fall into three groups that behave very differently, and telling them apart is most of what you need to read a verification result properly.
Syntax and pattern checks cost nothing and prove nothing about delivery. A perfectly formed address on a real domain can still bounce. What they are genuinely good at is catching the class of junk that never should have entered a list: malformed strings, keyboard mashing, and disposable domains that exist to be thrown away.
Domain checks establish that mail can reach the organisation. MX records and an answering SMTP server tell you the destination exists and is configured. They say nothing about whether a specific mailbox behind it does.
The mailbox check is the SMTP conversation, and it is the only one that speaks to the individual address. It is also the one that stops working exactly where you need it most.
The accept-all problem, and Hunter's claim about it
An accept-all domain, also called catch-all, is configured to accept mail addressed to every local part. Invent an address on one and the server will accept it, so an SMTP check returns a positive result for an address that has no mailbox behind it. That is not a flaw in any particular verifier. It is what the protocol conversation can observe.
Hunter's page makes a claim here worth quoting precisely: it says the company is able to verify accept-all addresses with several major email providers using a proprietary solution, and that this lets you get more out of your lead lists while minimising bounce rates.
Three things are worth saying about that, in order.
It is a scoped claim, not a general one. Several major email providers is a much narrower statement than accept-all domains, and it is narrow in the direction that matters: the large consumer and hosted platforms are the tractable cases, while the accept-all domains that dominate a B2B list are self-hosted and enterprise mail systems that no external observer can inspect.
It is an unverifiable claim from outside. The mechanism is not described, and there is no way to audit it without ground truth about which mailboxes exist, which nobody outside the receiving organisation has.
It does not change our position. We do not send to a mailbox whose existence nobody can evidence, and the catch-all tail gets banked as a preserved artifact rather than mailed. Volume comes from fresh sourcing instead. That rule is what keeps bounce rates low enough for sending domains to survive, and the reasoning is in our bounce rate benchmarks.
None of that means the feature is worthless. It means a vendor's confidence about a category of address is not evidence, and a claim scoped to some providers should never be read as a solution to the category.
- The address is well formed and not obvious junk
- The domain accepts mail and a server answers
- On a normal domain, that a specific mailbox exists
- That the address is worth spending a send on
- That a mailbox exists behind an accept-all server
- That the address belongs to the person you think
- That the person still works at that company
- That the message will reach an inbox rather than spam
The second item in that right-hand column is the one that costs real money. An address can be perfectly deliverable and still belong to somebody else, or reach the right person at a job they left two years ago. No verification step sees either case, by construction, and every deliverability metric you monitor will look fine.
What the verifier returns
Hunter states that the verifier returns a verification status along with the available data sources used in the verification, and describes it elsewhere as identifying invalid, risky and accept-all addresses.
What the page does not publish is an enumerated list of the status values, a definition of each, or a confidence score. Nor does it publish an API rate limit for the verifier. Those are absences in the page we fetched rather than absences in the product, and if any of them is load-bearing for an integration you are building, it is a question for the vendor rather than something to infer.
- Yes: The eight named checks the verifier runs
- Yes: That a verification costs half a credit against a full credit for a search
- Yes: A free allowance of 100 verifications a month with an account
- Yes: That credits last 12 months and a repeat inside a calendar month bills once
- No: An enumerated list of verification statuses with definitions
- No: A confidence score alongside the status
- No: An API rate limit for the verifier
That gap matters more than it sounds for anyone writing code against it. A status taxonomy is exactly the thing you need pinned down before you branch on it, and a status you have not seen documented is a status your handler will fall through.
What it costs
Two pricing details are currency independent and worth knowing whichever market you buy in.
A verification costs half a credit where a search costs a full one. Hunter's higher-volume Data Platform packs go further and separate the two into distinct currencies, search credits and verification credits, which is the clearest possible statement that the operations are not equivalent.
The free plan verifies up to 100 addresses a month with an account, against a monthly credit allowance of 50 on the same plan, consistent with verification costing half a credit.
Two further terms shape the real cost: credits can be used up to 12 months from purchase, and each repeated search or verification is counted once per calendar month, so re-checking an address you already checked this month does not bill twice.
The plan prices themselves are localised by region. The page served to us rendered in pounds rather than dollars, with the billing toggle defaulting to yearly at a stated 30 percent discount, so any figure quoted elsewhere may not be the figure you are shown. Check your own currency on the vendor's page rather than trusting a third-party table, including this one.
Where a finder's verifier fits
Verification attached to the tool that found the address saves an export, an upload and a reconciliation, and at small volumes that convenience is worth more than a per-check price difference.
At the volumes where verification cost matters, a dedicated bulk verifier wins on unit price and on the terms around it, which is why our own sequence puts one first: MillionVerifier brute-force, then Prospeo, then Findymail, with no fourth paid stage. Our page on MillionVerifier covers what a bulk verifier's result buckets mean in practice, and the sequencing argument sits in our guide to email finder tools.
The right mental model is that a finder's built-in verifier is a convenience feature for the addresses that finder produced, and a bulk verifier is infrastructure for every address you hold from any source. Most teams need both, and confusing one for the other is how a list arrives at a sending platform half-checked. For a vendor that separates the two meters explicitly, see our page on Voila Norbert.
The short version
Hunter's email verifier runs eight published checks, from syntax and disposable-domain detection through MX and SMTP presence to the per-address SMTP conversation and an accept-all determination. A verification costs half a credit against a full credit for a search, and the free plan covers 100 verifications a month. Credits last 12 months and a repeated check inside a calendar month is billed once. Hunter claims a proprietary method for verifying accept-all addresses with several major providers, which is a scoped and unverifiable claim that does not change our own rule: the catch-all tail is banked rather than mailed. The status taxonomy, any confidence score and the verifier's API rate limit are not published on the page, which matters if you are integrating rather than clicking.
If you would rather see the whole motion running on your own ICP without assembling a verification stack first, start a free campaign and we will build the list, the copy and the sending infrastructure around it.
Pricing and features verified as of August 2026. Verify current terms with the vendor before relying on them.
Frequently asked questions.
Frequently asked questions- Is the Hunter email verifier free?
- There is a free allowance. Hunter states that creating an account puts you on a Free plan that verifies up to 100 email addresses a month. That sits alongside a monthly credit allowance of 50 on the same plan, which is consistent with a verification costing half a credit while a search costs one.
- Can Hunter verify catch-all addresses?
- Hunter says it can verify accept-all addresses with several major email providers using a proprietary solution. Read the scope carefully: several major providers is much narrower than accept-all domains generally, and the hard cases on a B2B list are self-hosted enterprise systems no external service can inspect. We bank the catch-all tail rather than mail it.
- What statuses does the Hunter verifier return?
- The page states that the verifier returns a verification status along with the data sources used, and describes it as identifying invalid, risky and accept-all addresses. An enumerated list of status values with definitions is not published there, so pin the taxonomy down with the vendor before writing code that branches on it.
- Do I still need a bulk verifier if I use Hunter?
- Usually yes, because they solve different problems. A finder's built-in verifier is a convenience for addresses that finder produced. A bulk verifier is infrastructure for every address you hold from any source, and it wins clearly on unit price at the volumes where verification cost actually matters.
About the author.
B2B cold email experts helping companies generate qualified leads through done-for-you outreach campaigns.
RevenueFlow Team
Explore more.
Ready to scale your outreach?
We build GTM engines that book real meetings. See the receipts.
Related articles.
Voila Norbert: Three Separate Meters, and Where It Belongs in a Waterfall
Voila Norbert prices finding, verifying and enriching separately rather than bundling them into one credit. Every rate, and where each stage slots into a sequence.
Skrapp: The Credit Model, the Search Caps, and Where It Fits
Skrapp bills only for deliverable emails, which is the good news. The daily search caps sit below the prices and constrain more teams than the credit allowance does.
Clearbit Connect: What Happened to the Gmail Extension
Clearbit Connect was the free Gmail sidebar for finding work addresses. The vendor named it for discontinuation in 2025. Here is what replaced the job it did.
Free Email Finders: What Unlimited Actually Covers
Free plans cap the step that builds a list, and unlimited usually describes searching rather than exporting. The cheapest workflow that produces sendable addresses.
Prospeo: What It Does, and Why It Sits Second in Our Waterfall
Prospeo is the second stage of the email waterfall we run. The structural property that earns it that position, and what we deliberately will not publish about it.
RocketReach Review: Who It Fits, and What to Verify Before You Buy
An assessment of RocketReach built from its own documented terms rather than aggregated ratings: what its billing edges commit to, and where the trade sits.