"mail" field doesn't have unique values in Graph API

Question

Hello!

We have encountered an issue where we can't always reliably discern users by their e-mail address, i.e. several users may have the same exact address. This breaks the logic in our software which relies on the addressess being unique, and we have several support cases where this causes issues for our customers.

When we query a user in Graph API we can see their "mail" property as shown:
{
"@odata.id": "https://graph.microsoft.com/v2/.../directoryObjects/.../Microsoft.DirectoryServices.User",
"businessPhones": [],
"displayName": "dep1",
"givenName": "dep1",
"jobTitle": null,
"mail": "user1@mathieu.company .com",
"mobilePhone": null,
"officeLocation": null,
"preferredLanguage": null,
"surname": null,
"userPrincipalName": "dep1@mathieu.company .onmicrosoft.com",
"id": "<unique GUID 1>"
}

From https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0 we understand that "mail" returns Primary SMTP, which is supposed to be unique.

However, if you migrate a user from on-prem to cloud, you'll see that the user has the same "mail" field:

"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users",
"value": [
{
"@odata.id": "https://graph.microsoft.com/v2/.../directoryObjects/.../Microsoft.DirectoryServices.User",
"businessPhones": [],
"displayName": "ev1",
"givenName": "ev1",
"jobTitle": null,
"mail": "user1@mathieu.company .com",
"mobilePhone": null,
"officeLocation": null,
"preferredLanguage": null,
"surname": null,
"userPrincipalName": "user12345@mathieu.company .onmicrosoft.com",
"id": "<unique GUID 2>"
},

According to this article: https://support.microsoft.com/en-us/topic/how-to-use-smtp-matching-to-match-on-premises-user-accounts-to-office-365-user-accounts-for-directory-synchronization-75673b94-e1b8-8a9e-c413-ee5a2a1a6a78#:~:text=The%20cloud%20user%27s%20primary%20SMTP,have%20the%20same%20SMTP%20address this should not be allowed or should not happen? Maybe it describes a different scenario though.

So we now have two users with same "mail" field that is expected to have unique values. Why is "mail" not unique? What should we do, or what should we use as unique SMTP address for users? Maybe some of the values from "proxyAddresses" field as seen below?

"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(id,displayName,userPrincipalName,onPremisesSecurityIdentifier,mail,proxyAddresses,officeLocation,assignedPlans)/$entity",
"id": "<unique GUID 1>",
"displayName": "dep1",
"userPrincipalName": "dep1@mathieu.company .onmicrosoft.com",
"onPremisesSecurityIdentifier": null,
"mail": "user1@mathieu.company .com",
"proxyAddresses": [
"SMTP:user1@mathieu.company .com",
"smtp:dep1@mathieu.company .onmicrosoft.com"
],
"officeLocation": null,
"assignedPlans": [
{

Thanks!

Answer 1

MS Support has clarified that while this situation is possible, it's a bug in Azure AD they plan to fix.

Answer 2

First of all, define "migrate a user"? It doesnt look like you are synchronizing those from on-premises AD, and I know some t2t migration products provision Guest accounts as part of the process, are you perhaps in such scenario?

To set things straight, "Mail" is a different attribute from PrimarySMTPaddress/proxyaddresses, and in AD you can have duplicate values for it. In Azure AD, different rules will apply depending on the type of user, and recipient. For example, Guest users can have any value for said attribute; licensed mailbox users will be limited to only verified domains within the tenant, etc.

If you are syncing the account from on-premises AD, the uniqueness is enforced, as the value of the mail attribute is used to populate the PrimarySMTPaddress as detailed here: https://learn.microsoft.com/en-US/troubleshoot/azure/active-directory/proxyaddresses-attribute-populate
This is the reason why you actually see an error for duplicate PrimarySMTPAddress/proxyaddresses when looking in the MIISClient in such scenarios, instead of seeing a duplicate "mail" error.

None of the above applies to Guest users though, attribute duplication can occur just fine with those.

You can also refer to this article: https://learn.microsoft.com/en-us/microsoft-365/enterprise/prepare-for-directory-synchronization?view=o365-worldwide#2-directory-object-and-attribute-preparation