Email verification statuses: what RevOps should accept, review or reject

This guide translates email verification status meaning into a practical RevOps policy: what to accept, what to review and what to reject. The decision framework and financial example below are proposed methods, not measured TargetWise performance.

Read three separate signals, not one green badge

A record can contain an email without establishing that its mailbox exists. A mailbox can work without belonging to the buyer you intended to reach. A correctly matched buyer can still be unsuitable for a particular campaign.

Keep these questions separate:

• Was an address found? The enrichment operation returned a candidate value.
• What was verified? A provider checked particular properties of that address, using its own method and definitions.
• Is this record usable here? Your organisation accepts its identity, freshness, suppression and workflow conditions.

Hunter’s API, for example, exposes detailed verification status separately from a score and source observations. Its documentation warns that an accept-all SMTP response can produce false positives. This is why a single Boolean such as email_verified=true loses useful information. Source: Hunter API reference.

Email verification statuses: a decision table

The definitions below synthesise the providers’ documentation. The actions are our recommended conservative starting policy for named-person enterprise prospecting—not a universal provider standard. Hunter, MailerCheck and Snov.io use different labels and groupings. Preserve each original label alongside your normalised state. Hunter statuses; MailerCheck statuses; Snov.io statuses.

An important example of naming ambiguity: “blocked” need not mean the same thing everywhere. Hunter discusses blocked verification attempts; MailerCheck separately describes a mailbox blocked by its service provider. Mapping both to “invalid person” would be a category error.

What is a catch-all email?

A catch-all email domain accepts—or appears to accept—messages addressed to recipients regardless of whether the specific mailbox has been established. The meaningful uncertainty is not whether the company owns its domain. It is whether the address identifies a real, current recipient.

MailerCheck explicitly separates server acceptance from confidence that an address belongs to a person. Hunter likewise explains why accept-all behaviour prevents ordinary checks from establishing deliverability of the individual address. MailerCheck’s definition; Hunter’s explanation.

Consider a fictional contact, Alex Reed, at example.com. A provider returns a plausible address and a catch-all result. You have a candidate, not evidence that Alex’s mailbox exists. A second provider returning the same string does not resolve this if it merely applied the same naming pattern.

Do not reject every company with catch-all settings. Keep the account and person research, but separate the uncertain email from accepted contact coverage. An account can remain strategically important while one communication channel remains unresolved.

What does “extrapolated” mean in an email verification status?

The meaning of an extrapolated email verification status depends on the originating provider’s definition. Inspect that definition before mapping the result into your CRM. Do not assume that the word represents a standard mailbox-verification result shared by all vendors.

Where a provider uses “extrapolated” to mean an address inferred from a naming pattern or other records, classify that as inference evidence, not as a completed mailbox check. If its documented meaning is unavailable, retain the raw label and mark your normalised verification state unknown.

Ask the provider: Was this particular address tested? What was tested? When? Was the domain catch-all? Is the confidence attached to the identity match, the address prediction or the mailbox? A high confidence score for one question does not answer the others.

This article does not assign an undocumented definition to any named vendor. The practical rule is narrower: no field should become “verified” merely because an integration translated an unfamiliar label into a positive value.

Keep retrieval, source observation and verification dates apart

Store a retrieval timestamp for when your system received the response. Where available, also store the source observation date, mailbox verification date and employment observation date. Leave unavailable dates empty rather than substituting today’s date.

TargetWise’s documentation makes this distinction for grounding.retrieved_at: it describes retrieval, not a promise that every field was refreshed at that moment. Its documented matched, partial and not_found outcomes also describe retrieval results, not a universal SMTP verdict. These are documented capabilities, not independent test results. TargetWise developer documentation.

Choose freshness limits by the consequence of error. An upcoming executive meeting, a long-dormant CRM record and a newly submitted inbound enquiry need not have identical review rules. Record the policy and its owner; do not present an arbitrary number of days as an industry guarantee.

Build the acceptance rules before choosing the next supplier. Use TargetWise’s benchmark workflow to define a sample and measure returned fields, latency and errors alongside your own identity and verification checks.

A worked example: 80% found becomes 47% usable

Hypothetical data. This is arithmetic, not a vendor benchmark, deliverability forecast or customer result. Suppose you submit 1,000 unique, eligible CRM records after removing existing duplicates. Your policy requires a matched current person and employer, accepted mailbox evidence, no unresolved conflict and no suppression.

Each exclusion applies only to records remaining at that stage. An address marked both stale and suppressed is not subtracted twice. Although the input CRM records were unique, enrichment can reveal that two records represent the same person—hence the second deduplication check.

• Found coverage: 800 ÷ 1,000 = 80%.
• Policy-usable coverage: 470 ÷ 1,000 = 47%.
• Accepted share of returned records: 470 ÷ 800 = 58.75%.

Now assume the actual invoiced enrichment cost is £160, verification costs £24 and allocated operating effort costs £96. Total cost is £280. That is £0.35 per found address but approximately £0.60 per policy-usable contact. Neither figure establishes match accuracy: that requires checking accepted matches against a defensible reference.

Suppose an optional extra waterfall step costs another £30 and produces 50 addresses, only 10 of which pass the same policy. Its incremental cost is £3 per additional usable contact. Evaluate that incremental figure against the value of the missing coverage. Do not justify the extra step using the blended average from earlier, easier matches.

Set waterfall stop conditions at field level

Our proposed operating rule is: stop an email lookup when an acceptable email is obtained, not simply when a provider returns a non-empty string. But continuing indefinitely is not evidence gathering; it is uncontrolled spend.

1. Validate identity inputs. Use a stable person identifier or sufficient name-and-company context. Quarantine ambiguous candidates.
2. Request only missing fields. An accepted email does not require another email search merely because a phone is missing.
3. Preserve the source result. Store the provider, original status, dates and reason before normalising it.
4. Apply explicit acceptance rules. Separate mailbox evidence, employment match, duplicates and suppression.
5. Continue only for a defined purpose. A different address, an independent check or stronger identity evidence may justify another step. A duplicate answer without new evidence may not.
6. Stop on budget or latency limits. Return unresolved fields and reasons. Never promote an uncertain record to accepted to complete a batch.

When two providers disagree, compare identifiers, methods and dates. Do not average incompatible confidence scores or count providers as independent votes without checking their sourcing. Preserve the stronger existing CRM field until the conflict is resolved.

A missing phone should remain missing. An unverified number should not be labelled a verified mobile simply because the email passed its checks. Each field needs its own evidence and acceptance rule.

Implement a status policy without damaging the CRM

Use an immutable internal CRM record ID as the write target. Do not let a newly returned email silently choose which person record gets overwritten. Keep proposed updates separate from committed updates, and check that a salesperson has not changed the record since enrichment began.

The following fields are an illustrative internal data model, not a TargetWise API response:

API errors belong in a separate operational state. An authentication failure means the request was not authorised; it does not mean the mailbox is invalid. A timeout does not prove no contact exists. Use bounded retries with backoff for retryable failures, respect provider instructions and reuse your own job identifier to avoid duplicate downstream writes.

Hunter’s verifier documentation distinguishes verification still in progress from remote-server failure and invalid input. This illustrates why the integration must inspect the actual response contract rather than treat every non-success as “not found”. Hunter verifier errors.

Why agent workflows need the same controls

On 11 September 2026, ZoomInfo announced its MCP server’s listing on Cursor’s marketplace. On 24 August 2026, it announced updated MCP availability on Salesforce’s AgentExchange. These are vendor announcements about access and integration—not independent proof of any contact’s accuracy. 11 September announcement; 24 August announcement.

The implication for RevOps is practical: place acceptance rules in the application or workflow service, not only in an agent prompt. An agent may request a lookup and explain the result, but should not turn “unknown” into “verified”, guess missing addresses, override a suppression or enrol a person without the required approval.

TargetWise documents REST and MCP retrieval for contact and company data. Use its returned context as evidence to inspect, not as permission for an agent to invent missing facts. Keep mailbox checking and CRM-write permissions explicit in the surrounding workflow. TargetWise API reference; MCP documentation.

Limits: what a verification status cannot promise

Verification is not guaranteed inbox delivery. Gmail’s sender guidance separately covers authentication, sender behaviour and other delivery requirements. A valid recipient address does not remove those conditions. Google’s sender guidelines.

Nor does a company record verify a personal contact, a successful SMTP interaction establish consent, or a retrieval timestamp prove current employment. Keep your organisation’s legal and permission checks separate; this guide defines a data-operating policy, not legal advice.

Before rollout, evaluate an authorised, representative sample across the countries, roles and company sizes you actually target. Fix definitions before comparing suppliers. Record missingness, source conflicts, verification availability, p50/p95 latency, errors, integration effort and cost per accepted unique record. Review false matches, not just missing fields.

Frequently asked questions

Evaluate the records your team actually needs. Discuss an enterprise enrichment evaluation with TargetWise, using agreed acceptance rules and a defined sample rather than headline match rates.