Comparing Azure AD Guest Accounts and Exchange Online Mail Contacts

Are Guest Accounts Better Than Mail Contacts?

During an online discussion following publication of my article about how to purge guest accounts with unredeemed invitations from Azure AD, Microsoft’s Jef Kazimer said that he sees many Microsoft 365 organizations using guest accounts instead of mail contacts because guest accounts have better lifecycle management, even if the guests never sign in.

That idea got me thinking. Exchange Online is the largest Microsoft 365 workload and some organizations create many thousands of mail contacts for different reasons. For instance, they might have contacts for people in partner organizations so that users can easily find those contacts in the Global Address List (GAL). Mail contacts also exist in Exchange Server and many of the contacts now in Exchange Online originated. Hybrid organizations can synchronize on-premises contacts to Azure AD, but the management of those objects must be done on-premises.

Understanding Mail Contacts

Before comparing mail contacts with Azure AD guest accounts, we need to understand what a mail contact is. Mail contact objects exist in both the Exchange directory (EXODS) and Azure AD. For example, to create a mail contact, you run the New-MailContact cmdlet:

New-MailContact -Name Jef.Kazimer -DisplayName "Jef Kazimer" -ExternalEmailAddress "" -FirstName "Jef" -LastName "Kazimer"

This action creates a contact object in both Exchange Online and Azure AD. The Exchange object is what people think of when they think about a mail contact. The Azure AD object exists to hold properties unrelated to email processing. Because it uses mail contacts as addressable email recipients, all Exchange Online really cares about is the email address. Once an object has an email address, Exchange can route messages to it and allow the object to participate in distribution lists. The Get-MailContact cmdlet confirms the details of the new contact object:

Get-MailContact -Identity Jef.Kazimer | Format-Table DisplayName, ExternalEmailAddress

DisplayName ExternalEmailAddress
----------- --------------------
Jef Kazimer

The external directory object identifier stored in the mail contact points to the Azure AD object, which we can retrieve using the Get-MgContact cmdlet from the Microsoft Graph PowerShell SDK:

Get-MgContact -OrgContactId (Get-MailContact -Identity Jef.Kazimer).ExternalDirectoryObjectId | Format-Table displayName, proxyAddresses

DisplayName ProxyAddresses
----------- --------------
Jef Kazimer {}

The mail contact is a sparse object so far. To populate the other properties that you might want users to see in the GAL (Figure 1), you must run the Set-Contact cmdlet to update the Azure AD object:

Set-Contact -Identity Jef.Kazimer -StreetAddress "14, Preston Villas" -City "Bellevue" -StateorProvince "Washington" -PostalCode "98004" -Phone "+1 425-214-765" -MobilePhone "+1 425-214-705" -Pager $Null -HomePhone "+1 425-270-765" -Company "Contoso" -Title "Azure AD Guru" -Department "Information Technology" -Fax "+1 425-214-761" -Initials "JK" -Notes "Distinguished Person" -Office "Liberty Square" -CountryOrRegion "United States"
A fully-populated mail contact as seen by Outlook for Windows
Figure 1: A fully-populated mail contact as seen by Outlook for Windows

The Get-MgContact cmdlet reports the newly-populated properties as does the Get-ExoRecipient cmdlet. There are some exceptions and caveats:

  • Remember to include the PropertySet All parameter to force Get-ExoRecipient to retrieve the full set of properties.
  • Get-ExoRecipient doesn’t retrieve the street address because it’s not included in the GAL.
  • Get-MgContact uses compound properties to hold some information. For instance, to see the elements of a contact’s address, you must expand the properties stored in the Addresses property:
Get-MgContact -OrgContactId (Get-MailContact -Identity Jef.Kazimer).ExternalDirectoryObjectId | Select-Object -ExpandProperty Addresses

City     CountryOrRegion OfficeLocation PostalCode State      Street
----     --------------- -------------- ---------- -----      ------
Bellevue United States   Liberty Square 98004      Washington 14, Preston Villas

Managing Mail Contacts

A Set-MailContact cmdlet is available to update properties of the Exchange objects, including the set of custom attributes available for all mail-enabled objects. The Set-Contact cmdlet updates the information held in Azure AD contact objects such as the address data shown above.

When administrators manage mail contacts through the Microsoft 365 admin center or Exchange admin center, they can work with both Exchange Online and Azure AD object properties. The GUI hides the fact that the settings presented to the administrator come from two directories, much like it disguises the interaction between Azure AD and Exchange when managing mailbox-enabled user accounts.

Guest Accounts and Guest Mail Users

Now that we understand mail contacts, let’s discuss the relationship between Exchange Online and Azure AD guest accounts. Following the creation of a guest account, a background process creates a special type of mail user object with a RecipientTypeDetails setting of GuestMailUser based on the properties of the guest account. The mail user object allows:

  • Guest members of Outlook groups to participate in group conversations via email.
  • Mail routing to guest accounts.
  • Guest accounts to appear in the GAL and other Exchange address lists.

Guest mail user objects exist in the Exchange directory until the removal of their linked guest accounts from Azure AD. Although you can view guest mail user objects through the Exchange admin center, the GUI won’t allow you to update their properties.Changes must be made to the guest account using the Azure AD admin center or with a Graph API (including the Microsoft Graph PowerShell SDK cmdlets). You can update the Exchange-specific properties with the Set-MailUser cmdlet.

To see the set of guest mail user objects, run the Get-ExoRecipient cmdlet:

Get-ExoRecipient -RecipientTypeDetails GuestMailUser | Format-Table DisplayName, PrimarySmtpAddress, HiddenFromAddressListsEnabled

The last property is True (the default) if the guest account isn’t visible to Exchange address lists. Run the Set-MailUser cmdlet to update HiddenFromAddressListsEnabled to True to expose the object. Here’s an example:

Set-MailUser -Identity -HiddenFromAddressListsEnabled $False

Note that it takes at least a day before newly exposed objects show up in the offline address look (OAB).

Adding Guest Mail Users to Distribution Lists

Because the guest mail users are routable objects, they can be added to distribution lists. This example spells things out, but it’s possible to add a guest mail user to a distribution list by passing its display name or email address without going to the bother of fetching the object with Get-MailUser.

$GuestMailUser = Get-MailUser Get-MailUser -Filter {DisplayName -eq "Warren Gatland" -and RecipientTypeDetails -eq "GuestMailUser"}
Add-DistributionGroupMember -Identity "o365maestro Contacts" -Member $GuestMailUser.Name

Move to Guest Accounts or Stay with Mail Contacts

Getting back to the original point, Jef says that guest accounts have better lifecycle management. In other words, if an organization invests in creating guest accounts instead of mail contacts, they’ll benefit from the work Microsoft does to improve how Azure AD manages external identities.

There’s some truth here. An Azure AD guest account supports more properties, including custom security attributes and support dynamic Azure AD Groups and dynamic Azure AD administrative units. They’re a Microsoft 365 entity rather than being restricted to just Exchange Online. Azure AD development for external identities, including guest accounts, is active whereas I suspect the development effort for Exchange mail contacts entered an “only fix bugs” maintenance stage years ago. On the other hand, mail contacts are simple and effective and work across hybrid Exchange organizations.

If you’re a cloud-only organization, the choice exists to use either. If you decide to use Azure AD guest accounts, the existence of guest mail user objects smoothen the transition and make sure that address lists, distribution lists, an email routing continue working. Azure AD guest accounts are a better long-term bet, but that doesn’t mean that anyone should switch anytime soon.

Learn more about how the Microsoft 365 applications like Exchange Online and Azure AD really work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

10 Replies to “Comparing Azure AD Guest Accounts and Exchange Online Mail Contacts”

  1. Hello, I was wondering if it is possible to use guest accounts or mail contacts to set S/MIME public keys (userSMIMECertificate)? This would allow to centrally publish external users public keys for S/MIME encryption.

  2. Can I use ADconnect to sync contact to Guest account in azure AD instead of Powershell? I tried to set SourceObjectType to User for Contact in In from AD – Contact rule and set userType to Guest in Out to AAD – User join rule(this rule probably is not right. It should be Contact join rule? Not see UserType under Contact rule), but not able to get it done. Metaverse search shows none SourceObjectType of contact is even changed to User. What is the missing part? Thanks!

      1. Thanks, Tony. I know this is a rare situation. We eventually can sync Contact as Guest account using ADConnect by playing rules for in from AD-User Join, in from AD-User Common and Out to AAD-User Join. Need set SourceObjectType to User and userType to Guest. We hope this conversion can resolve “Use not in directory” for Sharepoint external sharing login issue. But the conversion results in other login issues. So, we revert back to keep Contact in Azure AD. We see that, for an existing azure contact to be able to login SPS, the guest account needs to be invited from Azure AD once the contact gets the sharepoint login error. One Time Passcode is not enough since the guest account created from OTP login flow does not have proxy address.

  3. I’ve just started at a small membership based org that is now 365 cloud-only.
    I was asked to make the members of our ancient CRM appear as contacts so that Outlook users wouldn’t be copy/pasting all the time.

    I saw this article and I prefer the idea of using Azure guests – partly because that seems like the future way, but also because about 25% of our members are already Azure guests because they take part in meetings / collaborate on files / etc and so are in AAD.

    I have a nascent script that can dump the CRM members into AAD as guests, skipping those already there… based on your Contact conversion one … but I’m interested what might happen if one of these ‘new’ guests then is invited by email to share a file, or join a Team.
    What happens when they find out they already have a guest account in our tenancy?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.