Google Workspace Alias vs Group vs User Account: Which to Create

Every Google Workspace admin runs into this question. Sales needs a sales@ address. Billing wants billing@. HR asks for careers@. There are three genuinely different ways to stand each one up — an email alias, a Google Group, or a full paid user account — and picking the wrong one costs money for the life of the address, or worse, forces a migration in six months when history has piled up in the wrong place.

The three mechanisms are not tiers of the same thing. They differ on who can reply, whether incoming mail is shared, whether history is kept, and whether the address costs a license. This page walks all three, honestly, with the licensing consequence as the deciding axis. Verify current alias limits and Groups-for-Business behaviour against Google's own documentation before you commit — those defaults have moved before.

The verdict, up front#

For a shared address that one person actually owns and answers — a founder's press@, a sole bookkeeper's billing@ — use an email alias on that user's account. Aliases are free, take a minute to add, and Google allows up to 30 of them per user. The one thing you have to do is enable a Send-mail-as entry in Gmail so replies leave from the alias instead of the user's primary address; without that step, replies go out from the wrong sender and the answer looks strange to the customer.

For a shared address that a team answers, and where everyone needs to see the incoming mail, use a Google Group with Collaborative Inbox enabled. Groups are included with Workspace, do not require a license per member, and — with Collaborative Inbox turned on — behave like a lightweight shared mailbox: members can assign a thread, mark it complete, and reply from the group address. The trade is that Groups are a coarser tool than a real helpdesk, and history lives on the group rather than in any individual mailbox.

For a shared address that needs a real mailbox — its own quota, its own Drive, its own calendar, retention rules distinct from any human's — create a paid user account. This is the only option that costs money per seat and it is the only one that gives you a mailbox in the strict sense. Reach for it when the address will outlive the people who currently answer it, when you need Vault retention or e-discovery scoped to that address, or when the shared history is the asset you cannot afford to lose.

If you have no idea which fits your case yet, the table and the three sections that follow are what decides it.

At a glance: alias vs group vs user account#

The dimensions below are the ones that actually decide the pick. Feature checklists in vendor comparisons tend to blur them together; the choice is usually made on two or three rows.

When an alias is the right answer#

An alias is a second name for a mailbox that already exists. Add sales@ as an alias on your founder's user account and every message sent to sales@ drops into that founder's inbox alongside their own mail. There is no new login, no new license, and — from Google's side — nothing else to configure.

Two things trip people up. The first is replies. By default, when the founder replies to a message that arrived at sales@, Gmail sends the reply from their own address, not from sales@. That looks wrong to the customer and, over time, teaches them to write to the founder directly. The fix is a one-time Send-mail-as entry in the founder's Gmail settings for sales@, after which Gmail asks which address to send from on every reply and defaults to the alias when replying to alias mail. If you skip this step, the alias is functionally broken — mail arrives, but the outbound half of the conversation loses the alias identity.

The second is the 30-per-user cap. Google documents up to 30 aliases per Workspace user at no extra cost; anything past that requires a second user account. In practice the cap almost never bites for a real business, but consultancies that spin up a new client-facing alias for every engagement do hit it, and finding out at the moment you need alias 31 is a bad afternoon.

An alias is the wrong answer the moment two people need to answer the same address. There is no clean way to route one alias to two mailboxes — the Google-supported path for that is a Group, not multiple aliases pointing at multiple users. Trying to fake it with forwarders is where inboxes go to die.

When a Google Group is the right answer#

A Google Group is a shared address that has members. Mail sent to support@ lands on the group, every member sees it, and — with Collaborative Inbox enabled in the group's settings — members can assign a conversation to a specific teammate, mark it complete, duplicate or requires-no-action, and reply from the group address rather than from their own. That is a lightweight shared-mailbox pattern that costs nothing per member and works today.

The reason Groups keeps winning this decision for support@, contact@ and hello@ is licensing. Add ten teammates to sales@ as a group, and there is no per-seat cost for the group itself; the ten members are already Workspace users you were paying for anyway. Turn the same address into a paid user account and delegate it to the same ten people, and you have added a real seat cost that recurs monthly forever.

Groups is a coarser tool than a full helpdesk. There is no SLA timer, no round-robin assignment, no CSAT and no built-in reporting. Duplicate detection is manual — a member marks a conversation as duplicate and it locks — and threading is Google Groups threading, which follows subject and headers rather than a ticket ID. If any of that sounds insufficient for the volume you actually run, you have outgrown Groups and the honest answer is a helpdesk product, not a paid user account pretending to be one.

Two prerequisites to confirm before committing. Collaborative Inbox is a group setting that a group owner or manager has to switch on, and it requires Groups for Business to be enabled at the domain level. Neither is default in every plan, and both are quick to verify in the Admin console. Google's Groups Help page is the source of truth for the exact toggles by SKU.

When a paid user account is the right answer#

A paid user account is the option a lot of admins reach for first because it feels the most correct, and it is usually the wrong answer for that reason. Do reach for it when the address genuinely needs to be a mailbox — its own quota that will not eat into a human's, its own Drive files that outlast whoever is currently answering, its own calendar for booking, its own Vault retention scoped to just that address, or an eventual login for an integration that expects to authenticate as the mailbox rather than as a person.

The classic case is an address that will outlive the people who currently staff it. accounting@ at a company with turnover in the finance function should not be an alias on one bookkeeper's mailbox, because when that bookkeeper leaves you have to decide whether to keep their whole account alive for the sake of the alias's history. Making accounting@ its own user account from the start is boring, costs one seat, and makes offboarding a non-event.

The other case is when an address is legally distinct — subject to specific retention, discovery, or supervisory rules — and mixing its mail into anyone else's inbox is a compliance problem. For most SMBs this does not apply. For regulated firms it decides the choice on its own.

Everywhere else, spinning up a paid user account for a shared address is spending real money to solve a problem a free group would solve better. It also creates the shared-password anti-pattern where five people rotate through a single set of credentials — the reason Google introduced Groups' Collaborative Inbox in the first place.

Pricing model, not prices#

No numbers below. Google reprices Workspace, and third parties reprice against it, often enough that a figure in this post ages within weeks. What is durable is the packaging shape, and shape is what you should be picking against.

Aliases and Groups are included in every paid Workspace tier at no additional cost. There is no per-alias fee and no per-group-member fee. Business Starter through Enterprise all ship them; the differences that matter across tiers are storage per user, Vault availability, and admin controls, not whether aliases or groups exist. Verify the alias cap and Collaborative Inbox eligibility for your specific SKU on workspace.google.com/pricing before you commit.

A paid user account, by contrast, costs one full seat regardless of whether a human logs into it or it exists purely to hold accounting@. Google does not sell a discounted seat for shared or role-based addresses. That is the entire reason the alias-vs-group-vs-user decision has a licensing consequence: it is the difference between spending nothing and spending one seat a month, forever, for each shared address.

AI Emaily is not a Workspace admin tool and does not price aliases, groups or user accounts — we are a client on top of whichever identity you set up. Our own packaging is a 7-day free trial on Pro and Autopilot plans (card required, $0 if cancelled before day 7), not a permanent free tier. Current tiers live at aiemaily.com/pricing.

Who each is genuinely for#

Feature grids do not decide this. Team shape, whether history has to be shared, and licensing pressure do. The table below is the compressed version of the three sections above.

A third option, honestly: delegation on a paid account#

There is a fourth pattern that combines two of the above and is worth naming so you do not reinvent it. Create the paid user account, then delegate access to it from the Gmail settings of every teammate who needs to answer. Each delegate sees the shared mailbox in their own Gmail as a second account, can read and reply on its behalf, and Gmail marks replies as sent-by-them-on-behalf-of the shared address.

This gets you shared history plus a real mailbox plus multiple people replying, at the cost of one seat. It sounds like the best of both worlds and for a specific case — a small team that needs the mailbox properties (quota, Drive, Vault) but also needs collaborative answering — it is. The trade-offs are that Gmail delegation is capped (Google documents up to 25 delegates per account, verify current limits), the on-behalf-of header is visible to recipients unless you configure Send-mail-as carefully, and delegates cannot chat or do everything an owner can.

Delegation is the right upgrade when a Group starts to feel too coarse and you have found a specific reason you need the mailbox properties — not the default first move. If your reason for wanting delegation is really shared history, a Group already gives you that for free.

Where AI Emaily fits — and where it does not#

AI Emaily is not an alternative to any of the three mechanisms above. It is a mail client with an AI agent, and Google Workspace's identity model — who owns the address, who receives its mail, who can reply from it — is set by Google, not by us. Whichever mechanism you pick, the mail lands where Google says it lands, and AI Emaily connects to that account and triages what arrives.

The adjacent thing we actually do: once sales@ or support@ is live, AI Emaily categorises incoming threads, drafts replies in a voice you configure through a Personal Context brain and per-client profiles (not by scanning your archive), and — in Copilot mode — never sends anything without your explicit approval. Autopilot is available with a full undo and an audit log you can read. That is a client-side triage layer on top of whichever identity you chose; it does not change the identity itself.

Where AI Emaily is the wrong tool: if your problem is that sales@ needs to be a group and it is currently an overloaded personal alias, no client fixes that. Fix it at the Workspace layer first with one of the three mechanisms above, then decide whether the volume warrants an AI layer on the resulting account. We build AI Emaily; on any post that names us we say so.