Reusing User Principal Names and Primary SMTP Addresses

User Principal Names and SMTP Addresses Must be Unique

In January 2023, I discussed how to standardize the creation of Microsoft 365 user accounts. The idea behind standardization is to make sure that user accounts are populated with appropriate properties such as job title, department, physical address, phone, and country to make sure that features like the user profile card display useful information. Standardization also means that it’s easier to deploy features like dynamic Microsoft 365 groups and dynamic administrative units which depend on accurate population of account properties. In this article, I consider whether it’s a good idea to reuse two critical account properties: the user principal name and primary SMTP address.

Every user account in a Microsoft 365 tenant has a unique and immutable object identifier (GUID). Accounts also have a user principal name (UPN) that the account owner uses to sign in. The UPN is made up of a prefix (account name) and suffix (domain name), such as [email protected]. The UPN is also unique within a tenant, but it’s not immutable because administrators can update a UPN for an account to take account of situations like marriages, divorces, or other circumstances where people change their name.

It’s common practice for people to have the same primary SMTP address as their UPN. This approach makes it easier for everyone because users sign in with their email address (or so they think). Seriously, it is easier than having two identifiers to remember.

During the normal course of business, people leave and join organizations. The question exists whether it is a good idea to reuse UPNs and primary SMTP addresses. The issue arises more often for people with common names like Jill Smith or James Ng where it’s more likely that a new employee joins with the same name as an ex-employee, so it’s good to have a policy to govern the situation.

After thinking about the issue for a while, my conclusion is that it’s a bad idea to attempt to reuse UPNs or primary SMTP addresses. Exceptions to the rule exist, but the general approach should be to avoid this practice. Let’s explore some reasons why.

Inactive Mailboxes

Inactive mailboxes are soft-deleted mailboxes retained by Exchange Online because a hold exists on the mailboxes or some of their contents. Retention occurs upon the final removal of the owner’s Entra ID account and lasts until the last hold lapses. An inactive mailbox can be recovered to become active and accessible by a user again. For instance, this might happen when someone who previously left returns to the organization and wants to use their old mailbox.

Mailbox restores are only possible with PowerShell. For example, this code recovers an inactive mailbox and connects it to an account with a UPN of [email protected]. The UPN chosen for the new account does not have to be the same as the UPN for the account that originally owned the mailbox. However, the UPN must be unique within the tenant.

$InactiveDN = (Get-Mailbox –InactiveMailboxOnly –Identity "Jill Smith").DistinguishedName
New-Mailbox –InactiveMailbox $InactiveDN –Name "Jack Smith" –FirstName Jack –LastName Smith –DisplayName "Jack Smith" –MicrosoftOnlineServicesID "[email protected]" –Password (ConvertTo-SecureString –String "Testing123!@A" –AsPlainText –Force) –ResetPasswordOnNextLogon $True

When the command completes, the mailbox’s ExternalDirectoryObjectId property points to the object identifier of the Entra ID account. The command works perfectly if no Entra ID account exists with the same UPN, but fails otherwise. If you reuse a UPN, it’s obvious that you cannot assign that UPN to a returning employee.

Email Misdelivery

The mention of email addresses brings us to an obvious problem that can occur if you reuse UPNs and email addresses. People who received email from those who previously used the email addresses might respond to those messages. When the email arrives in Exchange Online for delivery to the tenant, a match exists for the address and Exchange Online delivers the message to the mailbox that currently holds the address. Of course, this means that the email is delivered to the wrong (but not incorrect) mailbox, if you get my meaning.

No one can control the contents of mailboxes containing messages with reply addresses pointing to addresses used by ex-employees. A common solution to avoid inbound communications going into a black hole is to add the primary SMTP addresses for ex-employee mailboxes to a shared mailbox that has an auto-reply configured to respond to tell external senders that whoever they attempted to contact is unavailable. Figure 1 shows the Exchange admin center option to configure the auto-reply text used to respond to internal and external senders. You can also set auto-reply text through PowerShell with the Set-MailboxAutoReplyConfiguration cmdlet.

An Exchange Online mailbox supports up to 300 proxy addresses (aliases), which you can add by editing the mailbox properties through the Exchange or Microsoft 365 admin centers or by using PowerShell. For example, here’s how to use the Set-Mailbox cmdlet to add a new proxy address to a shared mailbox.

Set-Mailbox -Identity RedirectMailbox -EmailAddresses @{Add='[email protected]'}

If the organization needs to handle communications for more than 300 ex-employees, it can split processing over several shared mailboxes. The shared mailboxes used for this purpose should be hidden from address lists. Using shared mailboxes like this doesn’t cost anything because shared mailboxes are free unless assigned an Exchange Online Plan 2 to enable an archive mailbox or expand their quota from 50 GB to 100 GB.

An advantage of assigning email addresses for ex-employees to shared mailboxes is that Exchange Online won’t allow administrators to assign the addresses to new mailboxes. An email address can only exist once within the Exchange Online directory, so the fact that an address is present as a proxy address for a shared mailbox prevents its use elsewhere. The method won’t stop administrators from reusing UPNs, but if they see an error when attempting to reuse an email address, perhaps it will make them realize that a problem might exist with the UPN too.

Workload Directory Synchronization Woes

Although Entra ID is the directory of records for Microsoft 365, workloads can maintain their own directories. Sometimes this is to enable specific functionality, such as how the Exchange Online Directory (EXODS) holds mail-specific properties of emailable objects, some of which (like public folders or dynamic distribution lists) are unknown to Entra ID. And sometimes it’s to allow an application to work in its own way, like Teams “membership rosters.” When a workload maintains its own directory, it synchronizes objects and properties with Entra ID to make sure to add new user accounts and remove deleted accounts.

SharePoint Online has its own directory, and issues can result when hiccups occur in the synchronization between SharePoint and Entra ID. An example is the “User not in directory” issue when a user attempts to access SharePoint Online due to an obsolete user profile or profile identifier (PUID) mismatch. For more information, see this Microsoft Technical Community discussion and the Microsoft support articles linked in the text.

Best to Stay Unique and Avoid Reuse

It’s clear that Microsoft 365 applications expect people to have unique UPNs and email addresses. Internally, most processing is based on account identifiers, which are unique and immutable and therefore always resolve to the correct account. Entra ID uses the object identifiers to add and remove members to groups, so membership of Microsoft 365 Groups (dynamic or static) and security groups should always be accurate. It’s when things get exposed in the form of UPNs and email addresses that everything becomes more fraught.

Everything would work perfectly if people could be persuaded to use their account identifiers to sign in and for email, but it might just be a stretch for everyone to remember to sign in with a UPN like [email protected] or use the same as their email address. Because we want to use people-friendly identifiers, it’s best to stay safe and avoid reusing UPNs or primary SMTP addresses.