Every business function needs a real address. sales@, billing@, abuse@, legal@ — the list builds fast. On Google Workspace or Microsoft 365, every entry costs a seat. That's $6–$12/month per role, every month. Call it the per-seat tax on being organized.
It gets worse. Someone on your team registers the AWS root account under their personal work address. They leave. IT suspends the mailbox. Now you can't receive a password reset for your own infrastructure. You're spending an afternoon proving ownership to a support queue that doesn't care.
An alias email address fixes both problems. It's a public-facing address that accepts inbound mail and routes it to an existing mailbox — no extra account, no credentials, no billing seat. This guide covers the four routing patterns where an alias email address earns its keep, and the one scenario where it'll break your workflow instead.
For DNS mechanics, MX records, and forwarding configuration, see our guide on email alias forwarding.
What Is an Alias Email Address?
An alias email address is an alternate inbound address that routes mail to a real mailbox. It has no inbox, no password, and no storage of its own. When mail arrives addressed to the alias, the mail server rewrites the envelope recipient — RCPT TO: sales@domain.com becomes RCPT TO: alice@domain.com — and completes delivery. The sender sees sales@. Alice gets the email. The rewrite is invisible, and that invisibility is the entire point.
Use Case 1: Role-Based Routing
The primary use of an alias email address is establishing functional ownership — mapping a public role to the person currently responsible for it. One alias, one destination. This is the one-to-one pattern RFC 2142 codifies: every domain should maintain standard role addresses regardless of who fills them.
| Alias | Function | Routes To |
|---|---|---|
sales@ | Inbound leads | Founder or head of sales |
billing@ | Invoices, receipts | CFO or office manager |
abuse@ | Compliance (RFC 2142) | CTO or sysadmin |
legal@ | Contracts, NDAs | Founder or outside counsel |
no-reply@ | Transactional notifications | Archive mailbox or /dev/null |
None of these need their own accounts. Each is an alias email address pointing at an existing mailbox. On Postfix, the full configuration is a few lines in /etc/postfix/virtual:
sales@company.com alice@company.com
billing@company.com bob@company.com
abuse@company.com cto@company.com
legal@company.com alice@company.comPostfix queries the alias map on every inbound message and rewrites the envelope before delivery. When Alice moves to a different role, update one line and reload:
postmap /etc/postfix/virtual
systemctl reload postfixNo vendor tickets. No account migrations. No forwarding rules scattered across three clients.
Use Case 2: Infrastructure Handoffs
This is the most underrated application of an alias email address — and the failure mode that's hardest to recover from once it hits you. Every critical SaaS tool you register under a personal work address becomes a liability the day that person leaves.
The scenario plays out the same way every time. Steve registers the domain registrar, the AWS root account, and the Stripe dashboard under steve@company.com. Steve gets poached. IT suspends the mailbox 90 days later. Your billing emails bounce. Password resets disappear. The 2FA codes for your AWS root account are gone. You're now proving ownership of an account you built five years ago to a support queue with no SLA.
The fix: use a permanent alias email address for every infrastructure registration.
- Create
ops@company.comas an alias pointing to the current responsible party — CTO, sysadmin, whoever owns infrastructure. - Register all critical services — DNS registrar, AWS, Stripe, GitHub, Cloudflare — using
ops@as the account email. - When the owner changes, update the alias target to the incoming person. One change, takes under a minute.
The vendor records never change. Zero downtime. No "Forgot Password" loops. No support calls to prove you own your own account.
The alias email address pattern works here because the address itself is the permanent asset. The routing behind it can change anytime without the vendor knowing or caring.
Use Case 3: Inbound Tracking and Filtering
Aliases let you tag and sort inbound traffic without creating accounts, writing complex inbox rules, or touching your mail configuration more than once. Two patterns cover most scenarios: dedicated tracking aliases and plus addressing.
Dedicated Tracking Aliases
When attending a trade show, signing up for a vendor trial, or subscribing to a newsletter you don't fully trust, use a source-specific alias email address — conf2026@company.com or acme-vendor@company.com. If that address shows up in a spam list or starts generating noise, delete the alias. The traffic stops immediately. You can't do this with your primary address. You can't selectively revoke a Gmail address.
This pairs cleanly with a catch-all inbox: any address at your domain delivers to one mailbox, and you create the tracking alias retroactively after you see which tags arrive.
Plus Addressing (Sub-addressing, RFC 5233)
Most modern mail servers support RFC 5233 sub-addressing via the + delimiter. You don't create these anywhere — they work automatically on any compliant server.
alice+jira@company.com → delivers to alice@company.com
alice+shopify@company.com → delivers to alice@company.com
alice+newsletters@company.com → delivers to alice@company.comSet one inbox rule matching the tag and every tagged message routes to the right folder. Zero admin overhead. The alias email address already exists — you're just appending metadata to it.
Use Case 4: Sending As an Alias (and Where It Breaks)
Receiving mail through an alias email address is automatic. Sending mail from one takes one extra step — and if you skip it, you expose your personal address to every customer you reply to.
The failure: a customer emails sales@company.com. Mail routes to alice@company.com. Alice hits Reply. The customer sees the reply come from alice@company.com. The professional identity is gone, and Alice's direct address is now in their contacts forever.
Aliases carry no credentials. To send as an alias email address, configure an outbound identity in your email client:
- Standard clients (Outlook, Thunderbird, Apple Mail): Add a new identity with the alias as the From address. Authenticate via your primary mailbox SMTP credentials. The client sends through your account but stamps the alias in the From header.
- BYO SMTP (TrekMail Free or Starter with Amazon SES or SendGrid): You must verify the alias address — or your entire sending domain — in the SMTP provider's dashboard before sending. Skip this and the message is rejected outright:
554 Message rejected: Email address is not verified. See TrekMail's BYO SMTP configuration guide for the full verification flow.
When an Alias Email Address Breaks Down
An alias email address is a one-to-one tool. Route one alias to one mailbox and every use case above works correctly. The moment you forward the same alias to multiple people simultaneously — Alice, Bob, and Charlie all receive support@ — you've created a split-brain inbox that will eventually cost you a customer.
How it fails: Alice replies to a customer and resolves the issue. Her reply saves to her Sent folder — not a shared server folder, not Bob's client. Bob doesn't see it. Bob replies three hours later with conflicting information. The customer is confused, annoyed, and will remember it.
This isn't a configuration problem you can fix. It's a structural limitation of the alias email address model. For a full breakdown of when aliases work and when they don't, see our guide on domain email alias vs mailbox.
The right fix for shared inboxes: create a dedicated mailbox for support@company.com. Share the credentials via a password manager. Alice and Bob both add the account to their IMAP client. When either replies, the sent message saves to the server's Sent folder and syncs to both clients. State is shared. Replies don't collide. Nothing leaks.
| Scenario | Right Tool | Why |
|---|---|---|
| One person handles a role address | Alias | No extra account or seat needed |
| Infrastructure / service accounts | Alias | Survives personnel changes cleanly |
| Tracking inbound by source | Alias email address | Deletable on demand, no storage overhead |
| Burner address for low-trust signups | Alias email address | Revoke instantly if sold to spam lists |
| Two or more people read and reply | Mailbox | Shared IMAP state, no reply collisions |
| Long-term team ownership | Mailbox | Audit trail, delegated access |
The Per-Seat Pricing Model Pushes You Toward the Wrong Architecture
On Google Workspace and Microsoft 365, every mailbox you create costs money. That pricing pushes teams to use an alias email address as a shared inbox to save $6/month — which then fails exactly as described above. The wrong architecture isn't laziness. It's a rational response to per-seat billing.
TrekMail's pricing is flat-rate. Storage is pooled across all mailboxes on your account. You're not charged per mailbox or per alias. The Starter plan is $3.50/month for 50 domains and 15GB pooled storage. Whether you run 3 mailboxes and 10 aliases, or 20 mailboxes and 200 aliases, the price doesn't change.
That means the economics no longer push you toward the wrong tool. Create the dedicated support@ mailbox. Set up the permanent ops@ handoff alias. Tag every conference lead with its own alias email address. Build what your workflow actually needs.
If you're starting from scratch, see how to create email with your domain — it covers domain provisioning, DNS records, and first mailbox setup end to end.
Alias Email Address Summary
The alias email address is a one-to-one routing tool. Use it for role addresses, infrastructure handoffs, and inbound tracking. Use plus addressing for zero-overhead tagging. Use a dedicated mailbox the moment more than one person needs to read and reply. The alias email address works cleanly for the first three scenarios — the fourth requires shared IMAP state that an alias can't provide.
Stop Paying the Per-Seat Tax
Legacy providers charge you for every identity you create. On TrekMail, the alias email address is free and unlimited — and so is the second mailbox, the fifth domain, and the twentieth alias.
Starter plan — $3.50/month:
- 50 custom domains on one account
- 15GB pooled storage across all mailboxes
- Unlimited aliases per domain
- Catch-all inbox routing
- Managed SMTP included — no external provider required
- SPF, DKIM, and DMARC setup wizard
At $3.50/month, you're paying less than a single Google Workspace seat for 50 domains and every alias you'll ever need.
The 14-day trial starts at trekmail.net — a credit card is required to begin. If you'd rather test before committing, the Nano plan (10 domains, 5GB pooled storage, BYO SMTP) is permanently free with no card and no expiry. Start there and upgrade when you're ready.
