KoltrixNaming team addresses: support@, hello@, billing@ and beyond
Which role-based email addresses a SaaS team needs at each stage, naming conventions that age well, where to publish each one, and the catch-all trap to avoid.
On this page(9 sections)
Team addresses are surprisingly sticky. Once support@ is printed on invoices, linked from your docs and saved in a thousand customers' contacts, renaming it is a months-long migration. A little thought now saves that later.
Use this checklist to decide which role addresses you need, what to call them, and where each one should appear.
Stage 1: Just launched
At the very start, fewer addresses is better. Every address is a place someone has to check.
- hello@ — one public address for everything: questions, feedback, partnerships, press. Friendly, and it doesn't commit you to a structure.
- Personal addresses for each founder (first name or first.last, consistent across the team).
- postmaster@ and abuse@ — reserved role addresses (more below). They can deliver to the same place as hello@.
That's it. Resist creating sales@, press@ and partners@ before anyone writes to them.
Stage 2: First customers and first hire
Once paying customers arrive, separate customer problems from everything else.
- support@ — for customers who need help. This is the address you put inside the product, in docs and in transactional email.
- hello@ stays for general inquiries, prospects, partners and press.
- billing@ (optional now, useful soon) — for invoices, receipts, payment questions and the address you give your payment processor for notices.
Splitting support@ from hello@ is the single most useful step at this stage, because it lets customer problems get a different level of attention from inbound pitches.
Stage 3: A small team with distinct functions
As people specialize, addresses can follow functions, but only where there's real volume and a distinct owner.
- sales@ — if prospects write in often enough that someone owns the response.
- security@ — for vulnerability reports and security questions from customers' security teams. Publish it on a security page.
- legal@ or privacy@ — for data requests, contracts and legal notices. Keep access narrow.
- careers@ or jobs@ — if you're hiring regularly, to keep applications out of hello@.
- partners@ — only if partnerships are an actual program.
A useful rule: create a new address only when someone will own it and the mail it attracts differs meaningfully from what's already going to an existing address.
Reserved and expected addresses
Some addresses are expected to exist on any domain that handles email, and some are defined by long-standing convention (RFC 2142 lists common role mailboxes). The ones worth setting up:
| Address | Why it exists | Where it should go |
|---|---|---|
| postmaster@ | Mail administrators contact you about delivery problems | Whoever manages your email setup |
| abuse@ | People report spam or abuse originating from your domain | Founder or ops; read it |
| security@ | Researchers report vulnerabilities | Engineering lead, narrow access |
| privacy@ | Data protection requests | Whoever owns privacy, narrow access |
You don't need a separate mailbox for each; they can deliver into an appropriate shared mailbox. But they should deliver somewhere a human reads. Mail to abuse@ or security@ is rare and occasionally very important.
Naming conventions that age well
- Use function, not person. support@, not jen-support@. People change roles; functions persist.
- Use plain English words. support@ and billing@ beat cs@, acct@ or ar@, which customers mistype or misread.
- Avoid "no-reply." A no-reply sender tells customers you don't want to hear from them, and replies to it vanish. Use a real address that someone reads, even if it's only lightly monitored.
- Keep personal addresses consistent. Pick first@ or first.last@ for everyone and stick with it. Decide now what happens when two people share a first name.
- Don't encode team structure. emea-support@ and support-tier2@ expose internals and break when you reorganize. Route internally instead.
- Watch for awkward combinations. Say the full address out loud and type it once before publishing.
Where to publish each address
| Address | Website | In the product | Docs/help center | Invoices/receipts | Transactional email |
|---|---|---|---|---|---|
| support@ | Contact page | Help menu | Yes | "Questions?" line | Reply-to |
| hello@ | Footer, contact page | No | No | No | No |
| billing@ | Pricing or billing FAQ | Billing settings | Billing articles | Yes | Reply-to for billing emails |
| sales@ | Pricing, "talk to us" | No | No | No | No |
| security@ | Security page | No | Security docs | No | No |
| privacy@ | Privacy policy | Privacy settings | No | No | No |
The principle: each audience should see one obvious address for what they need. A customer with a problem sees support@ everywhere they look. A prospect sees hello@ or sales@.
The catch-all trap
A catch-all delivers mail sent to any address on your domain, including typos like suport@ or made-up ones like ceo-private@. It sounds helpful. In practice:
- It attracts spam. Spammers send to random addresses; a catch-all accepts all of it.
- It hides mistakes. You never learn that a published address has a typo, because mail still arrives.
- It can make you look less trustworthy. Some receiving systems treat domains that accept everything with extra suspicion.
If you use one at all, use it temporarily during a migration to catch mail sent to old addresses, then turn it off. A better long-term approach is to create aliases for the specific misspellings or old names you actually see.
Mapping addresses to mailboxes
Addresses and mailboxes aren't the same thing. Several addresses can deliver to one shared mailbox:
- help@ → the support@ mailbox
- privacy@ and legal@ → one legal mailbox with narrow access
- postmaster@ and abuse@ → an ops mailbox
This keeps the number of places people check small while still giving each audience a clear address. On Koltrix, for example, you can run several team addresses on your custom domain and control access per mailbox, so the legal mailbox isn't visible to everyone who answers support.
Bottom line
- Start with hello@ and personal addresses; split out support@ when paying customers arrive.
- Add new role addresses only when there's real volume and a clear owner.
- Make sure postmaster@, abuse@ and security@ reach a human.
- Name addresses by function in plain words, and avoid no-reply senders.
- Skip the catch-all except as a short-term migration aid.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
