How to find and verify B2B work email addresses without guessing.

The direct answer

Find a B2B work email only after the company and role are accepted and the person can be identified unambiguously. Submit either a canonical LinkedIn profile identity or the reviewed combination of first name, last name, and company domain to a bounded lookup tool. Preserve found, not_found, pending, and failed separately. Then test identity, address syntax, provider quality, mail-system acceptance, current employment, and permitted use as different questions. Never guess a pattern such as first.last@company.com and label it verified.

Leadbase's prospects.find_email capability accepts 1–50 identities per call and can be orchestrated repeatedly across a larger Sheet. A found work email currently consumes one credit under the contract reviewed on 9 August 2026; exact replay, not found, pending, and failed consume none. The key product advantage is the completed path: define and qualify the right accounts and roles, then let an agent make that people list reachable across thousands of rows. Identity, lookup state, quality, cost, and review remain attached as the control layer beneath that outcome.

1. Define “found,” “verified,” “deliverable,” and “usable” separately

Teams lose trust when one word covers four different claims.

Do not rename provider quality to “Leadbase verified.” Leadbase returns the provider-neutral quality field; your review decides whether it is sufficient for the intended action. Do not equate a syntactically valid address with a real mailbox. Do not equate a mail server accepting a message with inbox placement. Google explicitly says it does not track open rates and cannot verify third-party open-rate accuracy; sending outcomes and recipient engagement are separate measurements. Gmail sender guidelines

2. Start after account and role qualification

An available email does not make a person a good prospect. Before lookup, retain the accepted company, the reason it matches the ICP, the role hypothesis, evidence that this person currently holds a relevant role, and the approved next action. If those decisions are missing, email enrichment merely makes an unqualified list easier to contact.

Use a team gate:

1. account identity is resolved;
2. account passes the written ICP rule;
3. role family is relevant to a named business problem;
4. current evidence supports the person's employer and role;
5. a specific email use and owner exist; and
6. country, recipient type, suppression, and policy questions have an owner.

For building the company set first, use the ICP account-list Guide. For role evidence, use the buying-committee hypothesis Guide. This Guide begins only when a known person needs one work-email field.

The interactive planner estimates the lookup exposure when contacts are requested for every candidate account versus only qualified accounts. It uses your assumptions and is not a Leadbase coverage or saving claim.

3. Choose one canonical identity route per row

The current Leadbase email capability supports two identity shapes:

• a canonical https://www.linkedin.com/in/... profile URL, with corroborating name, company, domain, title, or country when already known; or
• person_at_company, containing first name, last name, and canonical company domain, with optional company, title, and country context.

Use LinkedIn as an identity key, not an instruction to crawl. Do not give an agent session cookies or ask it to bypass platform controls. If you use person-at-company, normalise the domain: remove protocol, path, tracking parameters, and email subdomain assumptions. Confirm that the domain belongs to the accepted operating entity rather than a parent, brand, reseller, or directory.

Never ask the model to choose between conflicting identities by intuition. If a profile says one employer and the company-domain evidence says another, mark the row identity_conflict. If two people share the name, require additional evidence. If the employer evidence is stale, hold the row. A smaller clean denominator is better than a high found rate built on wrong people.

4. Do not guess the mailbox pattern

Companies often use patterns such as first name, initials, or first-dot-last. Knowing a pattern can help investigate a result; it does not prove that a specific mailbox exists. Exceptions include duplicate names, aliases, preferred names, historical migrations, country subsidiaries, contractors, acquired domains, and role accounts.

A guessed address creates three risks:

• identity risk: the address can belong to another person with the same name;
• delivery risk: the mailbox may not exist even when the pattern is common; and
• governance risk: the team may record “verified” without evidence of what was checked.

Keep any observed company pattern in a separate pattern_hypothesis field, never in the accepted email field. Record where the pattern was observed, the domain and date, whether it came from the same legal or operating entity, and how many distinct current examples support it. Then compare a returned address with the hypothesis only as a review signal. A matching pattern can reveal a likely identity conflict when two people share a name; a non-matching pattern can reveal an alias, preferred name, acquired domain, or provider error. Neither result independently confirms or rejects the mailbox.

For every accepted email, the audit trail should answer: which exact person identity entered the lookup, which company domain was accepted at that time, which address the capability returned, what quality state came with it, which independent checks were performed, and who approved the intended next action. If any answer is missing, keep the row in review rather than promoting it through a spreadsheet formula.

If no lookup result is available, retain not_found and use the written fallback: investigate the identity, use a generic company route, choose another supported role, or stop. Never turn a no-result into a pattern-generated value merely to complete the column.

5. Preserve the complete lookup state

For each email request, retain:

The response preserves input order. Keep its index mapped to the source row. not_found means this configured lookup returned no address; it does not mean the person has no work email. failed is a terminal technical or unavailable outcome; it is not a no-result. pending must remain pending until polled or until the defined cutoff.

At the reviewed product contract, a found work email consumes one credit, including a new request served from cache. Exact replay, not found, pending, and failed consume none. Check the live capability and workspace policy before every material run because pricing and enablement can change.

6. Make retries idempotent

For every new ordered batch, create a fresh UUID or ULID. If a result is pending, wait for at least the returned retry interval and reuse the identical input and identical key. Do not change the people, order, or corroborating fields while polling. Do not create a new key for a pending batch unless you deliberately close the old operation and accept the risk of a new paid request under current rules.

For a larger Sheet, process eligible rows in deterministic order with at most 50 identities per capability call or the lower live workspace limit. A 5,000-person email queue therefore needs at least 100 new calls at the maximum payload. It can contain more transport calls when pending items are polled, but the logical batch lineage remains stable.

Stop when the credit ceiling, error threshold, or run cutoff is reached. Report unprocessed and pending rows. A workflow that silently retries until something returns can inflate cost and hide provider availability problems.

7. Review technical quality in layers

Email verification is not one test. Use a ladder:

1. Normalisation: lower-case domain, remove whitespace, preserve the returned local part exactly.
2. Syntax: confirm the address conforms to the accepted email-field policy; syntax alone proves no mailbox.
3. Domain: confirm the domain is the accepted company domain and has a plausible mail route.
4. Identity: compare person, employer, role, and evidence date.
5. Provider quality: retain verified, likely, or unknown without renaming it.
6. Delivery observation: record accepted, temporary failure, permanent failure, or not sent from your approved sending system.
7. Commercial acceptance: decide whether the row may enter the intended next action.

Do not use invasive mailbox probing that violates a provider's terms or creates unwanted messages. Use the signals lawfully available to your own systems. Mail servers can return temporary errors, filtering responses, or acceptance followed by later bounce; one observation is not an eternal fact.

For senders, list quality cannot compensate for poor infrastructure. Google's current requirements cover SPF or DKIM for all senders and SPF, DKIM, DMARC, alignment, low spam rates, and one-click unsubscribe for applicable senders over 5,000 messages per day to Gmail accounts. Those are sending requirements, not properties an email finder can satisfy. Gmail sender guidelines

8. Score a pilot with honest denominators

Start with 30–100 reviewed people across the countries, company sizes, and role families that matter. This is an operational calibration sample, not a universal statistical minimum. Freeze the identity and acceptance rules before lookup.

Calculate:

• returned coverage = found ÷ submitted;
• confirmed identity accuracy = correct ÷ (correct + incorrect);
• unresolved found share = (inconclusive + not reviewed) ÷ found;
• usable yield = accepted for the intended action ÷ submitted;
• permanent-failure rate = permanent delivery failures ÷ attempted sends; and
• cost per accepted work email = credits and review cost ÷ accepted results.

Do not remove no-results from usable yield. Do not publish confirmed accuracy without showing unresolved found results. Do not call a test successful solely because provider coverage is high; a high-coverage segment with wrong employer matches can be commercially worse than lower coverage with clean identity.

Download the work-email lookup and verification ledger. Its fictional rows preserve found, not found, pending, failed, incorrect identity, technical acceptance, policy hold, and accepted outcomes. Replace them with one frozen cohort.

9. Keep deliverability, permission, and relevance separate

An email can be deliverable and still be irrelevant or impermissible. The European Commission states that personal-data processing needs a specific purpose, must be limited to what is necessary, and must remain accurate for that purpose. It also describes information obligations when data is obtained from another organisation. European Commission: GDPR principles European Commission: information to provide

Rules depend on jurisdiction and recipient. The UK ICO distinguishes corporate from individual subscribers, says UK GDPR can apply to named business contacts, and requires identity and opt-out information for relevant B2B electronic marketing. Its guidance also notes that the legal-basis analysis is not automatic. ICO: business-to-business marketing

Maintain a separate policy field with country, subscriber or entity type where relevant, purpose, legal-review owner, transparency route, suppression result, objection date, retention rule, and permitted next action. This is not legal advice; obtain qualified review for your actual markets.

10. Use a decision table instead of one “verified” checkbox

This table protects against a common conversion mistake: treating a data product as valuable only when it fills the cell. A visible no-result can save sales from sending to a guessed address. An identity conflict caught before sending can be worth more than another found result. The product should make these decisions cheaper, not hide them.

11. Why Leadbase is a strong fit for this job

Leadbase is a strong fit when you want the same product that built and qualified the people list to make those people reachable with work email at scale.

The credible commercial story is not “Leadbase always has the most emails.” That would require a dated, segment-specific comparative test. It is this: Leadbase can carry one workflow from a target-market description through custom qualification to a work-email lookup across the resulting people list. A bulk email file answers only the final lookup question; it does not build the exact market and role logic that determined who belonged in the file.

The economic difference is clearest with false-positive results. A plausible but wrongly attributed address does not cost only one credit. It can create research time, irrelevant personalisation, a bounce, an incorrect CRM activity, and cleanup work for a sales rep. A visible not_found does not trigger that chain. The team can apply its written fallback, investigate another supported role, or close the account. Buyers should therefore compare more than the number of filled email cells. Compare how many source rows reach a traceable decision and how much human work is required per accepted result.

Make sure the sales handoff preserves that uncertainty. Do not pass only the address and person. Pass the account rationale, role evidence, evidence date, lookup quality, review state, permitted next action, and whether a sending test has occurred. The recipient should be able to understand why the person entered the queue and which claim remains unconfirmed without asking the researcher. That connection between research, contact data, and decision is the control layer beneath the Leadbase promise. It does not make every address true; it prevents an uncertain result from silently becoming a certain sales assumption.

Leadbase is not the right primary system when you require native CRM writeback, an email sequencer, inbox warm-up, consent management, a deliverability-monitoring platform, or a universal guarantee that every returned address is current and permitted. Use the appropriate sending, suppression, legal, and CRM systems around the reviewed Leadbase output.

12. Run a 30-row proof, then scale one variable at a time

For the first cohort, use people the team would genuinely want to contact if the field passes review. Include difficult cases: common names, subsidiary domains, recent role changes, non-English names, multiple country sites, and at least one deliberately ambiguous identity. Freeze the lookup date and review cutoff.

After the pilot, choose one outcome:

• Scale: usable yield and cost meet the written gate, unresolved share is tolerable, and no policy blocker remains.
• Revise: identity or domain quality causes avoidable holds; repair the input contract and rerun a new cohort.
• Segment: one country, company type, or identity route behaves materially differently; report it separately.
• Stop: the accepted yield does not justify cost or the intended use is not supportable.

When scaling from 30 to 5,000, keep definitions unchanged. Increase only queue size first. Do not simultaneously change provider settings, identity route, target market, acceptance rule, and sending system. Otherwise a better or worse outcome has no attributable cause.

13. Final checklist

• The account and role pass written qualification before email lookup.
• Each row uses one canonical identity route and stable row ID.
• No model or spreadsheet formula invents a missing mailbox.
• Found, provider quality, technical acceptance, and usable are separate states.
• Fifty identities is documented as a per-call payload, not a Sheet limit.
• Every new batch has a fresh UUID or ULID.
• Pending polling reuses the exact input and idempotency key.
• No-result, pending, and failed stay in the original denominator.
• Confirmed accuracy reports unresolved and not-reviewed results beside it.
• Sending infrastructure and delivery observations are measured separately.
• Country, recipient type, purpose, transparency, suppression, and retention have owners.
• Credit cost and human review time are included in cost per accepted result.
• The first pilot changes into a large run only after a written go/no-go decision.

The Leadbase capability contract and public sources in this Guide were reviewed on 9 August 2026. Recheck live capability descriptions, workspace policy, sending-provider rules, and legal guidance before a material run.