Plan Business Email Address Changes During a Rebrand

Start with the addresses people rely on

List every business email address that appears connected to the brand, not just staff mailboxes. Include role addresses such as sales or support, named employee addresses, addresses used for billing or sign-in, and any address customers are told to reply to. Record who owns each one and what it is used for.

Separate addresses that receive customer mail from addresses used to log in to services. A public contact address may also be a recovery address for an external account, or it may appear on a supplier profile. Those uses create dependencies that a website update alone will not resolve. If you cannot identify an owner or purpose, mark it for investigation rather than assuming it is unused.

• Address and current owner
• Purpose and audiences who use it
• Services or records that depend on it
• Person responsible for checking the change

Find references beyond your website

Search the places your organization controls: website pages, contact forms, email signatures, templates, proposals, invoices, newsletters, social profiles, directories, and customer or supplier portals. Check downloadable files as well as pages that are easy to edit. Ask the people who manage sales, support, finance, and operations to check their own materials; they may use different templates and accounts.

For third-party listings or customer systems, note who can request an update and whether the record needs approval. Some references cannot be changed immediately or may be maintained by another organization. Record the requested change and follow-up owner instead of treating the item as complete when a request is sent.

Build a dependency map before deciding what to change

For each address, connect the people and systems that depend on it. A support address might feed a shared workflow; a named address might receive password resets; an invoice address might be stored in a payment or purchasing profile. Note whether messages are expected from outside the organization, whether the address is used for account recovery, and who can verify that those uses still work.

Then classify each item: keep as is, update, investigate, or retire. These are planning labels, not assumptions about what your mail service can do. In particular, do not assume an alias is a separate mailbox or login. An alias may not provide an independent inbox or sign-in, so confirm the intended account behavior before depending on it.

Current: [sales]@example.com — website contact page and supplier profile
Proposed: [hello]@example.com — owner: [team lead]
Dependencies: [supplier profile], [sales form], [staff signatures]
Decision: [confirm available account action]; verify receipt before announcement

Check account actions before setting a launch date

Before announcing a new address, sign in through the account service and check which actions are available for the specific mailbox or workspace. Do not infer that a mailbox can be renamed, replaced, retained, or converted from how another provider works. Options can depend on role, plan, and provisioning state, and administration permissions are enforced by the service.

For BITTU Mail, account actions and sign-in go through mail.bittuicloud.com. Workspace domain and mailbox administration is available to authorized workspace or domain administrators in /workspace; the controls available depend on role, plan, and provisioning state. Confirm the actual available action in the authenticated account before planning around it. If the required option is not shown or its effect is unclear, pause the announcement and seek clarification through the appropriate account support route.

Verify the route, not just the address label

Once an action has been completed, verify the result using accounts and permissions you are authorized to use. Send a controlled message to the intended new address from an external mailbox, then confirm it arrives in the expected place and that an authorized team member can find and reply to it. Check the displayed sender name and signature in the outgoing message, too. A changed profile name or signature does not by itself prove that the underlying address changed.

Where the old address must remain useful, verify its handling separately rather than assuming mail will be forwarded or delivered elsewhere. Ask a trusted contact to reply to an existing conversation if that is an appropriate test. Record the date, what was checked, and any unresolved limitation. Do not use customer-sensitive information for a test.

Announce only what is ready

Update public references in a controlled order: first make sure the new route is ready, then revise the most visible contact points and operational templates, and finally send the announcement through channels your organization uses. Give staff a concise instruction on which address to use and when, and provide a contact for reporting missed messages. Keep the dependency list open during the transition so delayed third-party updates are not forgotten.

Confirm progress by revisiting each recorded reference and marking whether it was updated, verified, or is still pending with an owner and next step. The aim is not to claim every external copy has changed; it is to know which ones have, which ones remain, and how the team will handle them.