Free email permutator.
Enter a name and a domain, get every common corporate address pattern out. These are candidates, not addresses: the step that turns one into the other is verification, and sending an unverified permutation list is one of the fastest ways to a bounce rate that follows your domains around.
Privacy: this tool runs entirely in your browser. Nothing you type leaves this page, nothing is stored, and nothing is sent to GrowthPal.
Address patterns at a glance
| Item | Value |
|---|---|
| What this produces | Candidates. Not addresses, and not a list |
| The rule | Nothing gets sent to until something verified it |
| The usual winner | first.last@ dominates US and EU B2B; first@ dominates startups |
| The shortcut | One confirmed address at a company usually reveals the pattern for everyone else |
| When to use something else | At volume. A finder waterfall carries the bounce risk instead of your domains |
What is an email permutator?
An email permutator is a tool that combines a person's name with a company domain across the standard corporate address formats, producing every plausible version of their address.
It exists because company email formats are conventional rather than creative. Most organizations pick one pattern and apply it to everyone, so the space of possibilities is small and enumerable. What a permutator does is enumerate it.
What it cannot do is tell you which one is real, and that limitation defines correct use. A permutator is a tool for the single hard-to-find person: a new hire, someone at a stealth company, someone who keeps their address off the internet. It is the wrong tool for building a list, because a list of guesses sent to at volume produces exactly the bounce pattern that gets sending domains flagged.
How to read your results
The permutator returns the full set of candidates plus three notes about what to do with them.
Do not send to all of these. The list is deliberately exhaustive, which means most of it is wrong by construction. Blasting permutations guarantees bounces, and bounces are the expensive kind of mistake.
The usual winner. first.last@ dominates US and EU B2B and first@ dominates startups, so if you have to pick a single candidate to verify first, start there.
The faster path at scale. For anything beyond one or two people, a waterfall of finder providers is the right tool, because those services carry the verification burden and the bounce risk rather than your sending domains.
Treat the output as a shortlist to verify, in priority order, not as a set of addresses to try.
Which patterns are actually common
| Pattern | Example for Jane Smith | Where you see it |
|---|---|---|
first.last@ | jane.smith@ | The most common by a distance in US and EU B2B. |
first@ | jane@ | Startups and small teams, until two people share a first name. |
flast@ | jsmith@ | Enterprises and older organizations. |
firstl@ | janes@ | Less common, still current at some mid-size companies. |
first_last@ | jane_smith@ | Occasional, more common outside the US. |
lastf@ / last.first@ | smithj@ / smith.jane@ | Rare, and worth trying only after the others fail. |
Choosing a method
| Situation | Right tool | Why |
|---|---|---|
| One specific person you need | Permutate, then verify | Finds addresses no database holds, at a cost of a couple of minutes. |
| A few people at one company | Confirm one, infer the rest | One verified address usually reveals the company pattern. |
| A list of any size | Finder waterfall | The provider carries the bounce risk, and does it across several data sources. |
| A brand new company with no web presence | Permutate, then verify | Databases have nothing yet; the pattern is still conventional. |
| A catch-all domain | Neither, reliably | Everything verifies as acceptable, so no method can confirm the real address. |
How to find one person's address
- Look for a known address at that company first. A press release, a support thread or a team page often gives you one, and one is enough to infer the pattern.
- Generate the candidates. Full name and domain, exactly as the company spells them.
- Order them by likelihood.
first.last@for an established B2B company,first@for a startup under about twenty people. - Verify the top candidate before anything else. A verification service, not a send. This is the step that separates a candidate from an address.
- Stop at the first confirmed result. Do not verify the rest, and certainly do not send to them.
- Record the pattern against the company. The next person there costs you no guesswork at all.
Common questions about finding email addresses
How do I work out which pattern a company uses?
Find one confirmed address at that company and the pattern almost always holds for everyone else. Permutation is for the case where you have none, and every candidate it produces still has to be verified before anything is sent to it.
Is guessing addresses not how you end up with bounces?
Only if you send the guesses. This produces candidates, not addresses, and verification is what turns one into the other. Sending an unverified permutation list is among the fastest ways to a bounce rate that follows your domains around for months.
When does this beat a lead database?
For a single hard-to-find person: a new hire, a stealth company, someone who keeps their address off the internet. For volume it is the wrong tool, because a finder waterfall carries the bounce risk instead of your domains.
Can I send to several guesses at once?
No. Every wrong address is a bounce, and several bounces at one company on one day is a pattern their gateway notices. Verify, pick the one that resolves, send once.
What if the company uses a catch-all domain?
Then no method confirms anything, because a catch-all accepts every address you try. Verification comes back acceptable for a typo just as readily as for the real mailbox. Treat the most likely pattern as unconfirmed, and expect that it may reach nobody even though it never bounces.
What about people with middle names, hyphens or accents?
Companies almost always strip them, so a hyphenated surname usually becomes one run of letters and accented characters become their unaccented equivalents. Generate both forms where you are unsure, then verify rather than assuming, because the stripping convention varies by provider.