Google Workspace admin guide
The right email address type prevents future access and ownership problems.
Small teams should not create a paid mailbox for every public address. Decide what should be a user, alias, group, or shared workflow before customers start sending business-critical mail.
Google Workspace gives you several ways to create and route email addresses. The choice matters because it affects billing, privacy, handover, customer visibility, and what happens when someone leaves.
A messy setup usually starts with good intentions: create info@, sales@, support@, billing@, and admin@ as separate mailboxes because they look professional. Six months later, nobody knows which inbox contains the lead, who owns the password, or whether a former employee still has access.
Decision rule
Quick answer
Use this model:
Workspace address decision table
| Address type | Use when | Example | Notes |
|---|---|---|---|
| User | A person needs login, inbox, calendar, Drive, and account lifecycle | [email protected] | Usually paid license |
| Alias | One user should receive mail for another name | [email protected] -> owner inbox | Google documents aliases as alternate email addresses for a user |
| Group | Multiple people need team-owned mail | [email protected] | Good for sales, support, accounts, operations |
| Collaborative inbox | Team needs assignment and conversation handling | [email protected] | Uses Google Groups features |
| Temporary address | Migration, launch, or testing only | [email protected] | Add expiry or review date |
Google's alias documentation says administrators can create alternate email addresses for users and notes a limit of up to 30 aliases per user at no extra cost. Confirm current limits in Google's documentation before designing a large alias structure: Add or delete an alternate email address.
Users vs aliases vs groups
Create a user when the address represents a real login owner. Users are best for people who need private mail, calendar, Drive, authentication, account recovery, and device access.
Use aliases when an address is just another name for one mailbox. For example, a founder may receive owner@, founder@, and hello@ in one inbox during the first stage of the business. That does not mean each address needs a paid mailbox.
Use groups when the address belongs to a team. [email protected] should not live permanently inside one employee's private inbox if the business expects continuity. Groups can route mail to members, allow external senders if configured, and help the business manage access as people join or leave.
Avoid unnecessary paid users
Public labels such as info@ and hello@ are often aliases or groups, not paid users.
Do not trap team mail in one inbox
Support, sales, billing, and operations mail should survive staff changes.
Keep personal mail personal
A private employee mailbox is not a good place for shared customer workflows.
Document ownership
Every public address should have a clear owner, purpose, and review cadence.
Shared inbox workflows
Google Groups can be used as a Collaborative Inbox when the team needs shared handling. Google describes collaborative inboxes as a way for group members to take and assign conversations and perform collaboration tasks. Use the current Google documentation while configuring the feature: Make a group a Collaborative Inbox.
Shared workflows are useful for:
- Customer support.
- Sales inquiries.
- Accounts and billing.
- Vendor communication.
- Job applications.
- Branch operations.
- Website form notifications.
But they need rules:
Shared inbox rules
- Who owns the group?
- Who can receive mail?
- Who can send as the group?
- Can external senders email the group?
- Should messages be moderated?
- Is conversation assignment needed?
- What happens when a member leaves?
- Who reviews access quarterly?
If a support address receives customer complaints, invoices, or service requests, do not set it up casually. Decide whether the business needs a Google Group, collaborative inbox, help desk system, or CRM-connected mailbox.
Setup checklist
Before creating addresses, build a map.
List every address the business wants: personal, public, old, and temporary.
Mark each address as user, alias, group, collaborative inbox, or temporary.
Create users first, then aliases and groups.
Send mail from external accounts and confirm delivery, reply behavior, and ownership.
Add the address map to the Workspace handover document.
Testing addresses
Test like a customer would:
| Address | Test | Result to check |
|---|---|---|
owner@ | External sender to user | Mail arrives in owner's Gmail |
hello@ | External sender to alias | Mail arrives in mapped user's inbox |
support@ | External sender to group | Members or collaborative inbox receive it |
billing@ | Reply from responsible account | Customer sees correct From identity |
| Old address | Forwarding or alias check | Legacy contacts still reach business |
Also test removal. If a staff member leaves, can an admin remove them from group access without losing the public address? If not, the structure needs improvement.
Handover
The account structure should be part of the final Workspace runbook.
Address handover map
| Address | Type | Owner | Members | Review date |
|---|---|---|---|---|
[email protected] | User | Business owner | Not applicable | Quarterly |
[email protected] | Alias | Owner | Not applicable | Quarterly |
[email protected] | Group | Operations | Support team | Monthly |
[email protected] | Group | Accounts | Finance team | Monthly |
FAQ
Should info@ be a user or alias?
If one person receives and replies to all general inquiries, an alias can work. If several people handle general inquiries, use a group or shared workflow.
Can multiple people use one paid mailbox password?
Avoid shared passwords. Use groups, delegated access, collaborative inboxes, or a help desk workflow instead.
Can a user send from an alias?
Google Workspace supports alias send and receive behavior, but setup and visibility should be tested for each user.
Do groups receive mail from outside the company?
Only if group settings allow it. Test external posting before using a group as a public address.
How often should access be reviewed?
Review at least quarterly, and immediately after staff changes, vendor changes, or role changes.
