How to Find Someone's Work Email for B2B Outreach

How to find someone's work email starts with resolving the right professional identity. You need to know who the person is, find a work address only when one is available, and read the deliverability result before that address reaches an outreach workflow.

This is a workflow for professional contact data from public sources. It does not treat personal contact details as part of the process.

What “finding a work email” actually involves

Finding a work email is a sequence of identity resolution, work-email discovery, and deliverability checking.

These steps solve different problems:

• Contact identity resolution determines whether the record represents the professional you intended to find.
• Work email enrichment looks for a professional work address associated with that resolved person.
• Email deliverability probes a returned address and attaches an email status for operational use.

Treating these as separate steps prevents a common data problem: attaching a plausible email address to the wrong person.

The identity signal you provide matters. A company name, company domain, LinkedIn URL, or a name plus employer gives the enrichment process more context about the intended person. The company domain is especially useful when an employer has a common name, a parent company, or several similarly named business units.

The target is a professional work address found from public sources. Personal contact details are not part of the field catalogue. That boundary keeps the workflow focused on the information your team needs for a professional conversation.

An email result is also not the same thing as permission to contact someone. Finding an address supports contact research. Your outreach process still needs appropriate permission handling, suppression rules, and regional review.

Start with the strongest identity signals

Use a LinkedIn profile URL when you have it, because it is a person-level identifier rather than a text description.

A name can refer to many people. A job title can change. An employer name may be written in several ways. A LinkedIn URL gives the enrichment request a specific profile to resolve, which reduces ambiguity before any work email lookup begins.

When you do not have a profile URL, use a name plus employer. Add the employer domain when your system has it. This creates a stronger identity record than a name alone:

• Name plus employer distinguishes people with the same name.
• Company domain ties the employer to a specific organization.
• Current title can provide useful context, but should not be your only matching signal.
• Location can help narrow a match, but published location is free text and may be incomplete.

A record can still become stale. Someone may have changed roles, left an employer, or updated their public profile after your CRM last changed. A former employer attached to a current title can point to the wrong person. So can a location field that only names a country, region, or city.

Build your input record around the identifiers you know are current. If you have a LinkedIn URL, prefer it. If you have a name and employer, preserve both. If you know the employer domain, retain that as well.

This is less about collecting every possible field and more about preserving the fields that establish professional identity.

Use enrichment rather than guessing an address pattern when learning how to find someone's work email

Use enrichment for known person identifiers instead of treating a guessed email format as a confirmed address.

Address patterns can be useful internal context, but they do not prove that a particular mailbox exists or belongs to the intended person. An organization may use multiple formats. A person may use a different name at work. The mailbox may have changed, been removed, or never existed.

A plausible address is still only a guess until it is found and checked.

With Enrichments, you enrich people using identifiers you already hold: a LinkedIn URL, an email address, or a name plus employer. Request the email field explicitly when you need a work address. If a work email is found, it is returned with the result. If it is not found, you do not receive a fabricated address.

The distinction between search and enrichment matters:

• People search finds professionals matching an ideal-customer-profile description, such as titles, departments, seniority, location, or employer context.
• People enrichment resolves identities you already hold into person records.
• Email lookup occurs when you explicitly request the email field during enrichment.

This separation is useful in a GTM pipeline. Search helps you build a relevant set of professionals. Enrichment turns known identifiers into usable records. Email discovery is a requested data field, not an assumption applied to every search result.

The email field is not part of the default field set. Ask for it by name when your workflow needs it.

For a systems workflow, API enrichment accepts batches of identity records. An enrichment call returns one result wrapper per input, in input order. Each wrapper separates the processing state from the resolved record:

{
  "job": {
    "object": "job",
    "id": "job_id",
    "type": "people_enrich",
    "status": "succeeded"
  },
  "results": [
    {
      "position": 0,
      "status": "succeeded",
      "data": {
        "email": "name@company_domain"
      },
      "evidence": null,
      "error": null
    }
  ],
  "page": null,
  "estimatedCredits": null
}

Your application should read the person data from results[].data, not from the wrapper itself. It should also account for item-level outcomes such as not_found or failed instead of assuming every input produces a resolved email.

Check deliverability before an address enters outreach

An address should be probed and returned with an email status before it enters an operational outreach list.

Email deliverability is part of the enrichment run for returned work emails. The status is a useful control field. It tells your system how the address was classified at the time it was checked, rather than making a permanent claim about the mailbox.

Use the available email statuses as workflow states:

Email status	Practical handling
verified	Treat as the strongest available deliverability outcome. Keep the status and enrichment date with the record.
probable	Do not treat as equivalent to verified. Route according to your review policy.
unverified	The result does not provide a conclusive deliverability outcome. Avoid assuming the mailbox is usable.
risky	Keep out of automated sequences unless your process explicitly reviews and approves it.
undeliverable	Exclude from outreach use.
unknown	Do not infer deliverability from the absence of a clear result. Send to review or exclude from automation.

The status does not replace normal list hygiene. People change employers. Organizations retire mailboxes. A status describes the address when it was checked, not a guarantee about a future send.

A practical routing model is simple:

• Allow verified records into the next approved outreach step.
• Put probable, unverified, risky, and unknown records into a review queue or exclude them from automated sequences.
• Suppress undeliverable records.
• Retain the original identity inputs so your team can revisit a record if it needs investigation.

Do not apply phone-style logic to email, or email-style logic to phone. A mobile number, if returned through the phone field, has no deliverability verdict. It is not a verified phone number, and its availability is not advice that it is lawful to call.

Choose a workflow for one contact or a list

Choose the surface that fits where your identity records already live.

For an individual research task or a small set of contacts, the in-product chat agent lets you describe the work in plain language. It plans the run, shows what it is about to spend, and returns a table you can export. This is useful when the starting point is a research brief rather than a prepared file or an existing system record.

For a list, use CSV upload. You can upload identity columns, map them to the records you have, choose the returned fields, preview the cost, and download the enriched file. This works well when your team has a campaign list, event list, account list, or CRM export that needs structured enrichment before it moves elsewhere.

For a product or data pipeline, use the REST API. It is the right path when your application already holds LinkedIn URLs, emails, or name-and-employer identifiers.

A small enrichment can return inline. Larger enrichments, any enrichment requesting the email field, and requests sent with asynchronous preferences are queued as jobs. When queued, results is null until the job reaches a terminal job.status. Poll GET /api/v1/jobs/{id} and read job.status, which can be queued, running, succeeded, empty, failed, or cancelled.

If your client retries a request, send the same Idempotency-Key header. That makes the retry deduplicated. Without that header, a retry is a new request with a new job.

The same API key also works with the MCP server at /api/mcp if your agent environment uses tool calls. The MCP enrich_people tool accepts known person identifiers and can return work emails when you request fields: ["email"].

See the available integration paths in the docs and the plan allowances on pricing.

Keep the resulting contact data useful and responsible

Store the identity evidence, email status, and enrichment date alongside every returned work email.

A usable professional contact record should retain enough context for someone else on your team to understand where it came from. At minimum, keep:

• The identifier used for enrichment, such as a LinkedIn URL or name plus employer.
• The returned work email.
• The returned email status.
• The enrichment date.
• The employer name and company domain associated with the record.
• Any suppression or outreach eligibility state maintained by your own systems.

This makes later review possible. If a contact disputes the relevance of a message, if a record changes employers, or if a mailbox becomes undeliverable, your team can trace the record back to the professional identity used to resolve it.

Apply B2B outreach compliance before you contact anyone. That includes your own permission rules, suppression lists, and the regional rules that apply to your outreach. A work email from public sources is data for a workflow. It is not a blanket authorization to send messages.

Re-enrich important records when their role or employer changes. Enrichment is live rather than a licensed static database, so the same query can legitimately return different data later. That is useful when a professional record changes, but it also means you should treat enrichment as a dated observation.

The goal is not to accumulate addresses. It is to maintain a clear, current record of professional identity, work email enrichment, email deliverability, and the rules that govern whether your team should use the result.