How to find a prospect's email from a name and company on Zo Computer
Find a prospect's email from just a name and company: generate the likely patterns, verify the real one, and stop at the first confirmed hit.
To find a prospect's email from just a name and company, generate the handful of address patterns that person is likely using, then verify which one actually exists with an email verification API and stop at the first confirmed hit. On Zo Computer this runs as a deterministic script, not an AI guessing loop, and it works with whichever verification API you plug in, writing the confirmed address back to a file you own.
Key takeaways
- Most work emails follow six or seven predictable patterns. Generate all of them, then verify, instead of guessing one and hoping.
- The permutation and the verification run as a real script, so a batch of 200 names costs no more AI thinking than one name does.
- Verification is a live check, not a lookup, so it tells you whether an address actually accepts mail right now.
- A catch-all domain accepts every address, so it cannot be confirmed. The tool flags that instead of handing you a false positive.
- Verification is a pluggable step, not one vendor. Point it at whichever email verification API you already pay for, and keep the key in Settings > Advanced as a secret, never in a file or a route.
- Finding an address is automatic and safe. Sending to it is a separate decision that needs your approval every single time.
An email finder that only guesses is a liability. One that guesses and then checks is a tool. The verify step is the whole difference.
Why guessing one address does not work
You have a name and a company. Jane Doe at Acme. You type jane.doe@acme.com, hit send, and the bounce comes back an hour later. Acme runs on jdoe@, and now your first touch is a hard bounce that dinged your sender reputation for nothing. That is the trap a proper cold email address lookup avoids.
The problem is not that you guessed. It is that you guessed once. Companies scatter across a small set of conventions, and which one they picked is not something you can eyeball from outside. A permutator fixes half of that by generating every likely pattern at once. Verification fixes the other half, telling you which one is a real mailbox before you send.
What are the common work-email patterns?
Almost every corporate address is one of a short list of formats built from a first name, a last name, and a domain. Here they are, with Jane Doe at acme.com as the example, roughly in the order they appear in the wild.
| Pattern | Example | Notes |
|---|---|---|
| first.last@ | jane.doe@acme.com | The most common corporate default |
| flast@ | jdoe@acme.com | First initial plus last name, very common at scale |
| first@ | jane@acme.com | Smaller companies and early hires |
| f.last@ | j.doe@acme.com | First initial, dot, last name |
| last@ | doe@acme.com | Rare, usually tiny teams or founders |
| firstl@ | janed@acme.com | First name plus last initial |
The permutator does not stop at these six. It also produces the less-common orderings, middle-name variants when you supply a middle name, and dashed and underscored versions, all ranked from most to least likely. It is a faithful port of Metric Sparrow's "Email Permutator+", so the formulas and their ordering match the tool people have trusted for years. It will not invent an address that breaks the pattern rules, which keeps the list clean.
Which email verification API should you use?
Whichever one you already trust. Verification is one HTTP call at the end of the pipeline, so the provider is a swappable part rather than a dependency. MillionVerifier, ZeroBounce, NeverBounce, Emailable, Bouncer, and Clearout all do real-time single-address checks, and finder-style services like Hunter or Findymail can return a known address before you resort to guessing. Tell Zo which one you use and it wires that call in.
Judge them on three things: whether the check is live rather than a stale database lookup, whether the response distinguishes a catch-all domain from a confirmed mailbox, and what a check costs you at your volume. Pricing and free tiers shift constantly, so read the provider's current terms rather than trusting any number you find in an article.
How do you find a prospect's email in Zo, step by step?
The workflow is short because the script does the mechanical work.
- Add a verification key once. Pick a provider, generate an API key, and paste it into Settings > Advanced as a secret. Zo reads it from the environment, so it never touches a file.
- Give Zo the name and the company. A domain is ideal. With only a company name, the pipeline resolves it to a domain using a free keyless lookup.
- Let it permutate and verify. The script generates the ranked candidates, then checks them against your verification API in order, stopping the instant one verifies.
- Read the confirmed address from the file. The result is written back to your workspace, so it is a record you own and can hand to the next step.
Here is the copy-paste prompt for a single prospect. Hand it to Zo verbatim, changing the name, company, and output path.
Use the email-permutator skill to find and verify the work email for
Jane Doe at Acme (acme.com). Run the full find_verify pipeline: resolve the domain, permutate the likely addresses, and verify them through my verification API, stopping at the first confirmed hit. Write the result to Sales/verified-emails.csv with the name, company, domain, status, and the confirmed address. Report the status and the address back to me. Do not email anyone.The address that comes back has a status. You want valid. If it reads catch-all, not-found, or no-domain, read the failure section below first.
How do you verify a work email for a whole list at once?
Point the same email finder tool at a CSV and it runs the whole list, one row at a time, writing a confirmed address per person. Each row needs a name source and a domain source. Names can be first+last, a name column, or a LinkedIn URL it falls back to parsing. Domains can be a domain or website column, or a company name it resolves for you.
Use the email-permutator skill in batch mode. Read my leads at
Sales/leads.csv, run find_verify on every row, and write the results to Sales/leads-verified.csv. For each person: resolve the domain, permutate, verify through my verification API, and stop at the first confirmed hit. Mark catch-all and not-found rows as such instead of guessing. Do not send any email. Summarize how many came back valid, catch-all, and not-found.The output CSV carries a status column per row, so you filter to the valid ones and set the rest aside. Because the permutation and the API calls are a deterministic script, a 200-row list is the same kind of work as a 1-row list. No AI reasoning happens per name, which keeps a big batch from becoming a big bill. The files on your server become the shared surface every later step reads from.
How does the pipeline save verification credits?
Every verification API charges per check, so the script spends as few as possible. Three levers do that work.
| Lever | What it does | Why it matters |
|---|---|---|
| Stop at first hit | Probes candidates in ranked order and quits the moment one verifies | A typical person resolves in one to six checks, not the full candidate list |
| Catch-all detection | Spots a domain that accepts everything on the first probe | Stops the run from burning credits guessing against a server that says yes to anything |
| Optional lookup step | If an email finder API key is set, asks it for the known address before guessing | A well-known company can resolve without spending a verification credit |
A lookup API earns its keep on well-known companies where it returns the answer outright, so the verification API only handles what guessing cannot settle. Free tiers, credit bundles, and rate limits differ by provider and change often, so check current terms before you commit to one. You can skip the lookup step entirely, and you can cap the probes per person to trade a little hit rate for fewer credits. For a dry run that spends nothing, tell Zo to resolve and permutate only, skipping verification.
What goes wrong, and how to keep it accurate
An email finder that never lies to you beats one that always answers. Here is where this one can mislead, and the guardrail for each.
Catch-all domains cannot be confirmed. Some mail servers accept every address, valid or not. The pipeline detects that on the first probe and returns catch-all, so the top-ranked guess is your best bet but nobody can verify it. Treat a catch-all address as a lead, not a fact.
Verification is not 100 percent. A verification API does a live check, and live checks have edge cases. A valid result is strong evidence, not a guarantee. If a send bounces anyway, believe the bounce.
A lapsed key fails silently. If a verification or lookup key expires or runs out of credits, the API calls fail while the script keeps running. Have Zo flag a run where verification errored instead of recording everything as not-found. Zero valid addresses across a clean list is a signal to check the key, not proof the list was bad.
Fuzzy inputs produce fuzzy domains. A misspelled company name or a defunct domain resolves to nothing, so you get no-domain. Feed it the real domain when you have it. The domain is the load-bearing input.
Finding is not permission. This is the one that matters. Locating someone's address is not consent to email them, and not a license to blast a list. Keep outreach to people with a genuine reason to hear from you, honor unsubscribes and anti-spam law, and send one clean, personalized ask rather than a template to a thousand rows.
The send guardrail stays on. Zo drafts and finds. It does not send on its own. Finding the email is automatic and safe. Emailing it needs your explicit approval each time, which is the boundary you want between a research tool and a spam cannon. This pairs with a CRM that enriches leads and drafts outreach, where the drafting stays gated the same way.
Where does the API key go?
In Settings > Advanced, in the Secrets area, as an environment variable named for the provider you chose. Zo stores it there and the script reads it at runtime, so the key and the code stay two separate things.
This matters more than it sounds. An API route on Zo is public at the network level, so a key pasted into a route is not stored, it is published, readable by anyone who looks. The secrets and API keys rule is narrow: third-party keys live in Settings > Advanced, never in a file, a route, a comment, or a log line. An optional lookup API key goes in the same place. If a key leaks, revoke it at the provider first.
Frequently asked questions
How accurate is finding a prospect's email by permutation?
Permutation generates the likely candidates, and the verification step is what makes it accurate. A valid result from a verification API means the address passed a live check and is strong evidence it exists. Catch-all domains are the exception, since they accept everything and cannot be confirmed either way.
Can you find an email from just a name and company with no domain?
Yes. The pipeline resolves a company name to a domain automatically using a free keyless lookup, and an optional email finder API can also backfill a domain from a company name or a LinkedIn handle. A real domain is still the strongest input when you have one.
Does this cost money to run?
The scripts themselves are free. The only cost is whatever your email verification API charges per check, and most providers offer a free tier to start. The pipeline stops at the first verified hit and detects catch-all domains early, so a typical person costs one to six checks rather than the full candidate list. An optional lookup step can resolve well-known companies without spending a verification credit at all.
What is email permutation?
Email permutation is generating the standard address formats a person might use from their name and company, such as first.last@, flast@, and first@, ranked from most to least likely. It gives you a candidate list to verify instead of a single blind guess.
Is it legal to find someone's work email this way?
Finding a publicly patterned work address is generally fine. Sending to it is where the rules live. Follow anti-spam law, keep outreach relevant and consented where required, and honor opt-outs. Finding an address is never permission to spam it.
Where do I store the email verification API key in Zo?
In Settings > Advanced, in the Secrets area, as an environment variable named for whichever provider you chose. Never put it in a file, a route, or a code comment, because API routes are public and a key in code is a published key. The script reads it from the environment at runtime.
Put it to work
Try this in your Zo
Open Zo, connect the tools this guide uses, and ask it to build the workflow with you.
Try ZoContinue learning
Automated lead enrichment in a spreadsheet CRM that drafts your outreach
Automated lead enrichment in a spreadsheet CRM: an automation researches each lead from public sources, then drafts personalized outreach into Gmail.
TutorialCompetitor tracking automation that pings you when pricing moves on Zo
Build competitor tracking automation in Zo with a snapshot diff. Monitor competitor website changes from a watchlist file, get pinged only on real moves.