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

The direct answer

Find a B2B work email after the company and role are accepted and the person is identifiable. Give Leadbase the professional profile or the reviewed name, company and domain. Submit many independent questions together with enrichment_start, or research an email column across selected Sheet rows with sheets_enrich. Keep job progress, final email arrays, no-result, failure and settlement separate. Never guess a pattern such as first.last@company.com and label it verified.

Leadbase supports 1–100 independent research items per direct batch. One email question per person fits up to 100 people; requesting email and phone as separate items fits up to 50 people with both fields. Larger lists can use repeated batches or Sheet enrichment. A found-email contact action costs one credit; measured research usage can add costs even when no email is found. The advantage remains the completed path from your exact ICP and qualified roles to reachable people, with evidence, status and cost attached.

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.” The underlying contact action can supply provider quality; public research returns email arrays, summaries and sources rather than guaranteeing that field. Your review decides whether the observed evidence is sufficient. 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. Supply a clear identity for every person

Supply a canonical professional profile URL when known, or first name, last name, company and domain. Put these known facts in input and ask for the intended person's business email with output: {"type":"email"}. Leadbase can research missing identity context before the contact lookup; never invent a profile or treat two same-name people as interchangeable.

The underlying email action accepts a canonical LinkedIn identity or a person-at-company identity with first name, last name and company domain. These are internal lookup contracts, not the shape external MCP clients must submit. Use the public bulk research contract or Sheet enrichment.

Use a profile URL as an identity clue, not permission to bypass platform controls. Confirm that the domain belongs to the intended operating entity. If current employer or profile evidence conflicts, hold the row for review instead of silently choosing a different person.

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 evidence was actually available, 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 progress, results and settlement

Use the returned IDs to retain the mapping to each source row. Queued or running jobs remain unresolved. A completed empty email result is not a delivered contact; a failed job is not a no-result. Pending billing is not a zero charge.

The public email result is an array with job evidence. The underlying contact action may also have a provider quality label, but the public research result does not promise that metadata. Preserve it only when observed; do not invent verified from the presence of an address.

A found-email contact action currently costs one credit, including a new request served from cache. A no-result or failed contact action has no contact-result charge, but identity research, AI and web usage can still be billable. Reconcile the whole job's actual settlement before reporting cost per accepted email.

6. Submit once and read the existing jobs

Use enrichment_start with a stable idempotencyKey and 1–100 items. Each item has its own id, known scalar facts in input, a specific question, and output: {"type":"email"}. Keep the returned batchId and job IDs. Read progress with enrichment_get({"batchId":"BATCH_ID_FROM_START"}); do not submit the input again to poll.

For an existing Sheet, use sheets_enrich with the Sheet, existing email column and eligible rowIds, or define a new email research column. Use sheets_get_enrichment_status and sheets_query to read progress and saved values. Leadbase owns cell admission and dispatch.

With one email item per person, 5,000 eligible people need at least 50 direct submissions of up to 100 items. Separate email and phone questions need two items per person. Sheet enrichment can manage the selected rows without making the client submit one request per person.

If submission was interrupted, reuse the original key and unchanged input to recover its identity. Once the IDs are known, poll the read operation. Never create a new key to escape an uncertain paid submission. Stop adding work at the agreed credit, time or error threshold and report unfinished jobs and pending billing.

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, when observed: retain verified, likely, or unknown without renaming it; leave absent metadata unknown.
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 retain batch/item/job identities, public job and billing states, and separate contact-action and research charges. lookup_status maps these to review categories: found, not found, pending and failed. The sample also preserves incorrect identity, technical acceptance, policy hold and accepted outcomes. Blank credits mean unresolved or unobserved amounts, not zero. 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.

Leadbase takes your team from a target-market description through custom qualification to work emails across the resulting people list. You research the account fit, find the relevant roles and add contact details in one workspace. The address stays connected to the reason that person belongs on your list.

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.

Give sales more than an address: include the account rationale, role evidence, lookup quality and any review still needed before sending. Your team can start with the context already available in the Sheet. Review uncertain results and complete your normal sending and permission checks before outreach.

Use Leadbase to build and enrich the qualified people list, then export the results into your existing sending workflow. Keep delivery monitoring, suppression and campaign permissions in that workflow. Find work emails for your target contacts.

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.
• Direct batches contain up to 100 independent items; Sheet enrichment manages selected rows.
• Each new submission has a stable key and each person/field a stable item ID.
• Progress is read by batch/job ID; interrupted submissions reuse unchanged input and their original 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 product workflow was checked on 20 October 2026. Recheck current research schemas, workspace policy, sending-provider rules and legal guidance before a material run. External policy sources require their own review.