The following article is based on real-life examples that the author had to troubleshoot during a standard workday.

If you can contribute to its coherence and add extra references, please share in the comments section below.


In hybrid deployments, it may happen that a user who previously had used their corporate credentials to access an Office 365-related resource (eg. a SharePoint Online site), before being synced from on-premises Active Directory to the Azure Active Directory for the tenant, will become a Guest User and remain so until updated.

As a result, that user's Exchange on-premises mailbox would be mapped to Exchange Online as a Guest mail user contact type instead of Mail user type. If the tenant's Guest User has an external address (ie. address other than their primary corporate SMTP) in their ExternalEmailAddress attribute, that address will be used to divert all external correspondence going through Exchange Online, resulting in all correspondence coming from off-premises to land in an external mailbox.

User Issue Report

A user reported that all emails sent to them from external addresses as well as a part of emails sent from people from within the company end up in their private, non-corporate mailbox at Hotmail. 

Support has already investigated any potential local issues, like rules in the user's Outlook, redirection set up on the on-premises Exchange, et cetera. Everything was set up correctly, with no potential causes.

Gathering Data

​After running Get-MsolUser -UserPrincipalName XXX | Select *, the following was found:

​That user would show up under Guest Users in the Office 365 tenant:

​On Exchange Online, that user's contact item was set up as Guest mail user contact type, however using the corporate email address from the on-premises Exchange:

​The initial assumption was that changing the MSOL user type from Guest to Member would change the Exchange Online contact type from Guest mail user to Mail user, in line with all other contacts created from on-premises Exchange mailbox objects. In turn, that should allow better control over any email routing that might be happening.

​​After changing the MSOL user type from Guest to Member and allowing enough time for sync, the Exchange Online contact type was changed into Mail user type, however, their external email address was set to the user's Hotmail address - the one originally set on the MSOL Guest user as their AlternateEmailAddress / ExternalEmailAddress:

​It was confirmed that this address was the one the user had been receiving external correspondence to.

​An attempt to manually change it from the Exchange Online admin panel was unsuccessful:

The operation on mailbox '' failed because it's not of the current user's write scope. The action 'Set-MailUser', 'ExternalEmailAddress', can't be performed on the object '' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

Root Cause

​The user in question had accessed a SharePoint Online resource using their corporate credentials before they had been synchronized with the Office 365 tenant over DirSync, while the tenant had already been configured and DirSync had been running with a limited scope of synchronization. This caused the user to be set up as a Guest user on the tenant, rather than a Member that is usually created via DirSync in the synchronization process.

​When accessing the SharePoint Online resource the first time, the user specified an alternate, external email address as their alternative contact address. After the change of MSOL user type from Guest to Member, that external email address was used by Exchange Online to populate their ExternalEmailAddress attribute of their linked Mail user contact object.

​​Since the user's mailbox hasn't been migrated to Exchange Online yet, in a hybrid environment all changes needed to be done in the on-premises setup. 

​After realizing the above, the final issue was: how to update the ExternalEmailAddress attribute of an Exchange Online contact (Mail user type, already after conversion from Guest to Member), while neither the on-premises Exchange mailbox nor the Active Directory user have an attribute named ExternalEmailAddress?

This attribute is valid for contacts and mail users, not mailboxes.


All the steps to eventually resolve such issues:

1. Confirm that the corresponding MSOL user's type is set to Guest:

Get-MsolUser -UserPrincipalName "UPN" | Select UserType

2. Set that user's type to Member:

Get-MsolUser -UserPrincipalName "UPN" | Set-MsolUser -UserType Member

3. Confirm that the contact type in Exchange Online has changed from 'Guest mail user' to 'Mail user'.

4. On-premises, in Active Directory Users and Computers, set the user's targetAddress attribute to their correct primary corporate SMTP address they should be receiving emails on - this corresponds to ExternalEmailAddress attribute:

5. Run delta sync on your DirSync tool or wait for the timed job to synchronize this change with your Office 365 tenant.

6. Once synchronized, go back to the user's attribute editor and clear the targetAddress attribute.

7. Run delta sync on your DirSync tool again.

8. Confirm that the ExternalEmailAddress for the Mail user contact on Exchange Online has been changed:

Get-MailUser "samAccountName" | Select ExternalEmailAddress

External emails will now correctly flow to that user's corporate primary SMTP address rather than the external address they have specified when connecting to an Online resource for the first time while they had not yet been synchronized with your Office 365 tenant.