Native external sender callouts on email in Outlook
Published Apr 02 2021 06:20 AM 231K Views

Overview

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: Update 10/6/23: This feature is now available in Semi-Annual Enterprise Channel (Preview) too. External Tag view in Outlook for Windows (matching other clients) released to production for Current Channel and Monthly Enterprise Channel in Version 2211 for builds 15831.20190 and higher. We anticipate the External tag to reach Semi-Annual Preview Channel with Version 2308 on the September 12th 2023 public update and reach Semi-Annual Enterprise Channel with Version 2308 with the January 9th 2024 public update.  If any of the versions or dates change we will update this topic. See Update history for Microsoft 365 Apps (listed by date) to see release status of versions.
    • Outlook mobile (iOS & Android): version 4.2111.0 and higher
    • New 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 tracked 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 for Windows view of External sender (note that the experience is slightly different from others below):

ExternalCalloutsOutlook2.jpg

Update 11/3/2022: The newer External Tag view for Outlook for Windows (matching other clients) is currently rolling out:

OLupdatedexternal.png

Outlook on the web view of External sender:

NativeOLExternal01.jpg

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:

NativeOLExternal02.jpg

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

149 Comments
Steel Contributor

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

Iron Contributor

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.

Deleted
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!

Copper Contributor

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

Copper Contributor

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.

Steel Contributor

@shark_it 

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.

 

@wkwi108 

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

Thanks for sharing this, looking forward to testing this!

Brass Contributor

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

Copper Contributor

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

Brass Contributor

The -allowlist parameter seems not working 

Set-ExternalInOutlook -AllowList domainname.com

 

And the Get-ExternalInOutlook still empty value for AllowList

Enabled : True
AllowList : {}

 

Iron Contributor

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.

Copper 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 

Copper Contributor

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

Copper Contributor

Today's best news, really useful feature! 

Brass Contributor

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

Copper 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. 

Brass 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.  

Brass Contributor

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

Set-OrganizationConfig -MailTipsExternalRecipientsTipsEnabled $True

Steel 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.

Brass 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!

Copper Contributor

Good start but how can I address obvious spoofed email addresses such as this one:

billoreilly_0-1618859385931.png

Would like to be able to add "Spoofed Sender" banner.

Copper Contributor

I hope there is going to be more work in the area of exceptions.  Excluding only to the recipient's email address is seriously weak.  Example, we have lots of cloud services, Azure, DATP, MCAS, and other non-microsoft services that generate email from external, that we do NOT want our current "External Disclaimer"  to be stamped on.  In those cases we use an exception based on the DKIM signature.  You also may want to exclude IP based on sender's IP range.

 

We are a college and it would be simply chaotic to have emails from Blackboard or Canvas, for example, to all suddenly be labeled in this matter would scare recipients into thinking these emails are not legitimate.  Having the robust range of options in a transport rule, will keep us from using this until there are better exclusion options for this new commandlet.

Brass Contributor

If Outlook also had optional tiny color-coded callouts for SPF, DKIM, DMARC (green=pass, none=grey, fail=red) the adoption rate of DMARC would skyrocket. And people would learn real quick what their purpose was.

 

Just one callout for DMARC alone would be amazing and easier to implement since you wouldn't need to handle exceptions.

Copper Contributor

I agree with @Shon Miles that the exception by domain would defeat most of the reason for showing the alert.  Unless there is something else that would flag impersonated From addresses, or if it were exception by verified domain, it would allow our domain to be impersonated if we allow any legitimate emails to be sent by a third-party service.

Is there any possibility that the IsExternalSender flag could be set by a transport rule that we control?  This could give the benefits of having the alert always show in the clients, as well as not mangling the Subject or body or having it duplicated in the Subject.

Copper Contributor

@The_Exchange_Team  it would be good to be able to test this on few users first instead of applying to entire organization all at once. 

 

This has been major shortcoming for many features recently, All in or all out.

Since we cant really control this change, we opt not to implement and I am sure other companies feel the same way.

Many of the concerns raised above are applicable to us as well, things like what Shon Miles has mentioned are very practical in many organizations.

 

Copper Contributor

Has The Exchange Team designed something here which could be adopted across the industry as a common standard?

 

We know there are issues with the transport rule method (side note: an important limitation not mentioned in this article is that a targeted phishes can easily obfuscate the prepend html see: https://whynotsecurity.com/blog/external-email-warning-bypass/). This external tag is a remediation against all these limitations.

 

I'd be keen to use this IsExternalSender flag instead of prepend html, however it's currently only useful for Outlook users. If a user adds their O365 mailbox to another mail client, they wouldn't get any warning if we turned off external transport rule.

That makes me somewhat apprehensive about turning off the transport rule. I appreciate "perfect can be the enemy of good", and that 95%+ of our users would benefit from using the External Tag instead of the transport rule.

 

Can @The_Exchange_Team take the use of this MAPI property as a way to encourage adoption by the wider mail community (mail service providers and mail client developers), so that a common way of handling external tags across the industry is developed over time?

Copper Contributor

Victor Ivanidze - Thank you!!

Copper Contributor

I honestly love this!

 

I just have a few questions that I hope you can answer.

 

  1. Will it be possible to customize the external warning message?
    • I'd like to also tell users about the "Report Message" button, if it is an unsafe sender.
  2. Is it possible to enable this for a test group and not all users?
    • I'd like to test it out beforehand
  3. We will be able to enable this in the Exchange Admin Center at some point or only PowerShell?
    • It's a little easier for me to take screenshots and show them to management.
Bronze Contributor

Hello all,

 

we are going to release a small utility for Windows that will allow a tenant admin to modify the configuration of external sender identification. No PowerShell at all!

 

I'll inform you here soon.

 

UPDATE: Here it is.

Bronze Contributor

Hello all,

 

it looks like my modifications in the AllowList takes "from 24 to 48 hours".

I've executed 

Set-ExternalInOutlook -AllowList  jdoe@domainname.com

Get-ExternalInOutlook

Enabled : True
AllowList : {jdoe@domainname.com}

30 hours ago. But when I send a message to jdoe@domainname.com the tag External is still visible in OWA.

Can somebody confirm that?

Steel Contributor

@Victor Ivanidze 

I guess that the Internal/External is stamped at the Receive Time. I think, when you change the Setting it will only affect new received Mails.

 

Regards Andres

Bronze Contributor

Hi @Andres Bohren,

 

It seems I was unclear. 

I've changed the AllowList 32 hours ago. A minute ago I've sent a test message. It's still tagged that means AllowList is not used.

Copper Contributor

Has this feature been enabled on Windows 10 With outlook yet. In the thread it mentions May 2021. Any update??

 

Bronze Contributor

Hi @dhruv9211,

 

not yet - at least on my Windows 2010 and Microsoft® Outlook® for Microsoft 365 MSO (16.0.13929.20206) 32-bit.

Steel Contributor

@Victor Ivanidze 

Works here

ExO_ExternalInOutlook_04.jpg

ExO_ExternalInOutlook_05.jpg

Copper Contributor

@Andres Bohren @Victor Ivanidze 

Oh that's great!
We're currently still using Outlook Version 2104 and haven't received the feature yet.

 

Bronze Contributor

Hi all,

on my tenant AllowList just doesn't work.

Update: It has started working in 60 hours after populating AllowList.

Copper Contributor

Hi all,

 

I want to test this feature on individual email addresses before I enable it for our entire domain.  Does the Set-ExternalInOutlook cmdlet allow for this?  In everything I read online, I can't find if this is possible (I can't find a parameter to enable individual email addresses, and not the entire domain).   I only see the parameter to exclude addresses (AllowList).  Please confirm.  Thank you.  Others have asked this question here, but I don't see the answer.

 

Also, some people in the previous comments (starting with Shark_IT) argue this feature is not beneficial.  I disagree.  Our users often receive emails purporting to be from our IT Dept. (from me and my team).  (They get past the Office 365 mail filter and have spoofed sender addresses.)  And our users ask us if those emails are legitimate.  If those emails were marked "External" our users would know they are not from us.  Granted, there are ways to figure out that the email is fake (but many of our users don't spot the easy clues).   We are trying to train our users to spot fake, malicious emails.  But this feature makes it much easier.  We don't ever have any fake or malicious emails originating internally.   What is the harm?  I don't see any downside to enabling this new feature.

 

-David

Bronze Contributor

Hi @ians-uleth,

 

could you please let me know what "third-party clients" do you mean?

 

Copper Contributor

@Andres Bohren , do you have more screenshots of the normal Outlook client?

I've some questions about it:

1. are pictures of external senders automatically loaded

2. can you see the external tag in the list of emails

3. in the mail itself, is it only notifying about an external user or also prompt a block message (I see diffrent screenshots).

 

So it would be great to see the differences about the webclient and the normal client.

 

Thanks!

Iron Contributor

@Victor Ivanidze- Third-party client meaning any non-Outlook mail client such as Spark, Mozilla Thunderbird, Apple Mail, etc.

Bronze Contributor

Hi @ians-uleth, thanks for your answer.

Could you please confirm the only method of tagging that will work with all these mail clients is modifying of the Subject line?

Steel Contributor

@Victor Ivanidze But keep in Mind that changing the Subject Line may break the DMARC Signature.

Steel Contributor

@Marinus Witbraad 

>are pictures of external senders automatically loaded

Depends on your Junk-E-Mail Settings. Nothing new here

>can you see the external tag in the list of emails

In Outlook on the Web: Yes

In Outlook for Windows: No. You just see it in the Preview below the Subject Line / To FieldsOutlook_External2.jpg

 

Outlook_External.jpg

>in the mail itself, is it only notifying about an external user or also prompt a block message (I see diffrent screenshots).

Don't know what you mean. I see only the Above.

 

Regards

Andres

Iron Contributor

@Victor Ivanidze  - Not sure what you're getting at, seems you're missing the point of my original post. Of course a subject line tag, or a body prefix/suffix would work with third-party clients. The problem is that there are no controls on this new Exchange Online feature to say first-party clients get the ExternalInOutlook warning while third-party clients and only third-party clients get a fallback method of a body prefix/suffix or subject line tag.

Bronze Contributor

Hi @ians-uleth,

 

let's suppose I create a group named "ThirdPartyClients" and also create a transport rule that will place "External" tag to the Subject/Body of the messages addressed to the members of this group.

 

After enabling MS native ExternalInOutlook the first-party clients will use it but the members of "ThirdPartyClients" group will see modified Subject/Body.

 

Is this acceptable for you as a possible solution ?

Steel Contributor

@Victor Ivanidze 

What are you trying to archieve with the Tagging of External Mails? Improve User awareness and security right?

If you really want to improve security, then get rid of the Legacy Authentication Protocols and move to modern Clients that support Modern Authentication and Conditional Access Policies.

 

MSRSA_Account-Compromise-Rates.jpg

Iron Contributor

@Victor Ivanidze- Interesting idea, thanks for that. But unfortunately that would not quite do the trick. Users that use both Outlook and third-party clients would see the fallback tag in Outlook, and I'm sure we have a lot of users that would fall into that category. But appreciated nonetheless!

Copper Contributor

This is not meant to tag subject or body of the email, it adds it's own little table.

 

This is good because if you add the word "externa" to the subject or body you can't search or sort properly.

 

You can only see these on the Outlook clients either windows or mobile.

 

 

Copper Contributor

We enabled it about 24 hours ago. It now works on mobile clients. It does not work on the desktop clients. We are running version 16.0.13901.20516. The monthly enterprise channel. When will it work in the desktop client? What version do we need? I tried looking at the changelog for Office, but couldn't find any mention of this in any of the latest versions?

 

https://docs.microsoft.com/en-us/officeupdates/current-channel

Co-Authors
Version history
Last update:
‎Oct 06 2023 08:59 AM
Updated by: