KoltrixMoving Your Company Email to a New Domain After a Rebrand
A rebrand means new email addresses, but the old domain keeps receiving mail for years. How to switch addresses, authenticate both domains and avoid lost mail.
On this page(9 sections)
- Rule one: keep the old domain forever
- Step 1: Inventory what uses the old domain
- Step 2: Set up the new domain properly before announcing it
- Step 3: Make the old addresses keep working
- Step 4: Move application sending carefully
- Step 5: Tell people, more than once
- Step 6: Watch for lookalikes and phishing
- How long to keep the old addresses delivering
- Key takeaways
Changing your company's name takes a weekend of design work and a few weeks of updating websites. Changing its email domain takes years, because the old addresses are printed on invoices, saved in contacts and wired into systems you've forgotten about.
This guide covers how to move company email to a new domain after a rebrand without losing mail, confusing customers or handing an opening to impersonators.
Rule one: keep the old domain forever
Before anything else: don't let the old domain expire. Not next year, not in five years.
An expired domain can be registered by anyone, including someone who wants to receive mail meant for your customers' former contacts, reset passwords on accounts tied to old addresses, or send convincing phishing as your old brand. Renewing a domain costs little. Recovering from someone else owning it can cost a great deal.
Set it to auto-renew, put the registrar account under a role address on the new domain, and add a calendar reminder to check the payment method each year.
Step 1: Inventory what uses the old domain
List every place the old domain appears in email:
| Category | Examples | What to change |
|---|---|---|
| People's addresses | [email protected] |
New address plus alias from old |
| Shared addresses | support@, billing@, sales@ |
New shared addresses; old ones still delivered |
| Application sending | Receipts, password resets, notifications | From address and DKIM on new domain |
| Third-party tools | CRM, help desk, invoicing, forms | Sender settings and verified domains |
| Accounts registered with old addresses | Registrar, cloud, payment processor, app stores | Login and contact email |
| Printed and static material | Invoices, contracts, website footer, email signatures | Updated templates |
The accounts row is the easiest to overlook and the most important. If your cloud provider's root account is tied to an old address and that mailbox ever stops receiving, recovering it can be very difficult.
Step 2: Set up the new domain properly before announcing it
Treat the new domain as a fresh sending identity, because to mailbox providers that's exactly what it is.
- Add the domain to your email provider and publish SPF, DKIM and DMARC. Start DMARC in monitoring mode if you're unsure of all your senders, then tighten it.
- Create addresses for everyone, plus shared addresses.
- Send normal, low-volume mail first. People replying to real conversations from new addresses builds a sending history. A new domain that starts with a large announcement blast to every customer is more likely to be filtered.
- Verify the domain in every third-party tool that will send as it.
Step 3: Make the old addresses keep working
Mail will keep arriving at old addresses for a long time. Make sure it reaches the right person.
- Alias old addresses to new ones where your provider supports multiple domains in one workspace.
[email protected]delivers into Ana's mailbox alongside[email protected]. - Keep old shared addresses delivering to the new shared mailboxes.
- Decide how replies go out. Generally, reply from the new address so people learn it. Some teams reply from the old address for a short transition so threads don't look like they came from a stranger, then switch.
- Keep authentication on the old domain. As long as anything sends as the old domain, its SPF, DKIM and DMARC must stay correct. Even if nothing does, keep a DMARC record with an enforcing policy and an SPF record that authorizes no senders (
v=spf1 -all), so others can't easily spoof it.
If your provider supports multiple domains per workspace, this is usually straightforward. In Koltrix, for instance, Starter includes two domains and Pro includes ten, which covers an old and new domain side by side.
Step 4: Move application sending carefully
Your product's emails, such as receipts, notifications and password resets, are the messages customers rely on most. Change their sending domain deliberately:
- Publish DKIM for the new domain with your sending provider and confirm it passes.
- Switch one email type at a time, starting with low-stakes notifications. Watch bounce and complaint rates.
- Update the display name to the new brand at the same time as the domain, so customers see a consistent identity.
- Keep Reply-To addresses working. Make sure replies to old receipts still reach someone.
- Move password resets and security notices last, once the new domain has a good sending history.
Step 5: Tell people, more than once
Customers and partners need to learn the new addresses. A few channels help:
- A short announcement email from the new domain, sent after it has some sending history. Keep it plain: new name, new addresses, old addresses still work for now.
- Email signatures that mention the change for a few months: "We're now Brightline (formerly Oldname)."
- Auto-replies are usually unnecessary if aliases deliver mail normally. Use them only if old addresses won't be read.
- Update your website, help docs and invoices on day one.
Here's a simple announcement outline:
Subject: Oldname is now Brightline: our new email addresses
Hi Jordan,
We've renamed the company to Brightline. Our email addresses
are moving from @oldname.example to @brightline.example.
Nothing else changes: same team, same account, same billing.
Mail sent to the old addresses will keep reaching us.
If you've added us to an allowlist or address book, please add
@brightline.example too.Brightline and Oldname are made-up names, and the domains are placeholders.
Step 6: Watch for lookalikes and phishing
A rebrand is a moment of confusion, and confusion is what phishers exploit. Customers expect email from a domain they don't recognize yet.
- Register obvious variations of the new domain if they're cheap, such as common misspellings and the main alternative TLDs.
- Publish enforcing DMARC on both domains so exact-domain spoofing fails.
- Tell customers what legitimate messages look like and which domains you use.
- Watch DMARC aggregate reports for unexpected sources sending as either domain.
How long to keep the old addresses delivering
The honest answer is: as long as the domain exists, which should be indefinitely. Mail to old addresses tapers off but rarely stops. A customer who emails once a year, a vendor's old contact record, or a printed invoice from three years ago will keep generating occasional messages. Keeping aliases in place costs almost nothing.
Key takeaways
- Never let the old domain expire; auto-renew it and protect the registrar account.
- Authenticate the new domain and let it build sending history before a large announcement.
- Alias old addresses to new mailboxes, and keep the old domain's authentication correct, or locked down with
v=spf1 -alland enforcing DMARC if nothing sends from it. - Move application email one type at a time, and watch for lookalike domains during the transition.
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.
