A freelance inbox is a business asset that looks like a personal one. One address takes the client brief, the invoice chase, the newsletter you joined at a conference, the note from your accountant and the alert from your hosting provider. That works until something moves. A client relationship ends, a subcontractor starts, or a contact list you were on turns up somewhere it should not be.
An alias is an address that forwards to a mailbox you already read, so you can have many addresses without running many inboxes. For personal use the appeal is usually privacy. For a business it is separation: each address can be traced back to the one place you gave it, retired on its own, or handed to a different person, without disturbing anything else you use.
This guide argues for a shared setup rather than a solo one. It covers which mail belongs on which address, what should happen to those addresses when people join and leave, and the situations where an alias is the wrong tool and you should be paying for something else.
One address per client
Give each client an address of their own: acme@yourstudio.example rather than the same hello@ for everyone. The immediate benefit is that the address becomes evidence. Client contact lists get exported into CRMs, shared with agencies you never meet, and occasionally copied out of a system that was breached. When mail from strangers starts arriving at an address only one client ever had, you know which relationship leaked, and you can close that address on its own. Everything else keeps working.
The quieter benefit is the handover. Work ends, and a per-client address lets you decide what ending it means. Keep forwarding for six months while stragglers find you, then switch the address off. Or, if the account is passing to another supplier, point the address at them for a transition period and stop. A single shared address gives you no way to do either without breaking mail from everybody else.
Use names you can say out loud on a call, and keep a record of which address went to which client. A year later, an address whose origin you cannot remember is much less useful.
An address on your own domain
The professional argument is easy to overstate, and there is no survey worth quoting here on how prospects react to a free-mail address. What can be said plainly is what the domain gives you. An address at your own domain is a name you own. If your mail provider disappoints you, you move the domain and the addresses come with you. A free-mail address sits in somebody else's namespace and cannot move at all, which means every place you have ever printed it is hostage to that provider's decisions.
The domain also lets you run any number of addresses under one identity, which is what makes the rest of this possible. Custom domain support is the difference between a handful of masks and an address plan, and it puts you in charge of the records that authorise sending, so mail claiming to come from your business can be checked against what you published.
Role addresses that outlive the person
Role addresses are an old idea. RFC 2142, published in 1997, specifies the basic set of mailbox names an organisation should support, including info, sales, support, abuse and postmaster, so that mail sent to one of them reaches a recipient appropriate for that service or role. For a business of one that can look like a formality. It stops looking like one the first time the person changes.
Role addresses matter because they get printed. An address on an invoice template travels into a client's accounting system, gets typed into a supplier record, sits in a signed contract and appears on a website that stays cached for years. If that address carries your personal name, every one of those copies is wrong the day you hire a bookkeeper, and you will be forwarding stray invoices by hand for years afterwards. If it is billing@, you repoint it at whoever handles billing this quarter and nothing outside your own account has to change.
Keep the set small. hello@ for anything public, billing@ for money, and one address per function you genuinely have. Role addresses created optimistically and never watched are worse than none, because people write to them and get silence.
Subcontractors and short engagements
This is where a shared setup earns its cost. You bring in a designer for eight weeks. They need to receive client mail about their part of the job, and they probably need to send from an address that belongs to your business rather than one that announces the work was subcontracted. The obvious options are poor. Sharing your mailbox password gives them everything you have ever received. A full mailbox for a two-month engagement means paying for a seat and then negotiating over what happens to the archive.
An alias on your domain, forwarded to the subcontractor's own inbox, fits the shape of the work. They read mail for that address wherever they already read mail. They never touch your inbox, your archive or your other clients. Replying needs no setup on their side: the reply address is rewritten on every forward, so an ordinary Reply leaves as the business address. Brief them on two things. Reply All is the documented exception, because the other people already on the thread are ordinary addresses in their mail app, so replies to them go out from their real account, which is the disclosure you were trying to avoid; tell them to hit Reply and add recipients rather than Reply All. Starting a new conversation from the address is the other case, and that does need a per-alias sending credential, separate from yours and revocable on its own.
The end of the engagement is what you should be choosing a service on. When someone leaves a team, a well-designed service transfers their addresses on the company's domain back to the owner rather than deleting them. That distinction is not cosmetic. Mail arrives late: a supplier answers in November about something from September, an old client comes back with more work, a service they registered sends a password reset. If the address was deleted, all of that fails at the door and the sender is told there is no such person. If it was transferred, it keeps arriving, and it arrives to you.
The transfer should also take something away from the person leaving. On handover, the address's forwarding destinations should be cleared, so it no longer points at their personal inbox, and its sending password should be cleared too, so nobody can send as your domain using a credential you have forgotten about. The address survives; their control of it does not. Ask any service you are considering that exact question, because "we delete their aliases" and "we transfer them and cut the keys" are very different products behind the same feature name.
The same care applies when you shrink. If you drop to a smaller plan after a busy quarter, a service that pauses seats over the new allowance, newest member first, is much safer than one that removes them: the longest-standing people keep working, a paused member keeps everything except the inherited plan, and the arrangement comes back when you do. Agree in writing, separately, which accounts a subcontractor may register using an address on your domain. Controlling the address means you can recover those accounts later, but you would rather not have to.
Where an alias is the wrong tool
An alias is one address that routes mail. It is not a shared mailbox and it is not a helpdesk, and pretending otherwise causes problems in front of clients. Point one address at two people and each of them gets a private copy. Neither can see whether the other has answered, and although each reply goes back out as the alias rather than from a personal address, the sent copies land in two archives nobody else can search. The client gets two answers to one question, or none, because each of you assumed the other had it.
When responsibility is genuinely shared inside a thread, buy the right thing. A Microsoft 365 shared mailbox is a mailbox several people open, where a reply appears to come from the shared address rather than the person who typed it, and it includes a shared calendar. A Google Groups Collaborative Inbox lets members assign a conversation to someone, mark it complete or a duplicate, and apply labels. Both give you the shared state that forwarding cannot: one history, one record of what was said, and a way to see who is holding it.
The dividing line is easy to apply. If one person is responsible for an address at any given time, and the address needs to outlive that person, use an alias. If two people have to work the same conversation, use a shared inbox and keep aliases for everything else.
| Situation | Right address type | Why |
|---|---|---|
| A new client engagement | Per-client alias on your domain | Traceable if it leaks, closable at the end |
| Invoices and accounting | billing@ role alias | Printed on documents; must outlive the person |
| Enquiries from your website | hello@ or info@ role alias | Public, replaceable, easy to filter |
| Subcontractor on a short job | Alias on your domain, forwarded to them | No access to your inbox; returns to you at the end |
| Two people working one queue | Shared mailbox or helpdesk | Needs assignment and a single history |
| Bank, tax authority, registrar | Plain mailbox, no forwarding | A missed notice is expensive and slow to undo |
| Newsletters and vendor trials | Disposable alias on a shared domain | Kill it the moment it attracts spam |
What not to route through an alias
Some accounts belong on a plain mailbox with no forwarding in front of them. The tiering rule for bank accounts extends cleanly from personal finances to a business: where a failed delivery is expensive and the recovery path is slow, take the boring option. That covers the company bank, the tax authority, the processor that pays you, and anything that can freeze money or issue a penalty over a notice you never saw.
The domain registrar deserves its own warning, because it creates a loop. Registrars send renewal and expiry notices to the contact recorded on the domain; Cloudflare's registrar documentation, for instance, describes expiration notices going to the WHOIS registrant contact. If that contact address is an alias hosted on the same domain, then the moment the domain lapses the warnings about the lapse stop arriving, along with every other address you run. Register domains against a mailbox somewhere else entirely, and read it.
A setup order for one person
If you are starting from a single overloaded address, this order works. Each step stands on its own, so you can stop after any of them, and an hour is enough for most of it.
- Set up one plain mailbox, with no aliases in front of it, for the registrar, the bank and the tax authority. Do this first so you are never tempted to route those through anything.
- Point your domain at an alias service and finish the DNS records, including the ones that authorise sending, before you print the address anywhere.
- Create the role addresses next, hello@ and billing@ at minimum, and put them on the invoice template, the website and your signature the same afternoon.
- Create a per-client address as each engagement starts, and give it to the client in the kickoff message so it becomes the natural reply-to.
- Move existing signups gradually, changing the address when a service next makes you log in rather than in one long evening.
- Add people only when the work needs it, and settle the leaving rule before the first person joins.
- Keep a one-page list of every address, who reads it and why it exists.
None of this is elaborate. It is one address per relationship, a few addresses named after jobs rather than people, and a clear answer to what happens on the day somebody leaves. The value shows up later, on the day you would otherwise be forwarding mail by hand or explaining to a client why their invoice went nowhere.