Email aliases: what they are, how to set one up in Gmail, and when they stop scaling

An email alias is a second address that delivers into a mailbox you already have. No new login, no new storage, and in every system worth using, no new cost. Sensible aliasing is most of what separates a tidy domain from a messy one, which is why it gets its own chapter in our business email setup guide. This piece defines the terms precisely, walks the literal Gmail and Google Workspace setup, quotes the real limits with sources, and names the point where aliases quietly become the wrong tool.

Alias, mailbox, or group: get the words right first

People say "alias" for at least three different things, and the differences decide what you pay and what breaks later.

A mailbox is the expensive object: on Google Workspace or Microsoft 365 it is a paid seat. An alias is free precisely because it is nothing: a second name on the same door. A group fans one address out to many people, which sounds like teamwork until two members answer the same message twice from their personal addresses.

The Gmail +plus trick: free aliases you already own

Every Gmail address ships with infinite receive-only variants. Mail to yourname+anything@gmail.com delivers to yourname@gmail.com, so you can hand out yourname+newsletters@ or yourname+bank@ without touching a setting. Gmail also ignores dots: john.smith@ and johnsmith@ are the same account.

The tags earn their keep in filters. Match on the address you gave out:

Filter: to:(yourname+newsletters@gmail.com)
Action: Skip inbox, apply label "Newsletters"

Now the filter reality. Plenty of signup forms reject a plus sign in the email field, so the trick fails exactly where you want it most. Anyone who wants to reach your bare address can strip the tag, and list-sellers sometimes do. And the tag only sorts mail; replying from a +address takes extra send-as configuration and looks odd to the recipient anyway. Treat plus addressing as a tracer for where your address leaks, not as an identity system.

Setting up a real alias in Google Workspace, step by step

On your own domain, an alias is a two-minute admin task. The receiving half:

1. Sign in at admin.google.com (you need admin rights).
2. Go to Directory, then Users, and click the user.
3. Click User information, then Email aliases.
4. Enter the local part (the bit before the @), and click Save.

Mail to the alias now lands in that user's inbox. Google documents a limit of 30 aliases per user, at no extra cost (Google Workspace Admin Help, checked August 2026).

The sending half, so replies actually come from the alias:

1. In Gmail, click the gear, then See all settings.
2. Open Accounts and Import, find "Send mail as", and click "Add another email address".
3. Enter the alias, leave "Treat as an alias" checked, and confirm.
4. Compose or reply, and pick the alias from the From dropdown.

Because the alias lives on your own Workspace domain, this needs no SMTP details; Google sends it through its own servers. On a free @gmail.com account the same menu now demands an SMTP server, port, username, and password for any outside address, plus a verification code per address. That heavier path is part of the free-ish custom domain setup, and it is where alias enthusiasm usually goes to die.

For the record, Microsoft 365 is more generous with the ceiling: up to 400 aliases per mailbox, no extra licenses (Microsoft Learn, checked August 2026). The ceiling was never the real constraint, though, as we are about to see.

When aliases stop scaling

Aliases are a single-person tool. Three things break the moment they are asked to be more than that.

Shared visibility breaks first. Make support@ an alias of Dana's mailbox and the entire support history lives in Dana's personal account. When Dana is on holiday, support@ is a black hole. When Dana leaves, the archive leaves with her login. Nothing about an alias can be handed to a second person without handing over the whole mailbox.

Reply-from confusion breaks second. Mail to billing@ arrives in Dana's inbox looking like all her other mail. She replies without checking the From dropdown, and the customer who wrote to billing@ gets an answer from dana@. Half your correspondents now have a personal address they were never supposed to use, and the thread is split across two identities. Every send-as menu in existence relies on a human remembering to use it, on every reply, forever.

The count breaks last. Thirty slots per Workspace user sounds like plenty until every vendor, project, event, and newsletter wants its own address. Address-per-purpose is a genuinely good habit; per-user alias lists are a bad container for it.

What replaces aliases is a change of model, not a bigger limit. A shared inbox makes the address the primary object, with its own thread history that survives any one person's holiday. In our own workspace we went one step further: an address is a routing rule, not a property of a mailbox. The domain is verified once. After that, any address on it can receive (the inbound side is a catch-all, so an address exists the moment mail arrives for it), every conversation is threaded in one place the whole team can see, and a reply can go out from any address on the domain with proper In-Reply-To and References headers so it threads correctly for the recipient. We built it that way after living with per-alias verification, and there is no per-address ceremony left in the flow. Unlimited addresses is not a marketing number; it falls out of the architecture.

The rule of thumb

If one person answers an address, an alias is the right tool: free, instant, and set up in the two menus above. Give each purpose its own alias and filter on it. The day a second person needs to answer that address, stop stretching aliases and move the address into something team-shaped. Count the number of times a reply has gone out from the wrong From address this month; if it is not zero, that day already came.