Native external sender callouts on email in Outlook

Published 04-02-2021 06:20 AM 10.2K Views


We know that some of our customers leverage Exchange transport rules to prepend subject line or insert the message body to show the email is from external senders. This approach has a few limitations which we heard:

  • You can end up with duplicate [External] tags in subject line if external users keep replying to the thread (some of our customers use customized solutions to remove the duplicates).
  • Adding things to subject line breaks Outlook conversation threading, as the subject line is modified, so messages no longer “belong” to the same conversation.
  • Changed subject (or message body) stays as a part of the message during reply or forward, which leads to confusion if the thread becomes internal.
  • There can be localization issues, as transport rules have no knowledge of client language that end-users are using.
  • Those additions might take a lot of space in the subject line, making it hard to preview the subject on smaller devices.

We have heard the feedback on this, and are working on providing a native experience to identify emails from senders outside your organizations (which can help protect against spam & phishing threats). This is achieved by presenting a new tag on emails called “External” (the string is localized based on your client language setting) and exposing related user interface at the top of your message reading view to see and verify the real sender's email address.

To set this up

  1. Exchange Online tenant admin will need to run the cmdlet Set-ExternalInOutlook to enable the new user interface for the whole tenant (this is available now); adding certain emails and domains to the allow list via the cmdlet is also possible.
  2. Outlook on the web already supports this. Outlook Mobile (iOS & Android) and Outlook for Mac are rolling out this feature. Specific versions:
    • Outlook on the web: available now
    • Outlook for Windows: available in May 2021 (starting with Insider Fast)
    • Outlook mobile (iOS & Android): version 4.2111.0 and higher
    • Outlook for Mac: version 16.47 and higher

If you are using the prepend subject line transport rules currently to add an [EXTERNAL] tag in external email subject line: the new Outlook native callouts are adding a new MAPI property called IsExternalSender to the email item. Once all the (above listed) client versions you require have this functionality, to avoid emails being marked ‘External’ twice (once by new native functionality and once by the transport rule), please turn off the transport rule first before turning on Outlook native external sender callouts.

We are tracking this feature in Microsoft 365 Roadmap ID 70595. This feature can be enabled on the tenant level now.

Outlook on the web, Mac, and mobile will display an External tag in the message list. Outlook Desktop and OWA will show the sender's email address at reading pane info bar. Outlook mobile and Outlook for Mac will only see an external tag on the message reading pane, and users will need to click the tag to see the real sender’s email address.

Outlook on the web view of External sender:


In Outlook for iOS, External sender user interface in the message list, External tag when reading chosen email and view of sender's email address after tapping External label:


Once this feature is enabled via PowerShell, it might take 24-48 hours for your users to start seeing the External sender tag in email messages received from external sources (outside of your organization), providing their Outlook version supports it.

If enabling this, you might want to notify your users about the new feature and update your training and documentation, as appropriate.

Let us know here if you have any feedback!

The Outlook Team

Occasional Contributor

Thank's for the clarification for Outlook for Windows an Mac Versions

Senior Member

I assume the Outlook for Windows availability date should be May 2021 not 2020 as stated above? When will this feature be added to Semi Annual Enterprise Channel? Love this feature but it does need more customisability... we need greater controls over the Allow List for senders that should not be tagged as external. The current limitations of 30 senders/1KB are way too small for large enterprises. We should also be able to exclude senders based on other criteria e.g. x-header.

Not applicable

Do we have an option to exclude for certain senders?  If so, do you exclude by domain name, ip or range of IP addresses?  Thanks!

New Contributor

What about on premesis Exchange? Actually I‘m setting an X-Message-Flag with a transport rule but the solution above seems better. 

Senior Member

What are the benefits to users of distinguishing between internal and external? According to the Zero Trust concept, it is not appropriate to judge safety internally or externally. It would be more effective to display the impersonation judgment based on SPF, DKIM, and DMARC.

Occasional Contributor


For Instance Images are downloaded automatically on internal Mails. This does not happen on external Mails. This Setting makes it only more visible for Clients. Especially on Mobile Clients.



It is clearly stated that this is an Exchange Online Command / Functionality. I would not have high hopes that this comes back to OnPrem.

Occasional Contributor

Thanks for sharing this, looking forward to testing this!

New Contributor

I realized this cannot be deployed to subset of users for testing/reviewing puposes?

Senior Member

Great news! Any chance to pilot the feature for limited group?

New Contributor

The -allowlist parameter seems not working 

Set-ExternalInOutlook -AllowList


And the Get-ExternalInOutlook still empty value for AllowList

Enabled : True
AllowList : {}


Senior Member

Any advice on how to make use of this while still having the "old" methods as a fallback when a user is using a third-party mail client? Without that, this seems like a wasted effort. For example, is there a way to utilize a "prepend text" transport rule that prepends an external warning banner which does not appear if viewed in an Outlook client--effectively providing the native experience for Outlook clients, and the fallback experience for third-party clients? Without something like that, we (university) would unfortunately never be able to take advantage of the native experience as we would never get buy-in on blocking third-party mail clients.

New Contributor

 "Outlook Desktop and OWA will show the sender's email address at reading pane info bar." So there will be no difference for Desktop users? Or if it is, could anybody please share a screenshot of what it would look like? I have not found a way to test this for a small group of users. If there is no difference for Desktop users, is the plan to implement this further down the line? Thanks 

Occasional Visitor

Will this ever be available for Windows Outlook 2016 / 2019 clients?

Occasional Visitor

Today's best news, really useful feature! 

Senior Member

What about Hybrid, with external emails arriving first OnPrem they going to Exchange Online?

New Contributor

How will these play with Anti-Impersonation and First Contact Safety Tips? What about non-Outlook clients? I can see First Contact Safety tips in Gmail app for example. 

New Contributor

I really like the simplicity of the functionality.  But I tend to agree with @shark_it . As more and more organizations rely on external services for everyday applications and services we need a bit more flexibility than just allowed domains in the cmdlet. 


We have internal mail relays that we would prefer to not show as 'external' or 3rd party services we rely on and have trusted partnerships with this can become confusing to the end-user and ultimately just make them associate anything 'external' as bad.  


What is Microsofts recommendation - the action is this blog post, or thing command:

Set-OrganizationConfig -MailTipsExternalRecipientsTipsEnabled $True

Frequent Contributor

Please add some example screens it's how this will look in Outlook Desktop too. Would make it easier to explain this internally. But in short - great feature.

New Contributor

Glad to see this feature request getting traction. Having a native option to enable this will certainly make it easier for less technical orgs, but also streamline it for others. Will certainly be discussing this with the team and likely implementing soon. Thank you!

Version history
Last update:
‎Apr 05 2021 08:00 AM
Updated by: