Hunter.io is searched about 3,000 times a month in India. Most users arrive for the email finder, a quick way to guess the right address pattern for a founder, a CXO, or a procurement head. Many then use Hunter’s built-in verifier and assume the job is done.
That assumption is where bounce problems begin. Finding an email and confirming it can receive mail today are different tasks. This guide explains how Hunter’s verifier works, how to read each status and score, and where a dedicated verification step still earns its place.
Finding vs Verifying: Two Different Jobs
An email finder predicts an address. It looks at the company domain, known patterns (firstname@, firstname.lastname@, f.lastname@), and public sources, then returns its best guess.
A verifier tests an address. It checks syntax, confirms the domain accepts mail, and asks the mail server whether that specific mailbox exists.
Hunter does both, which is convenient. But a found address carries two risks: the pattern guess may be wrong, and the address may have been right once and stale now. Verification addresses both, as long as you understand its limits.
How Hunter’s Email Verifier Works
Hunter runs the standard sequence:
- Format check against address syntax rules.
- Domain checks, including MX records. Our MX record lookup guide explains what these show.
- SMTP check with the mail server to test mailbox existence without sending.
- Accept-all detection, probing with a random address the domain should reject.
- Risk checks for disposable and webmail providers.
Hunter also blends domain-level intelligence from its own ecosystem. As a result, its confidence score can sometimes differ from a raw SMTP result.
Hunter Verification Statuses Explained
| Status | Meaning | Recommended action |
|---|---|---|
| Valid | Mailbox confirmed by SMTP | Send; re-check if the record is old |
| Invalid | Mailbox or domain does not accept mail | Remove |
| Accept-all | Domain accepts any address; mailbox cannot be confirmed | Segment and send cautiously |
| Webmail | Personal provider such as Gmail or Yahoo | Fine for B2C; question fit for B2B |
| Disposable | Temporary address | Remove |
| Unknown | Server did not give a conclusive answer | Retry later or exclude from priority sends |
Hunter notes that unknown results often come from greylisting, where a server temporarily refuses unfamiliar connections. Re-verifying after a couple of days can resolve some of them.
Reading the Confidence Score
Every result carries a score from 0 to 100. The score matters most for accept-all and found-but-unconfirmed addresses. A practical segmentation:
- Valid, 90+: primary sequence.
- Valid, 70–89: send, monitor closely.
- Accept-all with high score: secondary segment, small batches.
- Unknown or low score: exclude from time-sensitive campaigns.
One caution. A high score on an accept-all domain can reflect domain-level delivery history rather than confirmation of that specific person’s mailbox. It is a probability, not proof.
Where Hunter’s Verification Falls Short
Credit economics
Hunter plans bundle searches and verifications into monthly credits. Teams that use Hunter mainly for finding often exhaust credits before verifying the full list, and skip the step under deadline pressure.
Catch-all prevalence in Indian B2B
Indian IT services, BFSI, and conglomerate domains frequently run accept-all configurations. On these, every verifier, Hunter included, returns uncertainty. See catch-all email addresses explained.
Point-in-time results
Saved leads retain their last verification date. A lead verified in March and emailed in September should be re-verified. Hunter itself recommends running a fresh verification before outreach.
Spreadsheet workflows
Many Indian SDRs build lists in Google Sheets from several sources: Hunter, Apollo, LinkedIn research, event lists. Verifying each source inside its own tool fragments the process. A single verification pass on the combined sheet is cleaner. Our guide to B2B email list verification covers multi-source lists.
A Practical Workflow for Hunter Users in India
- Find in Hunter. Note the confidence score for every found address.
- Consolidate Hunter results with other sources in one sheet, with a source column and date column.
- Deduplicate before verification to avoid paying twice for the same address.
- Verify the full sheet in one pass with a verifier that returns clear statuses beside each row. BounceProof runs this directly inside Google Sheets.
- Segment into send now (valid), send cautiously (accept-all), and hold (unknown).
- Suppress invalid, disposable, and role-based addresses from cold sequences.
- Re-verify anything older than 60–90 days before reuse.
This workflow also reinforces the finding step. When verification repeatedly rejects a pattern at one company, you learn the pattern is wrong and stop guessing it.
A worked example
A Hyderabad-based agency builds a 1,200-contact list of marketing heads at Indian D2C brands: 700 from Hunter, 400 from Apollo, and 100 from event badges. After deduplication, 1,080 unique addresses remain. A single verification pass returns roughly this shape:
| Result | Share | Action |
|---|---|---|
| Valid | ~70% | Primary sequence |
| Accept-all | ~15% | Secondary domain, small batches |
| Unknown | ~5% | Retry in 48 hours |
| Invalid, disposable, role | ~10% | Suppress |
Without that pass, the invalid tenth alone would push a first send well past the 2% bounce threshold. With it, the agency launches on the valid segment, watches bounces for two days, and only then releases accept-all contacts. The proportions will differ for every list, but the discipline is the same.
Key Takeaways
- Hunter is primarily a finder with a capable built-in verifier.
- Statuses include valid, invalid, accept-all, webmail, disposable, and unknown, each with a 0–100 score.
- High scores on accept-all domains are probabilities, not confirmation.
- Unknown results often resolve on a retry after greylisting clears.
- Consolidate multi-source lists and verify in one pass before sending.
- Re-verify saved leads older than 60–90 days.
Frequently Asked Questions
It is reliable on domains that answer SMTP checks honestly. Like every verifier, it cannot confirm individual mailboxes on accept-all domains, so those results carry risk.
The domain accepts mail for any address, including nonexistent ones, so Hunter cannot confirm the specific mailbox. The confidence score indicates likelihood, not certainty.
The receiving server did not give a clear answer, often due to greylisting or anti-verification protections. Retrying after a day or two sometimes resolves it. See why verification returns unknown.
If the list is large, combines multiple sources, or is older than a few weeks, a consolidated verification pass reduces bounce risk and keeps one consistent set of statuses.
Hunter offers a free plan with limited monthly searches and verifications. Paid plans increase credits.
Conclusion
Hunter solves the discovery problem elegantly. Its verifier is useful, honest about uncertainty, and good enough for small, fresh lists. The risk comes from treating a found address as a verified one, or a once-verified lead as permanently valid.
The discipline that protects Indian outbound teams is simple: find anywhere, verify everything together, segment by confidence, and re-check before reuse. Your domain reputation is shared by every email you send, so the verification step belongs to the list, not to the tool that found it.
