Professional email address: formats that earn trust
Pick one format and never mix. Own five role addresses. Stop sending from noreply@. The rest of this article is the reasoning and the edge cases.
Use first@yourdomain.com while your company is small, and first.last@yourdomain.com once a name collision becomes plausible. That one decision settles most of this topic, so the rest of this article covers what it does not: the role addresses every business needs, the formats that quietly cost you trust, and the edge rules around dots, hyphens, and unicode.
The domain does the work
An address is two parts, and the right-hand side does the heavy lifting. maya@atelier-north.com says there is a company; mayadesigns1988@gmail.com says there is a hobby. Prospects check the domain, not the spelling of your first name. So before debating formats, get on a domain you control, with SPF and DKIM authenticating it; our business email setup guide walks the whole path from DNS to inbox. The stakes rose recently: Gmail (November 2025) and Microsoft (May 2025) now hard-reject unauthenticated mail with a 550 error rather than filing it under spam.
Once the domain is yours, addresses stop being scarce. On our own stack an address is a routing rule, not a mailbox you pay for, so the only real question left is what the pattern should be.
Person address formats: our positions
Format guides usually list options and refuse to choose. Here is what we would actually do, with the tradeoff named.
| Format | Example | Our position |
|---|---|---|
| first@ | maya@ | Best under about 20 people. Short, warm, easy to say aloud. The tradeoff is collisions: the second Maya you hire breaks the pattern. |
| first.last@ | maya.chen@ | The default for a company that intends to grow. Survives collisions and stays guessable. One character longer to type, forever. |
| flast@ | mchen@ | Avoid. Fails the phone test ("m as in... what?") and produces accidental words often enough that IT departments keep blocklists for it. |
| initials | mc@ | Avoid. Unreadable to outsiders and exhausted after a few hires. |
| firstlast@ | mayachen@ | Acceptable for short names; long names turn into a wall of letters people mis-segment. |
| first_last@ | maya_chen@ | The low-line separator gets misheard as a space on calls and looks off in print. The dot does the same job better. |
| name plus number | maya2@ | Never. Numbers in a business address read like a burner account. If you hit a collision, that is the signal to move the whole company to first.last@. |
The phone test is the honest referee here: read the address aloud, once, to someone who cannot see your screen. If they need it repeated or spelled, the format failed. first@ and first.last@ pass. Almost nothing else does.
Whatever you choose, apply it to everyone, founders included. A team where the CEO is james@ but new hires are j.smith@ broadcasts a two-tier culture in the email directory.
The role addresses every business needs
People guess role addresses when they do not know a name, so owning the standard set is free surface area. Five cover most businesses.
| Address | What lands there | Who should watch it |
|---|---|---|
| hello@ | General inquiries, partnership feelers, humans guessing | A founder early on; whoever owns first impressions later |
| sales@ | Money trying to reach you | Whoever owns revenue, with a same-day reply habit |
| support@ | Customers with problems | The whole team, visibly; rotate the duty, share the history |
| billing@ | Invoices, receipts, disputes | Whoever pays the bills and chases the invoices |
| press@ | Journalists, usually on deadline | A founder, directly; press mail expires in hours, not days |
Two rules make these work. First, every role address needs a named owner, because an address everyone watches is an address nobody answers. Second, role addresses should be readable by more than one person from day one; the mechanics of that (Google Groups, delegation, shared mailboxes, or a workspace where every address is shared by default) are the subject of our shared inbox guide.
On a setup with unlimited addresses these five cost nothing to create, and you can add narrower ones (careers@, security@, partners@) the day you need them. Aliases make the same point at the personal level.
Addresses that hurt trust
info@ is the one we would retire. It is the default that nobody owns, and the address a dictionary spray tries first, which is why our own list-hygiene rules bar role accounts (info@, admin@, postmaster@, abuse@) from a newsletter list. They signal a distribution list, not a person. When your public contact is info@, you are telling people their message goes onto a pile. hello@ receives the identical mail and implies a human will read it. Same function, better promise.
Do not send from noreply@. This one costs you twice. The first cost is stated plainly in the name: you are emailing customers while announcing you will not listen. The second cost is mechanical. Mailbox providers rank engagement signals in a clear order (replies above clicks, clicks above opens), and a From address that cannot receive replies sets your strongest reputation signal to zero by design. Every address you send from should be one a human reads. If the volume worries you, that is a filtering problem inside your inbox, not a reason to slam the door on the sender's side.
The rest of the trust-killers, briefly: admin@ and office@ as outward identities (internal plumbing, not a face), cutesy addresses (topdog@, duckboss@) outside brands where whimsy is the product, and any abbreviation your own staff have to look up.
Business email address examples by company type
| Company type | Person pattern | Role addresses | Example set |
|---|---|---|---|
| Freelancer | first@ | hello@, billing@ | sam@okafor.design, hello@okafor.design |
| Agency, ~12 people | first.last@ | hello@, newbusiness@, billing@ | lena.ortiz@studionorth.co, newbusiness@studionorth.co |
| SaaS startup | first@ | support@, sales@, security@ | priya@shipmate.app, security@shipmate.app |
| Law firm | first.last@ | reception@, billing@ | d.whitfield@whitfieldlaw.co.uk, reception@whitfieldlaw.co.uk |
| Restaurant or local shop | first@ | hello@, bookings@ | marco@osteriaverde.com, bookings@osteriaverde.com |
| Media site | first.last@ | tips@, press@, corrections@ | june.park@thelocalledger.com, tips@thelocalledger.com |
Patterns worth noticing: client-facing professions stay formal (a law firm on first.last@ reads as intended), hospitality stays warm (first@ suits a business built on a person's name), and a media site's tips@ and corrections@ are trust signals in themselves.
Edge rules: dots, hyphens, unicode
Dots. Google famously ignores dots on @gmail.com addresses; m.aya and maya reach the same account there, and Google documents this. On your own domain that guarantee does not exist: maya.chen@ and mayachen@ are distinct addresses on most mail servers. Pick one form, publish it consistently, and if you expect people to guess wrong, run a catch-all so misremembered variants still arrive.
Case. RFC 5321 technically permits case-sensitive local parts, but no serious provider treats Maya@ and maya@ differently. Publish lowercase anyway; it removes the question.
Length. The local part maxes out at 64 characters (RFC 5321). If a business address is anywhere near that limit, something has gone wrong upstream of the RFC.
Hyphens. Legal, and best avoided in local parts: "maya hyphen chen at" survives dictation worse than the dot does. Hyphens in the domain itself are fine when the unhyphenated name is taken.
Unicode. RFC 6531 (2012) allows UTF-8 addresses, so josé@ and 田中@ are technically valid. Support remains uneven across providers, web forms, and CRMs, and one broken form is one lost lead. Our position: keep business addresses ASCII, whatever the brand name looks like.
Plus addressing. maya+invoices@ style tags are useful for filtering your own mail, and plenty of web forms reject the + sign. Treat them as a private tool, never as a published address.
Do this today
Pick the pattern: first@ if headcount is under 20 and you accept the collision risk, first.last@ if you would rather never migrate. Create the five role addresses and write a name next to each one. Retire info@ in favor of hello@, and delete noreply@ from every template it still haunts. The whole exercise takes an afternoon, and it is the cheapest credibility upgrade a small company can buy.