How to find email address for anyone, then verify it

Ask most people how to find email address records for a prospect, and they will name a tool first. You type in a name and a company, a box appears with an address, and the tool shows a green tick. The tick is the problem. It tells you that something matched, not that the address is right, and the difference is where cold campaigns quietly lose their reputation. A guessed address that happens to pass a weak check is still a guess, and a guess that bounces is a mark against every other message you send from that domain.

Finding a work email is a three-step job: establish the pattern a company uses, generate candidates from it, and verify each candidate with checks that you understand. This playbook walks through each step, explains what each check actually proves, and shows how to handle the cases that no tool can resolve for you.

Start with the pattern, not the person

Companies tend to use a small number of address formats, and once you know a company’s format, you can construct an address for anyone at that company. The formats are common enough that a short list covers most of the market.

The job of pattern discovery is to find real addresses at the target company, so you can see the format directly. Good sources include the company’s own press releases, which often name a spokesperson with a contact address, conference speaker pages, podcast show notes, published papers or reports with a corresponding author, open-source commit metadata for engineering teams, and customer case studies that name an implementation lead. None of these is guaranteed, and you should check the terms of service for each source before collecting at any scale. Scraping profile pages in bulk can breach a platform’s rules, and it is the kind of activity that makes your list harder to defend later.

Aim for three addresses before you trust a pattern. One address could be an exception: a contractor with a personal domain, an executive with a vanity alias, or an old employee’s address that was never updated. Three addresses that follow the same format make the pattern credible. If you can only find one, treat every candidate you generate from it as a low-confidence guess and verify it harder.

The formats you’ll meet most often

Once you have examples, match them against a short list of formats. For a person named Maria Lopez at a company called Acme, the common variants look like this:

1. first.last@acme.com gives maria.lopez@acme.com. This is the most common format in larger companies.
2. first@acme.com gives maria@acme.com. It shows up at smaller companies and startups.
3. flast@acme.com gives mlopez@acme.com. Often used where email addresses were assigned by a system.
4. firstlast@acme.com gives marialopez@acme.com. Less common but seen in some organizations.
5. first_last@acme.com or first-last@acme.com gives maria_lopez@acme.com. Common in certain tech and agency teams.
6. last.first@acme.com or lastf@acme.com. Rare, but found in some older and more formal organizations.

Two details trip people up. First, the format is a property of the company, and it can differ by region or by acquisition. A company that acquired another firm may run two formats at once, with the acquired staff on the older one. Second, a name with a hyphen, an accent, or a particle, like “de” or “van,” may be rendered differently in the address. Check the examples you have, not your assumptions about how names should be written.

Don’t generate every variant and send to all of them. That is how you build a list of addresses that bounce, and it looks like guessing to every receiver that sees it. Generate the one format your examples support, and keep the alternatives as a fallback you verify separately.

What each verification check actually proves

Verification is a set of checks, and each one answers a narrower question than people assume. The table below summarizes what the common checks can and cannot tell you.

The SMTP handshake is the most powerful check and the most misunderstood. A verifier connects to the recipient’s mail server, announces itself, names a sender, and asks whether the recipient is valid, without sending a message. A 250 response means the server accepted the recipient at that point. A 550 response with a code like 5.1.1 means the server says the user is unknown. Both answers are useful. Neither is absolute.

Consider why. Many domains are configured to accept every address and sort the mail later, which makes a 250 meaningless for that domain. Some servers respond with a temporary 4xx code, a deliberate delay known as greylisting, and a verifier that gives up at that point learns nothing. Large consumer providers frequently rate-limit or refuse probes altogether, so silence tells you nothing. A verifier that returns “valid” for a domain it could not really test is making a claim it cannot back up, and that is the most common source of bounces that verification was supposed to prevent.

Catch-all domains: the uncertainty you can’t remove

A catch-all domain accepts mail for any local part. Every candidate you test on that domain comes back accepted, including the ones that don’t exist. Verification can detect that the domain is catch-all, but it can’t tell you which individual addresses are real.

That is the case where a tool’s green tick is least trustworthy. At a catch-all domain, the honest status for an address is “unknown with a pattern guess,” and the sending strategy should reflect that. Label catch-all results as their own risky tier. Keep the tier small, send it in limited volume, and watch its bounce rate separately from the rest of the list. If the tier bounces heavily, you have learned something about the domain, and you should stop sending into it.

Some teams try to resolve catch-all addresses with additional signals, such as the person’s public presence on the company’s own site, or a confirmed address for a colleague that follows the same pattern. Those signals help. They do not turn a catch-all address into a verified one, so keep the label.

Why the probe sometimes lies

Three situations explain most of the false results you’ll see. Greylisting makes a server respond with a temporary failure to a first-time sender, which a verifier may misread as an unknown user. Probe blocking happens when a mail provider decides that repeated verification requests look like harvesting and starts refusing them, so the verifier gets no reliable answer. Accept-all configurations make a valid-looking response meaningless, as covered above.

The practical implication is that a verifier’s confidence score is an estimate built from these signals, and the estimate can be wrong in predictable ways. Run a sample of your verified list through a second verifier or a small test send before you commit a large batch. If two tools disagree on a meaningful share of addresses, that disagreement is itself a warning about that domain or segment.

When there is no pattern to find

Sometimes the evidence doesn’t exist. A company has no press contacts, no speakers, no public engineering commits, and the three addresses you can find use three different formats. In that case, resist the temptation to pick the most common format and carry on. Mixed formats are information. They often mean the company has changed its system, acquired another firm, or lets each team choose its own, and any single pattern you pick is a guess.

Move to other routes. A warm introduction through a shared contact is the strongest, because the introducer’s name gives the message a reason to be opened. A contact form on the company’s website, where one exists and is meant for sales inquiries, is a legitimate channel for a first message, and it avoids guessing an address altogether. A published role address such as sales@ or partnerships@ may work as a starting point, though you should expect it to reach a shared inbox rather than the person you want.

Duplicate names need care too. Two people with the same name at one company, or a common name at a firm with several hundred staff, is a classic way to send a message to the wrong person. Check the title and location on the profile against your source before you generate anything, and keep the source note next to the contact so the decision can be defended later. If none of these routes works, the honest answer is that the contact isn’t reachable by email right now, and the right move is to leave it out of the batch.

How to find email address data for 500 contacts, step by step

Here is the sequence to run on a batch of about 500 contacts, which is a realistic size for a focused campaign.

1. Start with the list of names and roles. Confirm each person still works at the company and holds a relevant role. Remove anyone whose status you can’t confirm, because a correct address for the wrong person is still a wasted send.
2. Group the contacts by company. Pattern discovery happens per company, so grouping saves time and keeps your evidence organized.
3. Establish the pattern for each company from at least three known addresses, and record the source for each example.
4. Generate one candidate per contact in the confirmed format. Skip companies where you can’t establish a pattern, and flag them for manual research instead of guessing.
5. Run the verification checks, then sort the results into three tiers: valid, catch-all or uncertain, and invalid. Drop the invalid tier entirely.
6. Check the disagreement. Run a sample through a second verifier. Note the segments where the tools disagree.
7. Send the valid tier first, in normal volume. Hold the catch-all tier back, and send it in small batches so you can watch its bounce rate separately.

This workflow is slower than importing a list and pressing send, and it produces a smaller list. That is intentional. The purpose of a verified batch is to keep your bounce rate low, which protects every other message you send, and a smaller clean list does that better than a large one that hides its failures.

Where the lead finder fits

Teams rarely do all of this by hand at scale, and the sensible approach is to automate the repetitive parts while keeping the judgment steps visible. OutboundLeadPro’s lead finder runs a free Smart check on every email it returns, so a basic validity pass happens before you decide what to send. That check is a starting point. The pattern evidence, the tiering and the decision about catch-all domains still belong to you, and they are the parts that protect your reputation over time. You can see how the lead finder and Smart check work, or start from the main page at OutboundLeadPro.

The wrap-up: a method you can defend

Finding an email address is easy. Finding one you can defend, to your own deliverability numbers and to a recipient who asks where you got their address, is harder. The method that holds up is simple to state. Confirm the pattern from real examples. Generate one candidate in that format. Verify with checks you understand, and label the uncertainty honestly. Send the confident tier first, and treat the uncertain tier as an experiment with its own limits.

If you do that consistently, your bounce rate stays low, your domain stays healthy, and the list you build becomes an asset rather than a liability. For the next step, once you have a clean list, the guide to fixing a high bounce rate covers what to do when a batch goes wrong anyway, and the lead list guide covers how to decide who belongs on the list in the first place.

Keep reading

Playbook

Cold Email A/B Testing: Why Most Tests Prove Nothing

Cold email A/B testing is often too small to mean anything. Here is the sample-size math at real reply rates, and how to read the results.

Daniel Khoury September 19, 20263 min read

Playbook

How to avoid spam folder placement: 12 causes and fixes

Want to avoid spam folder placement? These 12 causes, from authentication to list quality to complaints, each come with a concrete fix you can check.

Daniel Khoury September 24, 20263 min read

Playbook

How to build a lead list that stays clean after the first send

Build a lead list around a real ICP, with stage gates that reject bad rows before they cause bounces and complaints. Includes a worked example.

Daniel Khoury October 7, 20263 min read

Explainer

SPF, DKIM and DMARC explained for cold email

The three email authentication records decide whether you reach the inbox — and most cold outreach fails because one is missing or wrong. Here's each one in plain English.

The OutboundLeadPro Team October 11, 20262 min read