Create a Business Email Naming Convention Employees Can Follow

Start with the people who will use the address

Decide whether addresses should use a person’s full name, first initial and surname, or another simple combination. Prefer a pattern employees can say aloud and colleagues can guess without a directory. For example, a company might use first name plus surname, separated by a period. Avoid embedding department, job title, office location, or year of hire unless those details are essential: roles and locations can change, while an address may need to remain stable.

Specify how to handle spaces, hyphens, apostrophes, diacritics, preferred names, and long names. There is no single choice that fits every organization. The useful rule is the one administrators can apply consistently and employees can understand. If the written name differs from the address form, keep the person’s preferred display name in the appropriate account profile settings where available; the address pattern does not have to dictate how a person is displayed.

Make duplicate names predictable

Do not let each administrator invent a different fix when two people produce the same address. Choose a fallback order and document it. One possible policy is to try the standard pattern first, then add a middle initial if available, and then use a consistent numeric suffix if the collision remains. Another organization may prefer a different distinguishing element. Whatever you choose, check that the resulting address is unique and does not expose information the organization would rather keep private.

Keep the original pattern intact where possible. For instance, if two employees would both be [jordan.lee@example.com], a documented fallback might be [jordan.m.lee@example.com] for the employee whose recorded middle initial is M. If that does not distinguish them, use the next approved fallback rather than inserting an arbitrary number or department abbreviation. Never reuse an address just because its former owner has left; decide separately whether and how old addresses are handled.

Standard: [first].[surname]@example.com
Collision fallback: [first].[middle-initial].[surname]@example.com
If still unavailable: [approved consistent suffix]@example.com
Example addresses: jordan.lee@example.com; jordan.m.lee@example.com

Separate personal addresses from shared work

A person’s address and a team address serve different purposes. Decide how to name shared functions such as support or billing, and identify who is responsible for them. Do not create a personal mailbox under a team name simply because several employees need to handle the work. Conversely, do not make an employee’s personal address the only published contact for an ongoing function unless that is an intentional policy.

Clarify whether a shared address should be an independent mailbox or an address associated with another mailbox. In BITTU Mail, an alias is not automatically an independent mailbox or login. Confirm the intended account type and required access before creation; available controls can depend on administrator role, plan, and provisioning state.

Write exceptions before provisioning

Keep the convention somewhere administrators can consult before creating an account. Include the standard format, character-handling rules, duplicate-name sequence, shared-address rules, and who can approve exceptions. Record the reason for each exception, the approved address, and the person or role that authorized it. Limit the record to information needed to administer the address.

Common reasons to consider include a legal or preferred name that does not fit the standard, a genuine collision after the fallback sequence, or a function that requires a shared address. Avoid treating convenience as an invisible exception: if a rule changes, update the written convention so later administrators do not have to infer what happened.

• Before creating a mailbox, confirm the person’s requested display name and the name fields used by the policy.
• Check for an existing address that would collide, including any approved exception.
• Apply the documented fallback and obtain approval if the case still does not fit.
• Record the decision before sharing the new address.

Check the result with a dry run

Before rollout, apply the draft rules to a small set of fictional or approved test cases: two people with identical names, a hyphenated surname, a long name, a preferred name, and a shared function. Ask an administrator who did not write the policy to derive the expected addresses. If they reach different answers, clarify the rule before making accounts.

After an authorized administrator creates a mailbox, compare the created address with the approved record and confirm that the employee can identify it as theirs. If the address is wrong, correct it through the available administration process before distributing it. Permissions and account controls are enforced according to role, plan, and provisioning state, so use an administrator with the necessary access rather than assuming every user can make changes.

Keep the convention maintainable

Review the document when the organization changes its naming policy or discovers a recurring exception. Do not alter addresses casually to match a new preference; first consider who already uses the address and what communications may depend on it. Explain any approved change to the affected employee and update the administrative record.

The convention is working when different administrators independently produce the same address for the same case, employees can explain the pattern, and exceptions have a recorded reason. That is a more useful test than choosing a format that looks elegant on paper.