First name, last name, company domain. Ranked candidates, the domain's mail provider, and a CSV.
An email finder turns a first name, last name and company domain into the most likely email addresses. This one generates every realistic pattern, ranks them by how common each format is across corporate domains, and checks by DNS whether the domain accepts mail at all. It infers candidates. It cannot confirm which one exists.
Everything is computed in your browser. The only thing that leaves the page is the domain name, sent to Google Public DNS to read the MX record.
One person per line: first,last,domain. Tabs, semicolons and pipes work too. A header row is detected and skipped. Up to 500 rows.
There is no public registry of which company uses which email format, so this table is a prevalence ordering rather than a measurement of your target. The patterns at the top are the ones mail administrators pick most often. The ones at the bottom turn up mainly in large enterprises, government domains and legacy systems. The score column is exactly what the tool above sorts by.
| Pattern | Example for Ada Lovelace | How common | Score |
|---|---|---|---|
| first.last | ada.lovelace@example.com | Very common, the default at most mid-size and large companies | 100 |
| flast | alovelace@example.com | Very common, favoured where mailbox names are kept short | 96 |
| first | ada@example.com | Very common at companies under roughly 20 people | 92 |
| firstlast | adalovelace@example.com | Common | 84 |
| first_last | ada_lovelace@example.com | Occasional, more often in engineering-led cultures | 62 |
| f.last | a.lovelace@example.com | Occasional | 60 |
| last | lovelace@example.com | Occasional, seen in some European and public sector domains | 56 |
| last.first | lovelace.ada@example.com | Occasional, common in German and Nordic organisations | 46 |
| firstl | adal@example.com | Rare | 42 |
| first-last | ada-lovelace@example.com | Rare | 40 |
| first.l | ada.l@example.com | Rare | 38 |
| lastf | lovelacea@example.com | Rare | 36 |
| fl | al@example.com | Rare, mostly very large enterprises | 34 |
| f_last | a_lovelace@example.com | Rare | 30 |
| first.middle.last | ada.byron.lovelace@example.com | Rare, needs a middle name, mostly US enterprise and government | 28 |
| lastfirst | lovelaceada@example.com | Rare | 26 |
| last_first | lovelace_ada@example.com | Rare | 22 |
| fml | abl@example.com | Rare, needs a middle name | 20 |
One shortcut is worth more than the whole table: crack the format once per company and you have it for everyone there. If you can find a single confirmed address at a domain, from an email signature, a press release or a public contact page, every other mailbox almost certainly follows the same shape. The longer version of that argument lives in the email permutator guide.
Step one, normalise. The name is decomposed to strip accents, so José becomes jose and Ramírez becomes ramirez. Characters that do not decompose get explicit transliterations: ß to ss, ø to o, æ to ae, œ to oe, ł to l, đ to d, þ to th. Anything left that is not a letter or digit is dropped, because local parts with accented characters are legal under the SMTPUTF8 extension and almost never used in practice.
Step two, expand. Hyphens, apostrophes and spaces split a name into parts, and each part set produces several forms. Anne-Marie gives annemarie first, then anne, then anne-marie. van der Berg gives vanderberg first, then berg, then van-der-berg. Initials follow the same logic: the initial of van der Berg is b, with vdb as a lower ranked alternative.
Step three, score. Every pattern in the table gets combined with every name form. The candidate score is the pattern score minus a penalty for using a partial or unusual name form, so vanderberg outranks berg on the same pattern. Duplicates collapse to the highest score they earned, and the list is sorted.
Step four, check the domain. One DNS query over HTTPS reads the domain's MX records. That answers a real question, which is whether the domain accepts mail at all and who hosts it. If there is no MX record, the candidates are moot: mail to that domain will almost certainly bounce, whichever pattern is right. If the MX belongs to a free consumer provider, the whole table stops applying, because those local parts are chosen by each user rather than set by an IT policy.
van, de and von are kept in the joined form and stripped in the alternatives.first@domain, and that is all you get. If you paste a full name into the first name box, the last word is treated as the surname and the tool says so.Paste a list of first,last,domain rows and every person is expanded at once. The interesting part is the deduplication: a 200 row list of one company is 200 people and exactly one DNS query, because MX answers are cached per domain for the life of the page. The stats line above the table reports how many lookups actually went out and how many the cache absorbed.
Export gives you a CSV with one row per candidate: name, domain, rank, address, pattern, prevalence tier, score, whether the domain accepts mail, and the detected provider. That is the shape a verification step wants as input, which is the point. Generate wide, verify hard, send narrow.
Comma, tab, semicolon or pipe. Header rows are skipped.
Candidates locally, one MX query per unique domain.
Download the CSV, then verify before a single send.
An email finder takes what you already know about a person, usually a first name, a last name and their company domain, and returns the email addresses they are most likely to use. This one generates the full pattern set, ranks it by how common each corporate format is, and checks the domain's MX record so you know whether the domain accepts mail at all.
An email permutator is the generation half of an email finder. It mechanically recombines a name and a domain into every plausible address, first.last, flast, firstlast and the rest, and returns the list. It has no knowledge of which one is live. The tool on this page is a permutator with a ranking layer and a DNS check on top, and the longer explanation is in the email permutator guide.
No, and neither can any other tool that only has a name and a domain in a browser. Confirming a mailbox needs a check against the receiving mail server or a database of previously verified addresses. What this page can prove is whether the domain accepts mail and who hosts it. Everything about the specific local part is inference, ranked honestly rather than presented as a result.
Switch to the bulk tab, paste one row per person as first,last,domain, pick how many candidates you want per person and generate. Every unique domain is looked up once and cached, so a long list of colleagues costs a single DNS query. Then download the CSV, which is ready to feed into a verification step.
first.last@company.com, by a clear margin, and it becomes more dominant as headcount grows. Below roughly 20 people, first@company.com is the most likely single answer. In the middle sits flast@company.com, which large organisations favour because it keeps mailbox names short. The full ordering with examples is in the pattern table on this page.
It proves something narrower and still useful: that the domain has somewhere to receive mail, and which provider that is. A domain with no MX record will bounce almost anything you send it, so the candidate list is academic until that is fixed. A domain with a healthy MX record tells you nothing about whether one particular mailbox exists behind it.
The tool flags them and tells you the pattern logic does not transfer. A corporate local part is set by policy, so guessing it is a reasonable bet. A consumer address is chosen by the person who signed up, which is why you get things like adalovelace1815 and ada.l.programmer. Permutations against a free provider are close to random, and the page says so instead of pretending otherwise.
Names, candidates and the CSV never leave the page: generation is plain JavaScript running locally. The one network call is the MX lookup, which sends the domain name to Google Public DNS over HTTPS. Domains only, never a person's name and never a generated address.
Yes. No signup, no credits, no row cap beyond the 500 per paste that keeps the page responsive. Reload and paste the next batch.
Search a name against a real B2B contact database, verify it, and put it in a sequence without leaving one tab.
Try Overloop free