An email alias is an additional address that routes to an existing mailbox. It has no login, no inbox, and no storage of its own — which is why aliases are typically free and mailboxes are what you pay for. Use aliases for addresses that simply need to reach someone (hello@, careers@), for keeping personal addresses off your website, and for giving each vendor a unique address you can retire if it leaks. NevTan Mail includes unlimited aliases and groups on every plan, including the free tier.
This guide covers how aliases work, where they stop being the right tool, and how to set them up without creating a mess.
What an Alias Actually Is
An alias is a routing rule, not a container.
When mail arrives for hello@yourcompany.com, the server checks its alias map, finds that the address points to jane@yourcompany.com, and delivers it there. The message lands in Jane's inbox. The sender sees nothing unusual — as far as they know, hello@ is a normal address.
Two consequences follow, and both matter:
Aliases consume no storage. Mail is stored in the destination mailbox. This is why providers can offer them without limit while charging per mailbox.
Aliases have no independent existence. No login, no separate folders, no history of their own. Delete the destination mailbox and the alias has nowhere to deliver.
Alias, Group, or Shared Mailbox?
This is the decision that determines whether your setup works, and the three are routinely confused. Getting it wrong is the most common cause of missed customer email.
Alias | Group | Shared mailbox | |
|---|---|---|---|
What happens to mail | Routes to one existing mailbox | Copy delivered to each member's own inbox | Stored centrally in its own inbox |
Storage | None | None | Its own |
Who sees replies | Just the owner | Nobody, unless reply-all is used | Everyone with access |
Conversation history | In the owner's mailbox | Fragmented across members | Central and complete |
Cost | Free on most plans | Free on most plans | Usually consumes a mailbox |
Right for |
| Announcements, alerts, internal notifications |
|
The rule that prevents most problems: if an address just needs to reach someone, use an alias. If a message needs to reach many people, use a group. If a team needs to work an inbox together — seeing each other's replies, sharing history, avoiding duplicate responses — you need a shared mailbox, and an alias or group will not do the job.
Where this goes wrong
The classic failure is pointing a customer-facing address at multiple people via an alias or group. Say support@ delivers to five agents. Every agent gets a private copy. None of them can see whether anyone else replied. So either three people answer the same customer with slightly different information, or everyone assumes someone else took it and nobody does.
Both outcomes are visible to the customer, and neither is fixable with a better routing rule. That is a shared mailbox requirement.
Before routing customer mail through a multi-recipient address, confirm which model your provider offers. "Group" means different things across platforms, and the distinction only becomes obvious after it fails.
When to Use Aliases
Departmental addresses with a single owner. billing@ routing to your finance manager. Customers get a professional, stable address; you spend no additional money; and when the finance manager changes, you repoint the alias rather than telling the world a new address.
Keeping personal addresses off your website. Publishing jane.doe@yourcompany.com on a contact page hands attackers a named target for spear-phishing. hello@ as an alias protects the individual while still reaching her.
Name variations. People will guess j.smith@, jsmith@, and john.smith@. Aliasing the variants to one mailbox means mail arrives regardless of which they try.
Per-vendor addresses. Give each service its own alias — alias-for-vendorname@. If that address starts receiving spam, you know precisely who leaked or sold your data, and you can retire that alias without disrupting anything else. This is one of the more effective anti-spam techniques available and it costs nothing. See how spam and phishing protection works.
Temporary needs. Conference addresses, campaign addresses, seasonal contacts. Create, use, retire.
Role continuity. The address outlives the person holding the role, which is the whole point of departmental addressing.
Setting Up Aliases
1. Decide a convention before creating anything. Departmental addresses use function names (sales@, support@). Personal aliases follow one pattern consistently. Inconsistency compounds — you end up with dave@, d.kowalski@, and dkowalski@ for one person and no way to know which is authoritative.
2. Create the alias and set its destination. In your provider's admin area, add the address and point it at the mailbox that should receive it. On NevTan Mail this is managed from the admin console alongside mailboxes and groups.
3. Test it immediately. Send from an external account — a personal address works — and confirm arrival. A typo in the destination means mail silently vanishes, and you want to find that in the first minute rather than the first complaint.
4. Check send-as behaviour. Whether you can reply from the alias rather than the underlying mailbox varies by provider and matters for anything customer-facing. A customer emailing billing@ and receiving a reply from jane.doe@ is confusing, and it undermines the point of having a role address. Confirm how your provider handles this before publishing an alias externally.
5. Document it. A simple spreadsheet: address, destination, purpose, owner, date created. This takes seconds per alias and is the difference between an audit taking ten minutes or an afternoon.
6. Review quarterly. Retire what is unused. Repoint what has changed owner. Remove anything pointing at a departed employee's mailbox.
A Worked Example
A 25-person marketing agency runs everything through info@, monitored by one overloaded administrator. Messages get missed, and everything waits on one person.
What they do:
billing@ becomes an alias to the finance manager — one owner, one destination, no ambiguity. Same for press@ and careers@, each pointing at whoever owns that function.
support@ and sales@ are different. Five people work the support queue and three handle sales inquiries, and both need shared visibility so nobody double-replies to a client. These become shared team inboxes rather than aliases fanning out to individuals.
Each employee gets name-variation aliases so clients reach them whichever spelling they guess.
The cost picture: with unlimited aliases included, the departmental and variation addresses add nothing. Only the genuine shared inboxes and the individual mailboxes consume paid capacity. On NevTan Mail's per-mailbox annual pricing, 25 mailboxes on the Growth package runs $50 for the year — compared with per-seat providers charging $72 and up per user annually.
What actually improved: not the routing, but the ownership. Every address now has a named owner and a defined behaviour. The two queues that needed shared visibility got it; the sixteen addresses that only needed to reach someone became free aliases.
Choosing a Strategy by Size
Your situation | Approach |
|---|---|
Solo / freelancer | One mailbox, 2–3 aliases ( |
Small team (2–10) | Individual mailboxes, aliases per function, shared inbox only where a queue genuinely needs one |
Growing (10–50) | Formal naming convention, documented ownership, aliases for every public-facing address |
50+ | The above plus quarterly audits and a defined offboarding step for alias reassignment |
Start smaller than you think. Adding an alias takes seconds; untangling forty undocumented ones does not.
Common Mistakes
1. Creating aliases without documenting them. Undocumented addresses become orphans nobody will delete because nobody knows what breaks.
2. Not testing after creation. A typo in the destination sends mail nowhere, silently.
3. Using an alias where you need a shared mailbox. The most consequential error on this list. Multi-recipient routing for a support queue produces duplicate replies and dropped threads.
4. Routing security and account-recovery mail through aliases. Password resets, domain registrar notices, and billing alerts should go to a monitored mailbox. If an alias is deleted or repointed during a reshuffle, you can lose access to critical systems at the worst moment.
5. Leaving aliases pointing at departed employees. Mail continues flowing to a mailbox nobody monitors — or worse, one that still has an active login. Add alias reassignment to your offboarding checklist.
6. Publishing personal addresses when an alias would do. Named addresses on a public site are spear-phishing targets.
Frequently Asked Questions
What is an email alias? An additional address that routes mail to an existing mailbox. It has no login, inbox, or storage of its own — it redirects. Aliases are used to protect personal addresses, create departmental contacts, and handle name variations without paying for extra mailboxes.
How many aliases can I create?
This varies by provider. NevTan Mail includes unlimited aliases and groups on every plan, including the free tier. Where limits exist elsewhere they are usually generous — the practical constraint is how many you can maintain, not how many you can create.
Can I send email from an alias address?
This depends on whether your provider supports sending as an alias. It matters for anything customer-facing: a reply from jane.doe@ to someone who wrote to billing@ looks like a misdirect. Confirm the behaviour before publishing an alias externally.
Do aliases cost extra?
Usually not, because they consume no storage. NevTan Mail includes them on all plans at no additional cost, which is what makes them the right tool for departmental addresses — those do not need to each consume a paid mailbox.
Are aliases secure?
They introduce no new vulnerability when configured properly, and they offer a genuine security benefit: compartmentalization. A per-vendor alias that starts receiving spam identifies the source, and retiring it costs you nothing. Protect the underlying mailbox with strong authentication, since that is where the mail actually lives.
Can an alias be my primary address? Not as a standalone — it always needs a destination mailbox. But where sending-as is supported, an alias can be the address you present to the world while a differently-named mailbox holds the mail.
What happens to mail sent to a deleted alias? It bounces back to the sender as an unknown address. Before deleting anything public-facing, update your website, signatures, and any third-party tools, and consider routing it to a monitored address for a transition period.
When should I use a mailbox instead of an alias? When a person needs their own login and storage, or when a team needs to work an inbox together with shared history. Everything that only needs to reach someone can be an alias.
Conclusion
Aliases solve a specific, common problem: you need more addresses than you need inboxes. They cost nothing, they keep personal addresses private, and they let departmental contacts outlive the people currently behind them.
The judgment is knowing where they stop. An alias routes to a mailbox — it does not create a workspace. The moment a team needs shared visibility over a queue, you need a shared mailbox instead, and no amount of clever routing substitutes.
Get the distinction right, document what you create, and review it quarterly. That is genuinely the whole discipline.
NevTan Mail includes unlimited aliases and groups on every plan, alongside business email on your own domain, calendar and meetings in the inbox, role-based admin controls, TLS-encrypted connections, and guided SPF, DKIM, and DMARC setup — with 10 mailboxes at 5 GB each free forever.
