Email Addresses Finder

A name and a domain in,
an address and its status out.

Give it John Doe company.com and it builds the common corporate patterns, looks up the domain's mail server and asks it about each one. You get the address back with the thing that matters most: how it was arrived at, and whether anything actually confirmed it.

one-time 500 free rows$0.002 per row after10 columnsCSV · XLSX · JSON
How it works

Two things per line,
and nothing else to set.

A person and the company they work at. The tool does the pattern-building, the DNS lookup and the mail-server check; you read the status column.

  1. STEP 1Sign in to the platform.
  2. STEP 2Open the Email Addresses Finder.
  3. STEP 3Paste your lines as full name, then company domain - John Doe company.com - one per line, or upload a CSV, XLSX, TXT or Parquet file.
  4. STEP 4Choose your output format.
  5. STEP 5Click Get Data.
  6. STEP 6Sort by status before you do anything with the email column.

There is no limit control on this form. The MX lookup runs as DNS over HTTPS through our proxy pool, never from your real IP, and so does the SMTP probe.

Why teams use it

It tells you
how sure it is.

A status, not just a string

Most tools hand you an address and leave you to guess how much to trust it. Every row here carries a status and a plain-English status_details sentence saying what happened - published address found, mailbox accepted, catch-all domain, unconfirmed guess. That is the column you act on.

The pattern is on the row

pattern names the shape the address was built from - first.last, flast, first - or web when it was found published rather than constructed. Once you learn a company's house style from one confirmed row, the rest of that domain becomes far easier to read.

The mail server is asked, not assumed

The domain's MX record is resolved and each candidate is probed over SMTP, so the answer reflects what that server said at that moment rather than a row in a stale database. It also means the same input can answer differently on a different day - which is honest, if occasionally inconvenient.

What you get back

Ten columns,
and one of them decides the rest.

A name, a domain, the address that was arrived at, the pattern behind it, and - the part that matters - how far the check actually got.

One thing about this export matters more than everything else, so it goes first. The email column is not, on its own, an answer. Six values occur in status across our runs: found, deliverable, risky, guess, not_found and invalid. Only the first two mean something confirmed it - an address published on the web, or a mailbox the mail server accepted. risky means the domain is catch-all and would accept any address you invented. guess means the server never confirmed. If you export the email column and mail it without filtering on status, you are mailing constructions.

That leads to the second thing, which is a trap in the shape of the file rather than in a value. deliverable and catch_all are true or empty - never false. An empty cell means the check did not confirm it, not that the answer was no. Load that column into a boolean and blank silently becomes false, which reads as "this address is undeliverable" when what actually happened is "nobody said". Read the pair alongside status, not instead of it.

And a structural one worth knowing before you plan a run. One input line does not always produce one row. When a single address is confirmed or found published, you get one row for that person. When nothing confirms, the tool returns a row per candidate pattern instead - the same ladder in the same order every time, from first.last down to last - with position numbering them. That is useful, because it hands you every plausible address rather than picking one badly. It also means a row is not the same thing as a person, and billing is per row.

Data dictionary

Ten columns in the file,
eleven in the JSON.

The export's header row, in order. Where a field is described as sometimes empty below, that is a real state of the check - not a gap in the scrape.

query
The line you submitted, echoed with its original capitalisation and repeated on every row it produced - John Doe company.com and the like.
full_name
The person's name as it was parsed out of the line. Lowercased, whatever case you typed. Empty when the line held no name - passing a bare email address is one way to land there.
domain
The company domain parsed out of the line. Empty when the line could not be read as a name plus a domain, which is what an invalid row means.
email
The address arrived at. Read status before you use it. Depending on that column this is either an address something confirmed, or a construction nothing did. Empty on an invalid row.
pattern
How the address was built: first.last, firstlast, flast, firstl, first_last, first-last, last.first, lastfirst, f.last, first or last - or web, which means it was not built at all but found published. Empty on an invalid row.
status
The column the row turns on. found - a real published address. deliverable - the mail server accepted the mailbox. risky - a catch-all domain that accepts anything, so acceptance proves nothing. guess - a candidate the server did not confirm. not_found - no common pattern was accepted. invalid - the line could not be parsed.
status_details
A plain sentence explaining that status, meant to be read rather than matched: Catch-all domain - accepts any address; candidate pattern. When a published address was found it also says how many sources carried it.
deliverable
true where something confirmed the address. Otherwise empty - never false. Blank means unconfirmed, not undeliverable; do not cast this column to a boolean and read the blank as no.
catch_all
true where the domain accepts any address, which makes an SMTP acceptance meaningless. Otherwise empty - never false, with the same warning as above.
mx_host
The mail exchanger the domain resolved to - smtp.google.com, an Outlook mail.protection.outlook.com host, and so on. Useful for spotting which provider a company is on. Sometimes empty, including on rows where an address was found published.
position
1-based index within the query. On a single-answer row it is 1; on a candidate ladder it numbers the patterns in the order they were tried. JSON only - the CSV and XLSX exports stop at ten columns.

The one thing to know before you build on this: email without status is not a result. Only found and deliverable rows had something confirm them; risky means the domain would have accepted anything, and guess means nobody answered. The second trap is quieter: deliverable and catch_all hold true or nothing at all, never false, so an empty cell means unconfirmed rather than no. Beyond that: full_name is lowercased, mx_host is sometimes empty even on a good row, an unconfirmed lookup returns a row per candidate pattern rather than a single row, and position exists only in the JSON - so a CSV or XLSX export has ten columns rather than eleven.

What it accepts

A person,
and where they work.

One line per lookup, and it needs both halves. A company name on its own will not do, and neither will an email address - those come back as invalid.

John Doe company.com John company.com Full name + company domain Paste one per line CSV · XLSX · TXT · Parquet upload No limit control on this form MX over DNS-over-HTTPS, then SMTP Never your real IP
Common workflows

Three jobs people
most often run here.

A few examples of what a name and a domain are worth once the guessing is done in the open.

Outreach

Turn a list of names into a list you can mail

You have people and companies from a conference list or a CRM export, and no addresses. Run the pairs through, keep the found and deliverable rows for sending, and hold the rest back rather than burning your domain reputation on constructions.

Sales · Marketing
House style

Learn how one company formats addresses

Run a person you already have a confirmed address for and read the pattern column. Once you know a domain writes f.last, every other name at that company becomes a much shorter question - and the candidate ladder shows you the alternatives when it does not.

Research · Enrichment
Data hygiene

Find out which domains are catch-all

A risky status with catch_all set tells you the domain accepts anything, so no verification tool can ever prove an address there. Knowing which of your accounts are catch-all stops you trusting a green tick that does not mean what it looks like.

Ops · Deliverability
Pricing

Pay only for the rows
you actually pull.

No subscription, no minimum, no recurring bill. Your first 500 rows are on us - after that, pay-as-you-go at the same flat rate as every other scraper here.

Free tier

500 free rows - $0

Every new account, one-time. No credit card required. File upload and every export format included.

$0 forever
Pay-as-you-go

$0.002 per row, after the free tier

The same flat rate as every other scraper on the platform. Worth remembering here: an unconfirmed lookup returns a row per candidate pattern rather than one row, so a row is not the same thing as a person. The pre-flight estimator shows the cost before a run starts.

Most popular
Volume

Custom · high volume

Volume pricing, dedicated workers and an SLA for running large name-and-domain lists on a schedule. Tell us your numbers and we will quote.

Talk to us
10% off your first paid run.Use code LIVESCRAPER10 at checkout.
Sign up
Pairs well with

The steps either side
of this one.

This tool answers one question: what is this person's address at this company. These three answer the ones around it.

The legal bit

Is it legal to look up
someone's work address?

Short answer: the lookup is ordinary, what you do next is regulated - and unlike most tools here, this one produces personal data by design rather than as a side effect.

Start with what actually happens, because it is not quite scraping. Only the found rows come from an address published somewhere on the web. The rest are constructed: the tool builds the common corporate patterns from the name you supplied, resolves the domain's MX record over DNS-over-HTTPS through our proxy pool rather than from your real IP, and asks that mail server over SMTP whether each candidate exists. No account is accessed, no login is used, no paywall is crossed and nothing is read from inside anyone's mail. But we are not going to describe this as public-data collection, because for most rows it is not.

A named person's work email address is personal data under the GDPR and the UK GDPR, and running this makes you the controller of it. Because the data did not come from the person themselves, Article 14 applies: you need a lawful basis - legitimate interests is the usual one for B2B prospecting, and it needs an assessment rather than an assumption - and you have to tell the person you hold their details and where they came from, normally in your first message. The right to object and the right to erasure follow, and "it is a work address" does not exempt you from any of that. Some jurisdictions are stricter still with sole traders and small partnerships, whose business contact details are simply personal details.

Sending is governed separately from finding. The ePrivacy rules and PECR in the UK, CAN-SPAM in the US and equivalents elsewhere set what you may send unsolicited, to whom, and what an opt-out must look like - and none of that is affected by how you obtained the address. One practical note that follows from the export itself: a risky or guess row is a construction nobody confirmed, so mailing it is both a deliverability problem and a way of contacting people who may not exist. Filter on status first. We run no third-party trackers on the data layer, and your exports auto-delete after 30 days.

livescraper.app · principles
Candidates built from a name and a domain
MX and SMTP checks - no logins, no mailboxes read
Never your real IP
A work address is personal data - you are the controller!
Exports auto-delete (30 days)
Filter on status before you send anything.
Common questions

Things people
ask before signing up.

The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.

How do I use the Email Addresses Finder?+
Sign in to the platform. Open the Email Addresses Finder. Paste your lines as a full name followed by the company domain - John Doe company.com - one per line, or upload a CSV, XLSX, TXT or Parquet file. Choose your output format and click Get Data. Then sort by status before you do anything with the email column.
What do I have to give it?+
A person and a company domain, on the same line. Both halves are required: a company name on its own comes back as invalid, and so does an email address passed as the query. A first name plus a domain works - John company.com is a valid line.
Is the address it returns confirmed?+
Sometimes, and the status column tells you which. Six values occur: found means a real published address, deliverable means the mail server accepted the mailbox, risky means the domain is catch-all and would accept anything, guess means the server never confirmed the candidate, not_found means no common pattern was accepted, and invalid means the line could not be parsed. Only found and deliverable rows had something confirm them.
Why are deliverable and catch_all sometimes blank?+
Because those columns hold true or nothing at all - they are never false. A blank means the check did not confirm it, not that the answer was no. If you load the column into a boolean field, blank silently becomes false and reads as undeliverable, which is not what happened. Read them alongside status rather than instead of it.
Why did one name come back as several rows?+
Because nothing confirmed a single address for it. When that happens the tool returns a row per candidate pattern instead of picking one badly, numbered by position and always in the same order, from first.last down to last. It means a row is not the same thing as a person, which is worth remembering because billing is per row.
Will the same input always give the same answer?+
No, and we would rather say so. The answer depends on how the domain's mail server replies at that moment, so the same name and domain can come back found on one run and unconfirmed on another. That is the cost of asking the server rather than reading a stale database, and it is why the status column is on every row instead of a single quality score on the file.
What does the pattern column mean?+
It names the shape the address was built from - first.last, firstlast, flast, firstl, first_last, first-last, last.first, lastfirst, f.last, first or last. The value web means the opposite: the address was not built at all, but found published on the web. It is empty on an invalid row.
Is it legal to look up someone's work email address?+
The lookup is ordinary; what you do next is regulated. A named person's work address is personal data under the GDPR and UK GDPR, and running this makes you the controller. Because it did not come from the person, Article 14 applies: you need a lawful basis and you have to tell them you hold their details and where they came from. Sending is governed separately again, by ePrivacy and PECR, CAN-SPAM and their equivalents.
How much does it cost?+
The first 500 rows are free and one-time, with no credit card. After that it is $0.002 per row - the same flat rate as every other scraper on the platform. The estimator shows the cost of a run before it starts.

A name and a company
is enough to start.

Your first 500 rows are free - no card, no subscription. After that it is $0.002 per row, flat.

Activates instantly · no card required

Find a work email address from a name and a domain

The Email Addresses Finder takes the two things you usually have - a person's name and the company they work at - and returns the email address that goes with them. Each line is written as a full name followed by the company domain, like John Doe company.com, pasted one per line or uploaded as a CSV, XLSX, TXT or Parquet file. For each one the tool builds the common corporate address patterns, resolves the domain's mail exchanger over DNS-over-HTTPS through our proxy pool rather than your own IP, and probes each candidate over SMTP. Ten columns come back in the file and eleven in the JSON: the query, the parsed name and domain, the address, the pattern behind it, a status and a plain-English explanation, two confirmation flags and the mail host.

One thing needs saying before you build on this export. The email column is not an answer on its own - status is. Six values occur: found for an address published on the web, deliverable where the mail server accepted the mailbox, risky where the domain is catch-all and would accept any address at all, guess where nothing confirmed the candidate, not_found where no common pattern was accepted, and invalid where the line could not be read as a name plus a domain. Only the first two had something confirm them, so filtering on that column is the difference between a mailable list and a list of constructions.

Two quieter properties follow from the same design. deliverable and catch_all hold true or nothing at all and are never false, so an empty cell means unconfirmed rather than no - cast the column to a boolean and you will misread it. And a single input line does not always produce a single row: when nothing confirms one address, the tool returns a row per candidate pattern, in a fixed order from first.last down to last, numbered by position. That is more useful than a bad guess presented as a fact, but it does mean a row is not the same thing as a person. The answer can also differ between runs, because it reflects what the mail server said at the time rather than a stored record.

Because this produces a named person's work address, it carries obligations the rest of our catalogue mostly does not. That address is personal data under the GDPR and the UK GDPR, you are the controller of it, and Article 14 applies because it did not come from the person - a lawful basis, and telling them where you got it. Sending is governed separately again. Start free: your first 500 rows cost nothing and need no credit card, and after that it is $0.002 per row, flat.