Email Permutation: Guessing an Address From a Name and a Domain

Email Permutation: Guessing an Address From a Name and a Domain

Email permutation is the technique of generating the plausible mailbox formats for a known person at a known domain, then testing which of them exists. Given a first name, a last name and a company domain, it produces a short set of candidates such as first.last@, flast@, first@ and firstlast@, and resolves them by asking the receiving mail server which one it recognises. It is a derivation method rather than a lookup method: nothing is retrieved from a database of known addresses, because the address is constructed and then tested.

The term exists to separate two things that are sold under the same label. An email finder that returns an address may have found it in a repository of previously observed addresses, or it may have guessed it and checked the guess, and those two products have completely different failure modes. A repository can be stale, incomplete, and wrong about who currently holds an address. A permutation can be structurally impossible to resolve at certain domains regardless of how good the tool is. Knowing which mechanism produced an address tells you what kind of wrong it is allowed to be.

How permutation actually works

The method has three parts: build the candidates, test them, and interpret the answer.

1. Step 1Establish the inputs

   A person's first and last name, and the company's mail domain, which is not always the same as its website domain

2. Step 2Generate candidates

   Apply the standard mailbox formats, plus any pattern already observed at that domain from a known colleague

3. Step 3Test each candidate

   Resolve the domain's mail exchanger and ask whether the mailbox is accepted, one candidate at a time

4. Step 4Interpret the verdict

   Accept a single clear positive, and recognise the domain configurations where no verdict is available

The candidate set is small and the distribution across it is uneven. In most corporate environments a handful of formats account for the large majority of addresses, with first.last@ and first initial plus last name being the most common shapes, and single-name formats concentrated in smaller companies. The practical effect is that the first two or three candidates resolve most people, and the long tail of exotic formats costs more to test than it returns.

The strongest accelerator is not a better guess but a known colleague. One confirmed address at a domain usually reveals the convention for the whole organisation, which converts every remaining person at that company from a guess into a derivation. This is why permutation gets cheaper as a list concentrates into fewer companies, and more expensive as it spreads across many domains with one contact each.

Testing rests on the mail protocol's own address-verification behaviour, and the standard is unusually explicit about how little that behaviour guarantees. RFC 5321 states that "A server MUST NOT return a 250 code in response to a VRFY or EXPN command unless it has actually verified the address", and where a server cannot verify, "reply code 252 SHOULD be returned". It also notes that implementations "MAY provide local installations a way to disable either or both of these commands" for security reasons (RFC 5321, Simple Mail Transfer Protocol). Read together, those clauses describe a verification channel that was designed to be optional, and which large numbers of operators have chosen to switch off or answer non-committally.

Reading the verdicts

A usable answerThe method worked

• One candidate accepted, the others rejected
• The pattern is now known for that domain
• Supports the conclusion that the mailbox exists
• Says nothing about who reads it

No answer availableThe method cannot resolve here

• Accept-all domains answer yes to every candidate, including invented ones
• Verification commands disabled, so nothing is testable
• Greylisting delays the answer rather than giving one
• Treating any of these as a positive is the error the whole method has to guard against

A clear negativeUseful and often ignored

• Every candidate rejected at a live mail host
• Usually means the person is not at that domain, or the mail domain is different from the web domain
• Worth re-checking the domain before discarding the person
• A genuine negative is information, not a failure

The accept-all case is the one that decides whether the method is safe to rely on. On a domain configured to accept mail for any local part, every candidate you test returns a positive, including a deliberately nonsensical one. That is the standard test and it is worth running as a matter of course: submit a random string at the domain, and if it is accepted, no result from that domain means anything. A verification step that cannot distinguish a real mailbox from a fabricated one has not verified anything, and reporting its output as a pass is how invalid addresses enter a list wearing a green tick.

How the method is measured

Permutation is judged on two rates, and quoting one without the other is how the method gets oversold.

Hit rate is the share of attempted people for whom a single candidate resolves cleanly. It varies by segment far more than by tool: it is high in mid-sized and large companies with an enforced naming convention, and it falls away in small businesses, in owner-operated companies using a personal-style mailbox, and anywhere the mail domain differs from the website domain. Suppose you run a batch across a segment of established mid-market companies and a second batch across independent local businesses. The two hit rates will not resemble each other, and averaging them produces a figure that describes neither.

Falsifiability rate is the more useful and less discussed number: the share of domains where a negative answer is actually available. It is the share of domains that reject an invented local part rather than accepting everything. On a segment where that rate is low, the hit rate is meaningless, because most of the hits were unfalsifiable acceptances rather than confirmations. Measuring it is cheap: test one random string per domain before testing any real candidates, and count.

Run both on a sample before committing a large batch. A segment with a good hit rate and a poor falsifiability rate is a segment where permutation should be used to generate candidates and something else should be used to confirm them. Knowing that in advance is the difference between a costed decision and a surprise at send time.

Where the textbook definition breaks

The definition says permutation finds an address that exists. Both halves of that sentence carry more weight than they can hold.

An existing mailbox is not a monitored mailbox. Permutation resolves whether the mail server will accept mail at an address; it has no visibility into whether anyone opens it. Aliases, shared inboxes, distribution lists, catch-alls routed to an archive and mailboxes belonging to someone who left months ago all accept mail and all verify identically to a live personal mailbox. So a technically valid address can reach nobody, and there is no signal in the verification result that distinguishes the two. This is why a role or shared address that verifies cleanly deserves separate consideration rather than automatic inclusion: the check that passed was a check about mail routing, not about readership.

On an accept-all domain the method returns a confident positive for everything, so the verdict is not evidence. This is the more serious break, because it fails in the direction that looks like success. A rejection is unambiguous. A universal acceptance produces a full column of verified-looking addresses, most of which may be wrong, with nothing in the output to indicate which. Any process that consumes permutation output has to carry the accept-all flag alongside the address and refuse to treat those rows as confirmed. A check that cannot see must not report a pass, and a verification layer that quietly converts "I could not tell" into "valid" is worse than no verification at all, because it removes the reason anyone would look again.

Greylisting is the milder version of the same problem. A temporary deferral is a request to try later, not a verdict, and a process that records it as a negative discards real people while a process that records it as a positive invents them. The correct handling is to hold the row and retry, which is an operational cost most implementations would rather not carry.

Is permutation the right method here?

• ✓Yes: Several contacts at the same domain, so one confirmed pattern resolves the rest
• ✓Yes: A company large enough to run a predictable naming convention
• ✓Yes: A name you are confident is spelled and ordered correctly
• ✕No: Domains that accept mail for any local part, where no candidate can be falsified
• ✕No: Consumer or freemail domains, where there is no organisational convention to derive
• ~Depends: Names with multiple surnames, diacritics or an unclear given-name order
• ~Depends: One contact at each of many unrelated domains, where the cost per resolved address rises sharply

What to do with it

Treat permutation as the cheap first stage of a wider resolution process rather than as a substitute for one. It costs almost nothing per attempt, resolves a substantial share of ordinary corporate contacts, and hands the remainder to paid providers with a smaller bill attached. That ordering is the whole argument for it, and the neighbouring entry on waterfall enrichment covers how the stages hand off to each other.

Carry the verification state with the row rather than reducing it to a yes or no. An address that resolved cleanly at a normal domain and an address that "passed" at an accept-all domain are different objects, and collapsing them into one column destroys the only information that would let you handle them differently later.

Finally, keep the mailbox-shape question separate from the address-validity question. Whether an address is deliverable is one problem, and whether the person you intended to reach will read it is another; permutation speaks to the first and is silent on the second. Deliverability, bounce handling and list hygiene are their own topics with their own entries, and this method is upstream of all of them.

Related terms and guides

For the wider comparison of ways an address gets discovered, including the repository-based products this method sits next to, see email finder tools and, for one widely used implementation in detail, the Apollo.io email finder. The step that confirms a candidate, and what its verdicts do and do not mean, is covered in email verification tools.

The staged provider ordering that permutation opens is set out in waterfall enrichment. For building the underlying contact and domain records that permutation runs against, see custom scraping for lead generation. And because an unverified list is one of the fastest ways to damage a sending domain, email deliverability services covers what that damage looks like and who fixes it.

If you would rather see a properly resolved list run against your own market than build a permutation stack, see what a first campaign looks like.