External tag not removed for MTO members in Outlook

Question

The customer is part of a Microsoft 365 Multi-Tenant Organization (MTO) with a parent tenant and has enabled "Suppress Outlook external tag for MTO members". However, Outlook still displays the External tag for users with the @contoso.com domain, while the tag is correctly suppressed for users with the @contoso.onmicrosoft.com domain. The automatically created Remote Domain appears to use contoso.onmicrosoft.com instead of contoso.com, causing external tag suppression to work only for the onmicrosoft.com domain. Adding contoso.com to the External Sender Identification Allow List using Set-ExternalInOutlook -AllowList contoso.com did not resolve the issue after several days. Additionally, the issue is observed in both directions between the member tenants.

Answer 1

Hi Bindu M S

Based on my research regarding the [External] tag remaining visible for Multi-Tenant Organization (MTO) members using your custom domain. This behavior arises from how the automated MTO configuration wizard interacts with Exchange Online’s mail flow boundaries

When the setting “Suppress Outlook external tag for MTO members” is enabled, Microsoft 365 automatically creates a backend Remote Domain entry for the partner tenant and marks it as internal (IsInternal = $true). This specific flag is what instructs Outlook to suppress the external tag.

However, the automated MTO setup wizard only provisions this Remote Domain for the partner tenant's default routing domain (.onmicrosoft.com). It does not automatically discover or add custom vanity domains (like @contoso.com).

Because of this:

• Messages via @contoso.onmicrosoft.com match the automated entry > recognized as internal > Tag is suppressed.
• Messages via @contoso.com fail to match the entry > classified as standard inbound mail > Tag is displayed.

This also explains why the issue is strictly bidirectional and why standard cross-tenant services like Teams work perfectly (as Teams relies on Entra ID cross-tenant sync attributes, whereas Outlook strictly follows Exchange mail flow perimeters).

The Set-ExternalInOutlook -AllowList cmdlet evaluates the visible From address (P2 sender). In complex MTO setups, Outlook’s perimeter logic defers heavily to defined Remote Domains. If a domain isn't explicitly classified as an internal mail flow boundary via a Remote Domain entry, standard allowlist overrides are frequently bypassed.

To resolve this, you will need to manually define the custom domain as an internal Remote Domain boundary. Because this affects inbound mail flow, these steps must be completed by an Exchange Administrator in both tenants for each other's custom domains.

Note: The option to mark a Remote Domain as internal is not exposed in the Exchange Admin Center (EAC) visual interface. You must create the domain via the admin portal and then flip the internal flag using PowerShell

Create the Remote Domain in the Portal

• Open the Exchange Admin Center (admin.exchange.microsoft.com).
• Navigate to Mail Flow > Remote Domains and click *Add a remote domain > *Name it descriptively (for example: MTO Partner Vanity Domain).
• In the Domain box, type the partner's custom domain (ex: contoso.com) > Click Save.

Set the Domain to Internal via PowerShell

Connect to Exchange Online PowerShell:

Connect-ExchangeOnline

Run the following command using the exact name you specified in step "Create the Remote Domain in the Portal"

Set-RemoteDomain -Identity "MTO Partner Vanity Domain" -IsInternal $true

Allow Time for Replication

Exchange Online mail-flow perimeters and Outlook configuration tables rely on heavy client-side and cloud caching. Please allow 24 to 48 hours for these changes to fully replicate across all Outlook endpoints (Desktop, Web, and Mobile).

Since manually creating Remote Domains introduces extra management overhead whenever you add new custom domains in the future, you may want to open a formal support ticket with official Microsoft 365 Support. This helps bring visibility to the limitation so the Microsoft product team can consider expanding the MTO wizard's automated domain scope in future updates.

I hope this information helps and if you have any further question, please feel free to let me know via comment section!

---

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

The behavior is explained by how Outlook external tags and multitenant org (MTO) suppression work together with Remote Domains.

1. What the MTO setting does
   When "Suppress Outlook external tag for MTO members" is enabled in the MTO settings, Microsoft 365 automatically creates a Remote Domain for the partner tenant and marks it as internal (IsInternal = true). This is what removes the External tag for messages between tenants in the MTO.
2. Why suppression only works for contoso.onmicrosoft.com
   The documentation states that if external tags are not already enabled, checking External tag suppression will automatically create a Remote Domain for the partner tenant and mark it as internal, but:

   If the tenant hasn't enabled external tags in Outlook, checking the External tag suppression option will automatically create a remote domain for the partner tenant and mark it as internal (i.e., IsInternal = true), but it won't have effect in end user experience. In this case, external tags aren't displayed to members in MTO.

   In the described case, the automatically created Remote Domain is using contoso.onmicrosoft.com. That means:
   • Messages using the @contoso.onmicrosoft.com domain match this Remote Domain and are treated as internal, so the External tag is suppressed.
   • Messages using the custom domain @contoso.com do not match that Remote Domain, so they are still treated as external and the External tag appears.
   The MTO suppression feature does not automatically create or adjust Remote Domains for all custom SMTP domains (such as contoso.com) used by the partner tenant; it is scoped to the tenant’s default/onmicrosoft.com identity.
3. Why Set-ExternalInOutlook -AllowList contoso.com did not help
   The external sender identification allow list (used by Set-ExternalInOutlook) is a separate mechanism from the MTO suppression setting. The MTO suppression relies on Remote Domains being marked as internal. Adding contoso.com to the allow list does not change the Remote Domain configuration or IsInternal status, so it does not affect the MTO-based suppression behavior.
4. Implication for the scenario
   Based on the documented behavior:
   • The current MTO suppression setting is functioning as designed for the automatically created Remote Domain (which is tied to contoso.onmicrosoft.com).
   • Because the custom domain contoso.com is not the one used in that automatically created Remote Domain, messages using @contoso.com remain tagged as External.
   • The issue appearing “in both directions” between member tenants is consistent with each tenant’s MTO suppression being scoped to the other tenant’s onmicrosoft.com identity rather than all custom domains.

To fully align the behavior for contoso.com, a Remote Domain configuration that treats contoso.com as internal would be required. The provided documentation, however, only describes automatic creation of a Remote Domain for the partner tenant’s default/onmicrosoft.com domain when enabling the MTO external tag suppression setting and does not document automatic handling of additional custom domains.

---

References:

• Manage multitenant org settings
• What is the External label on Outlook mobile email?
• Why is there no External label or External mail tooltip on an external email?