KoltrixMigrating Aliases, Groups and Shared Mailboxes Without Losing Mail
User mailboxes get migrated. Aliases, groups and catch-alls get forgotten, then mail bounces. How to map every address before cut-over and test it after.
On this page(8 sections)
- The addresses that go missing
- Step 1: Export the full address list
- Step 2: Build an address map
- Step 3: Decide what each address should become
- Mailbox, alias or shared mailbox?
- Groups versus shared mailboxes
- Catch-alls
- Forwards to outside addresses
- Step 4: Create everything before the cut-over
- Step 5: Test every row after the cut-over
- Step 6: Clean up the outside world
- Key takeaways
Nobody forgets to migrate the CEO's mailbox. What gets forgotten is invoices@, the alias someone created four years ago so the accountant could receive statements, which forwards to two people, one of whom has left. After the cut-over it bounces, and nobody notices until a supplier calls about an unpaid bill.
Personal mailboxes are the easy part of an email migration. This guide is about everything else.
The addresses that go missing
Most providers support several kinds of addresses besides one-person mailboxes. They're easy to create and easy to forget:
- Aliases: extra addresses that deliver into an existing mailbox.
jane@might also receivej.doe@andpress@. - Groups or distribution lists: one address that delivers a copy to several people.
team@,founders@,all@. - Shared mailboxes: a mailbox that belongs to the company rather than a person, which several people can open.
support@,billing@. - Catch-all addresses: anything sent to an address that doesn't exist gets delivered somewhere instead of bouncing.
- Forwarding rules: a mailbox set to forward everything, or some things, to another address, sometimes outside the company.
- Service addresses:
postmaster@,abuse@,dmarc-reports@, and whatever address your DNS provider, registrar or domain verification records point to.
The last group is especially dangerous. If your DMARC record sends aggregate reports to an address that disappears in the migration, you lose visibility into who's sending as your domain at the exact moment you most need it.
Step 1: Export the full address list
Before changing anything, get a complete list of every address on the domain from the current provider's admin console. Look specifically for:
- Every user and their aliases
- Every group and its members
- Every shared or resource mailbox and who has access
- Domain-level catch-all settings
- Mailbox-level forwarding rules (these are often only visible per user)
Then cross-check against what the outside world uses. Search your DNS records, your website, your app's sending configuration, your billing system, your registrar account and your contracts for addresses on the domain. Anything that appears there but not in the admin export is a red flag.
Step 2: Build an address map
Make one table with a row per address. This is the most important artifact of the whole migration.
| Address | Today | Who receives it | Destination after migration | Tested |
|---|---|---|---|---|
support@ |
Group | Ana, Ben, Chloe | Shared mailbox, Ana and Ben with access | |
billing@ |
Alias of ana@ |
Ana | Shared mailbox, Ana and finance contractor | |
invoices@ |
Forward | [email protected] |
Retire; update supplier records to billing@ |
|
press@ |
Alias of founder | Founder | Alias of founder | |
dmarc@ |
Mailbox | Nobody reads it | Mailbox, reviewed weekly | |
*@ catch-all |
Enabled | Founder | Disabled after 30-day review |
Fill in "who receives it" from the actual configuration, not from memory. Fill in "destination" as a conscious decision.
Step 3: Decide what each address should become
Migration is a good moment to fix address design. For each one, ask what it's for.
Mailbox, alias or shared mailbox?
- Use a personal mailbox when one person owns the conversations and they'd leave with that person.
- Use an alias when one person owns the address but wants it to land in their main inbox, like
press@going to a founder. - Use a shared mailbox when the address belongs to a function, not a person, and more than one person might reply.
support@,billing@,sales@andsecurity@almost always belong here.
Groups versus shared mailboxes
Groups that fan out copies to everyone's personal inbox are a common source of double replies and dropped threads: everyone assumes someone else answered. When several people respond to the same address, a shared mailbox with per-person access works better. Everyone sees the same thread, and replies are visible to the whole team.
In Koltrix, for instance, shared addresses like support@ belong to the workspace, access is granted per person and per mailbox, and nothing has to be forwarded to personal inboxes. Most team inbox tools follow a similar model.
Catch-alls
Catch-alls feel safe but mostly collect spam and dictionary-attack attempts. If you keep one during the transition to catch addresses you missed, set a date to review what it received and turn it off.
Forwards to outside addresses
Forwarding company mail to personal or third-party accounts creates security and continuity problems. Use the migration to replace them with proper access to a shared mailbox, or retire the address.
Step 4: Create everything before the cut-over
Recreate every address on the new provider before you change MX records. Send a test message to each one through the new provider's internal routing if it supports that, so you know the address exists and delivers to the right people.
Don't forget permissions. A shared mailbox that exists but that nobody has access to is just a quieter bounce.
Step 5: Test every row after the cut-over
Once MX points to the new provider, send a test message from an external account to every address in your map. Mark the "Tested" column as you go. Check:
- The message arrives
- It reaches the right people
- Replies go out from the right address
- Nothing lands in a personal inbox that should be in a shared one
It's tedious, and it's the step that catches the problems. A twenty-address domain takes about half an hour.
Step 6: Clean up the outside world
For any address you retired or renamed, update the places that reference it: supplier records, payment processors, app store accounts, your registrar contact, DMARC rua addresses, website footers and help-center articles. Keep a forwarding alias from the old address for a few months if you can, then retire it.
For the broader cut-over sequence, see our Google Workspace migration checklist, which applies to most providers.
Key takeaways
- Aliases, groups, shared mailboxes, catch-alls and forwards are where migrations lose mail.
- Export every address from the admin console and cross-check against DNS, contracts and your app.
- Build an address map and decide deliberately what each address becomes.
- Functional addresses like
support@andbilling@work best as shared mailboxes with per-person access. - Create everything before the cut-over and test every single address afterward.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
