How to Find Work Emails from a Name and Company Domain

You have a list of names and the companies they work at, and you need their work emails. The manual approach — guessing first.last@, trying it, watching it bounce — doesn’t scale past a handful of prospects. Most “email finder” APIs that do scale come with API keys, monthly quotas, and rate limits that stall a big list halfway through. This guide covers a different approach: rank the common corporate email patterns by real-world frequency, validate the domain over DNS, and do it with no keys and no ban risk.

What you get per person

This finder takes a full name and a company domain and returns a structured, ranked result. The fields:

• mostLikelyEmail — the single top-ranked guess, built on a domain that actually accepts mail.
• confidence — a 0–100 score for that top guess, combining how common the pattern is in the wild with the domain’s validity.
• candidates — the full ranked set of alternatives, each with its pattern (e.g. first.last, first, flast, firstlast), its email, and a probability. Twelve common patterns are scored, so if the top guess bounces you have the next-best formats ready.
• status — a clean classification of the domain: deliverable_domain, risky_domain, invalid_domain, personal_domain, or invalid_input.
• domainHasMx / mxHost — whether the domain has mail-exchange records, and its primary mail server hostname.
• fullName, firstName, lastName, domain — the parsed input, echoed back so every output row is self-contained.

The status field is doing real work here. It separates a corporate domain that can receive mail (deliverable_domain) from a free provider like Gmail or Outlook (personal_domain, where name patterns simply don’t apply) and from a domain that doesn’t resolve at all (invalid_domain). You never waste an outreach send on a dead domain.

How pattern-ranking actually works

Corporate email conventions are not random. A large share of companies standardize on one of a small set of formats — first.last, flast, first, firstlast, and a handful more. The trick is that these patterns have very different real-world frequencies: first.last is far more common than, say, f.last. So the smart guess isn’t “try them alphabetically” — it’s “try them in order of how often companies actually use them.”

That’s what the confidence score encodes. For a name like Marques Brownlee at mkbhd.com, first.last ([email protected]) ranks highest, followed by first (marques@), then flast (mbrownlee@). Each candidate carries its own probability so you can decide how many to try.

The second half of the method is DNS validation. Before ranking is worth anything, the finder does an MX lookup on the domain to confirm it can receive mail at all, and records the primary mxHost. This is pure DNS — no scraping, no headless browser, no page loads. That’s why it’s fast, deterministic, and immune to the failure modes that plague scraping-based tools.

Input: bulk in, bulk out

The simplest input is one person per line as "Full Name, company-domain.com":

Marques Brownlee, mkbhd.com
Tim Cook, apple.com
Sarah Johnson, stripe.com

You can also pipe in objects from another actor — pass firstName / lastName / fullName plus domain, and the finder handles them the same way. That makes it a natural second stage after a company or LinkedIn scraper: the upstream actor produces name-and-company rows, this one appends the email column.

▶ Run the Work Email Finder on Apify — feed names + company domains, get the most likely work email plus ranked alternatives, each MX-validated. No API key, no rate limits. Bulk CSV / Excel / JSON in and out.

The access reality: why no rate limits

Most email-finding tools break at scale for one of two reasons, and this approach sidesteps both.

• It’s pure DNS, not scraping. There are no proxies to rotate, no anti-bot walls to clear, no “try again later” throttling. Feed 10 names or 10,000 — every row comes back, because a DNS MX lookup is cheap and no one rate-limits it the way they rate-limit a scraper. Lookups run in parallel for high throughput.
• It deliberately does not do SMTP mailbox probing. This is the honest part. A “does this exact mailbox exist” check requires opening an SMTP conversation with the mail server, and cloud providers block outbound SMTP from their infrastructure and blacklist IPs that attempt it. So this finder intentionally skips it. It gives you the most likely address and confirms the domain accepts mail — it does not claim to have verified the individual inbox.

That trade-off is the whole design. You get a deterministic, ban-free result for every input, instead of a slower “verified” tool that gets its IPs blacklisted and stalls.

Example output

One representative record:

{
  "fullName": "Marques Brownlee",
  "domain": "mkbhd.com",
  "mostLikelyEmail": "[email protected]",
  "confidence": 33,
  "status": "deliverable_domain",
  "domainHasMx": true,
  "mxHost": "aspmx.l.google.com",
  "candidates": [
    { "pattern": "first.last", "email": "[email protected]", "probability": 33 },
    { "pattern": "first", "email": "[email protected]", "probability": 19 },
    { "pattern": "flast", "email": "[email protected]", "probability": 14 }
  ]
}

Note the confidence of 33 on the top guess — this is honest scoring, not false certainty. The most common single pattern still only accounts for about a third of companies, which is exactly why the candidates array matters: keep the top two or three formats on hand.

Typical use cases

• Cold email & sales prospecting — convert a list of prospects (name + company) into reachable inboxes for outreach.
• Recruiting — reach candidates and hiring managers directly instead of routing through a careers portal.
• Lead enrichment — append a probable email column, with a confidence estimate, to any name-and-company dataset you already have.
• Event & partnership outreach — go from a conference speaker or exhibitor roster to a contact list.

The pattern that ties these together is chaining: company scraper → this finder → email verifier → outreach. The finder sits in the middle, turning names into candidate addresses cheaply and at any volume.

Cost / effort math

Building this yourself is deceptively involved. The DNS layer is easy; the hard parts are (1) compiling and maintaining an accurate, frequency-weighted table of corporate email patterns, and (2) resisting the temptation to add SMTP verification that will get your sending IPs blacklisted. Get either wrong and your “finder” either guesses badly or bans itself.

The managed actor runs pay-per-result — you pay per person processed, a fraction of a cent per row, with no key and no quota. Because there are no proxies or browsers involved, the compute cost is minimal and large lists run start to finish without babysitting. For a list of a few thousand prospects, you’re spending single-digit dollars and getting a deterministic result for every row.

Pitfalls and honest limits

• This is a candidate, not a guarantee. mostLikelyEmail is the statistically most likely format on a mail-accepting domain — the same approach every lead tool uses. It is not proof the mailbox exists. Treat confidence as a probability, not a promise.
• Free providers can’t be pattern-guessed. Gmail, Outlook, Yahoo and the like don’t follow corporate naming, so a personal_domain status means there’s no pattern to apply. That’s flagged, not failed.
• Run a verifier before you send. For a real deliverability pass — catching role accounts (info@, sales@), disposable domains, and syntax issues — chain the output into a bulk email verifier. This finder deliberately doesn’t do the SMTP-level check, so pair it with one that does.
• Names with prefixes/suffixes need clean input. Titles, middle names, and accented characters can shift which pattern wins. Feed clean First Last where you can.
• A missing MX means no result, correctly. If a domain has no mail server or doesn’t exist, you get an invalid_domain status rather than a fabricated guess. That’s the tool refusing to lie to you.

Wrapping up

Finding work emails at scale comes down to two things done well: ranking the common corporate patterns by how often they’re actually used, and validating that the domain can receive mail — both without touching SMTP and getting your IPs blacklisted. The result is deterministic, ban-free, and runs at any volume. Use it as the enrichment stage between your company data and your outreach, and put a verifier after it before you hit send.

▶ Open the Work Email Finder on Apify — one run turns a list of names + domains into ranked, MX-validated work emails with confidence scores. No API key, no rate limits, deterministic every time. Bulk CSV / Excel / JSON export. Start on Apify’s free monthly credit.