ON THIS PAGE
By Efe Berke Colaker, Founder at GetleadReviewed by the Getlead editorial team for accuracy. Last updated August 2026.
You have a name, a company and a domain, and no email address. The permutator approach is to generate every plausible combination, test them, and keep whatever survives. It is old, it is crude, and on the right kind of company it still works better than most people expect.
It also has a failure mode that quietly destroys sending reputation, because a permutation list is by definition mostly wrong. This covers the patterns worth generating, how to test them safely, and when to stop and use a real finder instead.
What a permutator actually does
A permutator takes structured inputs, usually a first name, last name and domain, and expands them across known naming conventions. Given Jane Smith at example.com it produces jane.smith@, jsmith@, jane@, smithj@, j.smith@ and a dozen more.
That is the whole mechanism. There is no lookup and no source, which is the important distinction: a permutator is a hypothesis generator. While a finder queries data that already links a person to an address. Confusing the two is how teams end up mailing guesses.
Getlead has a free permutator on the tools page. And it exists precisely because the technique is useful as a starting point rather than as an answer. Everything below is about the difference.
The patterns that cover most companies
Conventions cluster hard. A handful of formats account for the large majority of business domains, and generating fifty exotic variants mostly adds noise to verify.
Company size predicts the pattern
Small companies lean toward first name only, because there is no collision to resolve. Larger organizations need disambiguation, so they use first.last or flast. If you know the headcount band you can usually order your candidates sensibly before testing any of them, which cuts the work substantially.
One real shortcut beats all of this: find any single confirmed address at the domain and the convention is solved for everyone there. A published contact on the website, a press release, a support address in a footer, or one verified record in your own database tells you the pattern for the entire company.
Order candidates before you test them
Testing costs something, whether that is verification credits or time, so the order matters. For a company under 20 people, try first, then first.last, then flast. Above 200 people, reverse it: first.last and flast first. And treat plain first name as unlikely because the collision would have forced a change years ago.
That single heuristic typically finds the right address in the first two attempts instead of the sixth. That matters when you are working a list of several hundred rather than one prospect.
An email permutator is a generator that combines a person's name with a company domain across known naming conventions, producing candidates rather than confirmed addresses.
For example, generating candidates for Jane Smith at example.com produces jane.smith@, jsmith@, jane@ and janes@ among others. At most one is correct, so the other eleven are hard bounces waiting to happen if anyone mails the list without verifying it first.
A naming convention is the single rule a company applies to every mailbox it creates, which is why one confirmed address resolves the format for the whole domain.
Why you cannot send to the output
A permutation list is mostly wrong by design. If you generate twelve candidates for one person, at most one is right, so eleven are invalid addresses waiting to bounce.
Our verification data puts invalid addresses at 23.9% of raw B2B records, and those are records someone at least intended to be real. Unverified permutations are worse by construction, and sending to them drives bounce rates far past the roughly 3% level where sender reputation starts to suffer.
The tempting shortcut, mailing all twelve candidates and seeing which one answers, is the single fastest way to burn a sending domain. Eleven hard bounces per prospect is not a campaign, it is a reputation experiment with a known result.
Verify, then send
SMTP verification tests each candidate against the receiving mail server without delivering anything. That converts a list of guesses into a small set of confirmed addresses. And it is the step that makes permutation safe rather than reckless.
A hard bounce is a permanent rejection from the receiving server, and every one of them is charged against the sending domain's reputation.
Where the technique breaks down
Permutation has three hard limits, and knowing them saves hours of pointless generation.
- Catch-all domains. The server accepts every address, so every candidate verifies as maybe. In our data 16.7% of records sit in this state and no amount of guessing resolves it.
- Non obvious conventions. Initials, employee numbers, middle names and regional formats defeat pattern generation entirely.
- Name ambiguity. Compound surnames, transliteration and preferred names mean the input itself is wrong, and no pattern applied to a wrong name produces a right address.
- Large companies with duplicates. Two Jane Smiths force a disambiguation scheme you cannot guess from outside.
Catch-all is the one that matters most in practice. Treat those prospects as a separate segment, send at low volume. And judge them on replies rather than on verification status, because verification cannot help you there.
The workflow that keeps it safe
Permutation earns its place as a fallback, not as a primary sourcing method. The order below keeps the cost low and the risk contained.
- Search a real database first. If the address exists as a sourced record, use it and skip everything else.
- If not found, check whether you already know the company's convention from any confirmed address at that domain.
- Generate candidates for the six common patterns only, ordered by company size.
- Verify all candidates with SMTP verification, never by sending.
- Keep confirmed valid results. Discard invalid ones and park catch-all results in a separate low volume segment.
- Record how each address was obtained, so a guessed address is never mistaken for a sourced one later.
That last step is worth more than it looks. Six months on, nobody remembers which records came from a database and which came from a permutator. And the difference matters both for data quality and for answering where a record came from.
Used this way the technique is a genuine gap filler for the small share of prospects a database misses. Used the other way, as a bulk address generator, it is the fastest route to a domain nobody will hear from again.
When to stop guessing entirely
If a domain resists three verified attempts, stop. The cost of continuing rises while the odds fall. And the prospect is usually reachable another way: a colleague at the same company whose address you can confirm, a contact form, or a connection request that puts the conversation somewhere else.
Permutation is at its best filling small gaps in an otherwise sourced list. When it becomes the main way you build lists, the real problem is that the underlying data source is too thin. And no amount of pattern generation compensates for that.
Sources and method
First-party data (Getlead, 2026): the verification split of 43.4% confirmed valid, 23.9% invalid, 16.7% catch-all and 16.0% unknown comes from 383,368 addresses analyzed through live SMTP verification. And the 0.51% bounce rate comes from 34,973 tracked sends, aggregated and anonymized at campaign level. Full method in our cold email benchmark study.
External sources: sender reputation and the 0.3% spam complaint ceiling that bounded sending behaviour throughout this guide (Google Workspace sender guidelines, 2026); mailbox verification behaviour follows the SMTP specification in RFC 5321.
US commercial email obligations, including accurate headers, a physical postal address and a working opt-out honored within 10 business days, come from the FTC CAN-SPAM compliance guide.
Figures were checked in August 2026.
Frequently asked questions
What is an email permutator?
A tool that generates candidate email addresses by combining a person's name with a company domain across common naming conventions. It produces hypotheses rather than verified addresses, which is the key difference from an email finder that queries data linking a person to a known address.
What are the most common business email formats?
first.last is the most common overall, followed by first alone at small companies, flast and firstl at larger ones, then first_last and lastf. Company size is a good predictor: small teams use first name only because there are no collisions to resolve.
Is it safe to send to permutated email addresses?
No. A permutation list is mostly wrong by design, so sending to it produces many hard bounces per prospect. Our verification data shows 23.9% of ordinary raw records are already invalid, and unverified guesses are worse. Verify with SMTP first, then send only to confirmed addresses.
Why do permutations fail on catch-all domains?
A catch-all server accepts mail for any address at the domain, so every candidate returns the same accepting response and none can be confirmed. In our data 16.7% of records sit in this unconfirmable state, and no amount of pattern generation resolves it.
How can I find a company's email format quickly?
Find one confirmed address at the domain and the convention is solved for everyone there. Published contacts, press releases, footer support addresses or a single verified record in your own database all work. And this is far faster than testing patterns person by person.
Is a permutator better than an email finder?
No, it is a fallback for the cases a finder misses. Search a sourced database first, and use permutation plus verification only when nothing is found, recording how each address was obtained so guesses are never confused with sourced records later.