Keep the old domain registered and decide where each old address should deliver before announcing a new company name. A domain alias can help when the names before @ match and both domains receive mail through TrekMail. Replies need their own decision: customers may write to the old brand but hear back from the new one.
Prepare an address list with three columns: old address, intended recipient, and approved reply address. This makes exceptions visible before you connect the domains.
How matching addresses work
Suppose company.example is the new main domain and brand.example is the former name you are keeping. Create or confirm hello@ and anna@ on the main domain before linking the old domain.
After you configure a domain alias, a message to hello@brand.example goes to hello@company.example. A message to anna@brand.example uses the corresponding anna@company.example address. The system matches the part before @.
If billing@ does not exist on the main domain, the relationship won't create it automatically. Do not assume that every invented address on the second domain will reach hello@. Other routing rules apply to unknown addresses, including a catch-all if one has been configured separately. A catch-all is a recipient for messages sent to unrecognized addresses on a domain.
The incoming mail routing guide explains the distinction.
Prepare both domains
For a domain alias, both domains must belong to the same TrekMail account, be active, and receive mail through TrekMail. Check the MX records for each. Those tell other email systems where incoming messages should be delivered.
Choose the main domain where recipients already exist. Then link the additional domain to it in the routing settings. Start with a pair whose result is easy to verify, such as hello@ on both domains.
Domain alias delivery is available on Starter, Pro, and Agency.
Keep a list of the connected domains and the main domain for each relationship. This is useful for former company names and regional versions. Avoid building a chain in which one alias depends on another. Each relationship should have a clear main domain with working recipients.
Account for addresses that already exist
The additional domain may have its own mailbox or a rule for a specific address. TrekMail checks that exact recipient before applying the domain alias, preserving existing address assignments.
For example, sales@brand.example might belong to a separate team while other matching names route to company.example. Messages for sales@ will continue using its explicit route.
Review the additional domain's mailboxes, aliases, and forwards before connecting it. Afterwards, test both a normal matching address and one with its own configuration. Different results can be expected behavior rather than an error.
If you only need one additional address with a different recipient name, consider a regular mailbox alias. It connects a specific address to an existing mailbox without linking every matching name across the domain.
Set up replies separately
Receiving a message at hello@brand.example doesn't guarantee the reply will come from that address. Check webmail's authorized sender list. Replying from the additional domain requires the appropriate sender identity and a working sending route.
During testing, inspect both the inbox and the reply's From field. The recipient should see the reply identity you chose for the transition. If an old domain is only being retained for incoming mail, you may choose to reply from the main address, but make that decision deliberately.
Sort the old addresses before choosing one rule
Divide the old address list into three groups. First are exact name matches that should reach the equivalent address on the new domain. Second are exceptions that need a different person or team. Third are obsolete addresses for which you still need to decide what happens. A domain-wide relationship fits the first group, but it does not make those decisions for the other two.
For example, anna@oldbrand.example can match anna@newbrand.example when Anna's new recipient exists. The old enquiries@ address may need to reach hello@ instead, which is a different local name. Use an appropriate explicit address arrangement for that exception and test it separately. Do not rename a customer's destination merely to make the whole list look uniform.
Record any existing explicit recipient on the old domain before applying the broader relationship. Its priority can explain why one address behaves differently from the rest. Avoid deleting that recipient until you know whether its current owner still needs it and what happens to any stored correspondence.
Keep delivery, archive and identity as separate jobs
A domain alias controls delivery of new incoming messages. It does not rename previously stored messages, rewrite old contracts or transfer an archive between mailboxes. If the rebrand includes an archive move, list that task separately with the messages to transfer and the person who will verify them.
Choose a reply policy for the transition. The business might reply from the new brand while keeping the former address available for incoming mail. Alternatively, a team may need to continue a particular conversation under the old identity for a period. Either choice requires an authorised sending identity and a working route; receiving through the alias is not sufficient.
Explain the change in plain language to customers when relevant. They should be able to recognise why the reply comes from a different company name. Keep sender names, signatures and website contact details consistent with the chosen policy, rather than changing them independently on different devices.
Keep the former domain under your control
Put the old domain's renewal and recovery responsibilities in the rebrand plan. Customers, suppliers and account recovery services may keep using an old address long after the website has changed. Removing the old domain from a logo does not remove those dependencies.
Before retiring any former address, inspect the business accounts that use it and update them through each service's supported process. Check where replies and recovery messages should go after the change. Keep a dated exception list so a future administrator can distinguish an intentional old route from an overlooked configuration. Review that list after the new name is established instead of assuming all correspondents changed their address books on announcement day.
Move in stages and keep an exception list
Test a matching address on both domains, an address with its own existing route, and a name that has no recipient. Record the expected result before sending. An unknown address must not be treated as proof that a domain alias creates every mailbox.
Update signatures and the chosen From identity separately. Keep the old domain renewed while people still use its addresses. Before removing any former route, check where customers, invoices, and account recovery messages still arrive.
