Company Email Address Format: How to Find It and Verify It (2026)

On this pagev

• The format guess fails more often than it works
• Find one real address before you infer anything
• Infer the pattern from the address you found
• Confirm the address with an SMTP handshake
• Handle catch-all, timeouts, and silent servers
• Where a tool helps and where it does not
• Key takeaways

Guessing first.last@ would have matched the dominant pattern in only 15.7% of 70 domains with one identifiable format in our benchmark from 2026-03-19 to 2026-07-05. Find one real address on the public web, infer the pattern from that address, then confirm any new address with a live SMTP handshake before you send. That check matters because 141 of 211 resolved domains in the same benchmark were catch-all, so an acceptance from those servers proves nothing about a person. If the server gives no clear verdict, label the result catch-all or unknown and find another route to the person instead of sending to a guess.

We build Kustiq, the product mentioned near the end of this post. The manual method below works without it, and every benchmark figure here comes with its sample size so you can judge the evidence yourself.

The format guess fails more often than it works

Sales advice usually treats first.last@ as the default corporate pattern. Our probe data says that default is weak. We published the full method and caveats in our catch-all email benchmark, built from 3,508 recorded SMTP probe outcomes across 4,127 processed contacts. Within that sample, only 70 domains of 211 resolved domains had one identifiable email format. The rest either accepted everything or never gave a verdict clean enough to name a pattern.

The distribution across those 70 domains is nearly flat. The leading format holds 15.7% of 70 domains. The top three formats together cover about 40% of 70 domains. A guess based on the leader is therefore right roughly one time in six, using 70 domains as the base. The remaining formats split the rest in small slices.

That table shows why guessing fails. Trying every row against a mail server counts as probing, and servers notice repeated failed lookups. Some throttle the connection. Some block the probing address entirely. One genuine address from the target domain reduces the whole table to a single candidate pattern, so look for that address first.

The catch-all problem sits on top of the guessing problem. A catch-all domain accepts mail for any local part, real or invented. That applied to 141 of 211 resolved domains in our sample. On those domains, a guessed address looks valid even when nobody owns it. Your message then lands nowhere useful, or bounces later in ways that hurt sender reputation. Format knowledge alone cannot solve that. You need a server verdict, and you need to know when no verdict is possible.

Find one real address before you infer anything

Start with evidence. You need a single address that the company itself has published, or that an employee has used in public. Several source types work well.

• Press and media pages. Companies list a named contact for journalists often. Author bylines on the company blog serve the same purpose.
• Email signatures in public archives. Mailing list posts often preserve full signatures with direct addresses. Old posts still reveal the pattern even when the person has moved on.
• PDFs indexed by search engines. Conference agendas name speakers with work addresses. White papers and event programmes do the same.
• GitHub commit history. Commits carry an author email. Use only commits where that email sits on the corporate domain, since personal addresses reveal nothing about company format.
• Conference and association listings. Speaker directories and member rosters often print a direct work address next to a name you can match.

Search with the domain in quotes. A query shaped like "@example.com" on its own returns pages that print addresses verbatim. Adding a job title narrows the field. Adding a filetype filter finds documents that websites bury. We walk through more of these searches in our guide on how to find someone's business email.

Judge the quality of what you find. A role address such as press@ or info@ tells you nothing about personal format. You need an address built from a person's name. Confirm that the name beside it matches the local part. A signature block does this best, because the printed name sits directly above the address.

One address is useful, and two addresses that follow the same pattern give stronger evidence. A single example might be an exception a company created for a founder years ago. Two matching examples from different people suggest a company-wide rule. If your two examples disagree, the company may have changed formats over time. Prefer the more recent example in that case.

Hold on to the source page. Note where you found the address and when the page was published. That note helps later if a colleague asks why you trusted the pattern. It also helps you avoid repeating the same search for the next contact at that company.

Infer the pattern from the address you found

Read the local part next. The local part is everything before the @ sign. Compare it against the person's full name. Work out which pieces of the name appear and in what order. Note the separator, if any. A dot, a hyphen, and an underscore produce different addresses even when the name pieces match.

Take a concrete case. Suppose you found jane.doe@ on a press page next to the name Jane Doe. The pattern uses the full first name and the full surname. A dot separates them. For a colleague named Mark Reed, the candidate address becomes mark.reed@ on the same domain. Treat that candidate as a hypothesis until a server verifies it.

Several traps catch people at this stage.

• Nicknames. Robert may publish as bob@ while the directory lists him as Robert. The published address wins, so check how the person refers to themselves.
• Hyphenated surnames. Some companies keep the hyphen. Others drop it or replace it with a dot. Only a second example with a similar surname settles this.
• Initial collisions. A short format like jdoe@ runs out of combinations. Later hires often get a longer variant. The pattern you found may be the older one.
• Middle initials. A few firms insert a middle initial to break ties. You cannot guess that initial from a name alone.
• Changed names. People marry and change surnames. Companies rarely update an existing mailbox. A current surname can produce a wrong candidate.

Write the candidate down as a candidate. Keep it separate from addresses you have actually seen published, because that separation prevents a list built from guesses from being treated later as a list built from evidence. The next stage closes that gap.

Confirm the address with an SMTP handshake

Verification happens at the receiving server. SMTP is the protocol mail servers use to accept messages. A handshake walks through the opening steps of a delivery and then stops before any message is sent. Our separate explainer on how to verify an email without sending covers the protocol in more depth.

First, look up the MX records for the domain. Those records name the servers that accept mail for it. No MX record usually means the domain no longer advertises a mail server (a few domains fall back to their A record, as RFC 5321 allows), so treat the candidate as dead until a direct connection proves otherwise. Next, connect to one of those servers and introduce yourself. Then state a sender address. Finally, present your candidate as the intended recipient with the RCPT TO command. The server replies. An acceptance means the server would take mail for that address. A refusal means no such mailbox exists there. You disconnect without sending anything.

Run one extra probe before you rely on the acceptance. Present an invented local part at the same domain, built from a long random string. If the server refuses the invented address and accepted yours, the domain distinguishes real mailboxes from fake ones, and your acceptance means something. If the server accepts the invented address too, the domain is catch-all, and your acceptance means nothing on its own.

Our probe outcomes show how often servers answer at all. Only 617 probes of 3,508 recorded probe outcomes produced a definitive server verdict. Timeouts swallowed the rest, along with proxy outages on our side. The verdicts we did get split as follows.

The remaining 5 probes of 617 probes were flagged as catch-all at probe time. Note what the accepted share hides. Those probes ran against addresses our pipeline had already researched, so the sample skewed toward plausible mailboxes. Cold guesses would draw more refusals.

Turn the verdict into a decision.

• Accepted, and the invented address was refused. Send with reasonable confidence.
• Refused. Do not send. Your inferred pattern or your spelling of the name is wrong.
• Accepted, and the invented address was accepted too. Label it catch-all. Decide based on how much a bounce would cost you.
• No reply at all. Label it unknown. Retry later or find another route to the person.

Handle catch-all, timeouts, and silent servers

Many servers refuse to cooperate with probes. Large providers guard their directories by design. Some accept every recipient during the handshake and bounce later. Some delay replies to slow down automated checks. Some block connections from address ranges associated with bulk probing. A silent server tells you nothing about the mailbox, so treat silence as unknown and never as a soft yes.

Platform behaviour differed sharply in our data. Google Workspace produced a confirmed deliverable result for 273 of 1,729 processed contacts, or 15.8%. Microsoft 365 produced a confirmed deliverable result for 115 of 1,166 processed contacts, or 9.9%. Proofpoint produced a confirmed deliverable result for 16 of 143 processed contacts, or 11.2%. Mimecast produced a confirmed deliverable result for 5 of 154 processed contacts, or 3.3%.

Read those shares carefully. Infrastructure failures sit inside every denominator across 4,127 processed contacts. The low confirmed shares mostly reflect how rarely a probe got a clean answer. They do not mean the other mailboxes were invalid. Filtering gateways such as Mimecast answer probes less often by design. Expect more unknowns when your targets sit behind one.

Two caveats bound everything above. The sample came from our own outbound funnel of 4,127 processed contacts, aimed at SMB and mid-market companies. It describes that world, not the whole internet. Timeouts and proxy outages also left 2,860 of 3,508 recorded probe outcomes without a mailbox verdict. With that much missing data, we publish no industry breakdown. Anyone quoting you a universal format statistic owes you the same honesty about their sample.

A few habits keep the labels honest. Probe once and record the verdict with its date, because repeat probing of the same server adds noise and risks a block. Store the label beside the address, so no one upgrades catch-all and unknown results without new evidence. Re-check old addresses before a big send, since mailboxes close when people leave and a verdict from last year describes a server that may have changed since.

Where a tool helps and where it does not

The manual loop above takes minutes per company. That is fine for a short target list. It breaks down when you work through a market. Our own product enters at this point, and we build Kustiq. Judge the workflow claim below against the manual method you just read.

Kustiq runs the same loop in one step. You paste a company domain. It builds a company profile at request time. It identifies a decision maker at that company. It then checks the resulting address with a live SMTP RCPT TO handshake at delivery. The contact comes back only after that handshake accepts. Catch-all results stay labeled as catch-all and never count as verified. That labelling rule matters more than the automation, because a tool that promotes catch-all acceptances into verified contacts gives you confidence you have not earned.

Know the limits before you pay for any tool, ours included. No tool can extract a verdict from a server that refuses to answer. No tool can verify a specific mailbox on a catch-all domain through SMTP alone. On those domains the honest output is a label saying so. A vendor promising full verification everywhere promises certainty that the protocol does not offer. Ask any vendor how they report catch-all domains. Ask what share of their results come back unknown. If a vendor will not answer either question, treat that refusal as a warning.

Keep doing some work manually even with a tool. Spot-check a few results against the public web yourself. Check that the person still works at the company. Read the company profile before you write anything. The correct format gets your message to the mailbox, and a relevant message gives the recipient a reason to read it.

Key takeaways

• The leading format held only 15.7% of 70 domains with one identifiable format from 2026-03-19 to 2026-07-05, so guessing the pattern is a weak strategy.
• One real published address turns a table of possibilities into a single testable candidate.
• A live SMTP handshake confirms or refuses a candidate without sending a message.
• Catch-all domains covered 141 of 211 resolved domains in our sample, and acceptances there verify nothing.
• Unknown and catch-all labels protect your sender reputation better than hopeful sending ever will.

Frequently Asked Questions

What is the most common business email format?

The most common single format was first.last in 70 domains with one identifiable format from 2026-03-19 to 2026-07-05. Its share stayed small, so treating it as a default guess fails far more often than it succeeds.

How do I find the email format for a specific company?

You find one real address that the company or an employee has published on the public web. Press pages and conference listings work well, and a second matching address makes the inferred pattern much safer.

Can I verify a guessed address without sending an email?

An SMTP handshake checks a recipient with the receiving server and stops before any message is sent. You should also probe an invented address at the same domain, because a catch-all server accepts both and verifies neither.

What does catch-all mean for my outreach?

A catch-all server accepts mail for any local part, including names that belong to nobody. Addresses on those domains need a catch-all label rather than a verified label, and high volume sending to them risks bounces and reputation damage.

Does Kustiq guess email formats?

Kustiq returns a contact only after a live SMTP handshake accepts the address at delivery. Catch-all outcomes stay labeled as catch-all instead of being counted as verified, which keeps guesswork out of the verified column.