A change to a business email identity can affect who receives messages, how recipients recognize the sender, and who can access a mailbox. Yet “change the email” may mean several different things: updating a display name, changing an address, or transferring mailbox ownership. Treating them as one routine request can lead to missed messages or access being left with the wrong person. A short written process helps teams route each request to the right people, separate approval from execution, and verify the outcome—without assuming every workspace offers the same controls.
The useful bits
- Classify each request as a display-name, address, or ownership change before approving it.
- Separate the requester, reviewer, authorizer, and person who applies the change where practical.
- Confirm the resulting identity and access through approved workspace or provisioning controls.
Start by naming the change
Ask the requester to specify what should change, why, when it should take effect, and which mailbox or person is affected. A display identity is the name recipients may see; an address determines where messages are sent; ownership concerns who is responsible for or can access the mailbox. These are related but not interchangeable.
For example, a team member might need a corrected display name while keeping the same address. A department might need a different address, or a departing employee’s mailbox might need a new responsible owner. Each case can involve different consequences and permissions, so do not approve a vague request such as “update this account” without clarifying its scope.
Give each role a distinct job
The requester explains the business need and identifies the affected mailbox. A reviewer checks the details against an authoritative internal source, such as the organization’s approved directory or documented staffing process. An authorizer decides whether the change is appropriate and whether its impact is acceptable. An administrator or designated provisioner applies the approved change using the controls available to them.
Where staffing permits, keep authorization separate from execution, especially for ownership transfers or address changes that affect a team. In a small organization, one person may have more than one responsibility; document that reality rather than implying that separate approvals occurred. Limit the process to people with the relevant authority, and do not ask someone to share sign-in credentials to make a change.
Review the impact before approval
For a display-name change, confirm the requested wording and whether it represents an individual or a shared function. For an address change, check who relies on the current address and what needs to happen to incoming messages during the transition. Do not assume that changing an address automatically creates a separate mailbox, preserves access, or redirects mail; those outcomes depend on the workspace’s configuration and provisioning.
For an ownership change, establish who should have access afterward and whether the prior owner’s access should end. Consider related responsibilities, such as handling existing correspondence or updating the address in business materials. The approver should be able to understand these consequences from the request, rather than infer them after the change.
Use a written approval record
Keep a concise record in an approved internal process. Include the affected mailbox, the current and requested identity details, the reason, the requested effective timing, the reviewer, the authorizer, and who is responsible for carrying out the change. Record any transition steps or follow-up checks that matter. Avoid putting passwords, one-time codes, or unnecessary sensitive information into the request.
For example, a request could say: “Change the display name for [person@example.com] from [current display name] to [approved display name] because [reason]. Keep the address and mailbox ownership unchanged. [Reviewer] confirms the requested name; [authorizer] approves; [provisioner] applies and confirms the update.” This makes the scope explicit and prevents a display-name request from being mistaken for an address or access change.
Address and ownership request Mailbox: [team@example.com] Requested change: [new address or new responsible owner] Reason and effective timing: [business reason] / [date or timing] Impact checked by: [reviewer] Approved by: [authorizer] Applied by: [provisioner] Follow-up: [message handling and access check]
Check what the workspace permits
Do not assume a written approval means the requester can make the change, or that every administrator can make every kind of change. In BITTU Mail, workspace administration includes domain and mailbox administration, but available controls depend on role, plan, and provisioning state. Admin permissions and quotas are enforced server-side. An authorized workspace or domain administrator should use the controls available for their own workspace; if the required change is not available, follow the organization’s provisioning or support process rather than improvising.
A personal mailbox setting for a profile or name is not proof that a domain-level address or mailbox-ownership change has been made. Confirm that the action taken matches the approved request and that the person performing it is authorized for that action.
Confirm the result and close the request
After the change, compare the resulting address, display identity, or access arrangement with the approved details. For an address change, verify that the intended mailbox is the one affected and that agreed message-handling steps are in place. For an ownership transfer, confirm that the intended person has the required access and that access changes match the approval. For a display-name change, check the account’s current setting and send a suitable internal confirmation if appropriate.
Recipient mail apps and external providers choose how to render names, avatars, and logos, so a sender’s display may not look identical everywhere. Treat that as separate from whether the workspace change was applied. Mark the request complete only after the responsible person has checked the relevant result and recorded any remaining limitation or follow-up.
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction
