Did you know: at least one SMTP address needs to match the UPN in Office 365

It’s sometimes surprising that even 7 years after Office 365 launched I keep running into basic things I have overlooked, or simply forgotten about. One such example is the fact that Office 365 enforces the requirement that at least one of the SMTP addresses for a user needs to match the UPN. Any alias, not necessarily the Primary SMTP one, but it should be matching the UPN. For either synced of cloud-authored users. No other way around it.

I run into this recently when troubleshooting a simple script that removes email addresses from user’s mailboxes. Here’s a simple example, assuming we have a user UserX with two aliases:

(Get-Mailbox UserX).Emailaddresses

smtp:something@domain.com
SMTP:anythingelse@domain.com

In my case, the script was supposed to remove the something@domain.com alias, but failed to do so repeatedly. Although no error was generated, the alias kept showing up in the end result. So I tried to remove it manually, only to see the same behavior:

Set-Mailbox UserX -EmailAddresses @{remove="something@domain.com"}

(Get-Mailbox UserX).Emailaddresses

smtp:something@domain.com
SMTP:anythingelse@domain.com

I gave the EAC a shot too. After numerous tries, that damned alias kept reappearing automagically. So I started wondering what else should be in play here. The domain in question was the primary domain for the tenant, however Office 365 does not have any email address policy that will enforce such aliases. The only policy in play is the one associated with the onmicrosoft.com domain, and it’s disabled by default. So that was not the case.

I tested the behavior is another tenant, and was able to reproduce it. In yet another tenant, this time with DirSync enabled, the same behavior was also observed. After getting some additional feedback from the infamous bunch of Grumpy Old Exchange MVPs, it become clear that in Office 365 at least one of the email aliases should match the user UserPrincipalName attribute. And behold, in all my scenarios that was the case indeed, the infracting alias (either Primary or Secondary) was the one matching the UPN.

In Exchange Server on-premises, this requirement is certainly not enforced, and as mentioned above already, Email Address Policies are not to blame here. So it looks like the restriction is enforced somewhere in the code, and no options to control it are available to us. And the interesting part is that it seems to have been around for a while now, certainly few years (according to examples I’ve dug out of my PowerShell transcript files).