Table of Contents
Helping Exchange Protect Users from Bad Email
Given the amount of spam floating around today, it comes as no surprise that many organizations deploy an Exchange transport rule to mark inbound external email with a suitable warning. This is a straightforward rule to configure and it can help stop users being fooled by bad messages that get past the array of checks used by Exchange Online Protection to detect and suppress spam. Even the best anti-spam defense is sometimes fooled by a phishing attempt (at times, you wonder how some “amateur night at the races” phish attempts manage to get through).
Visual Marking to Help Users
The usual approach is to add two visual markings to external messages with the aim that these markings highlight the risk that could be present in external email. The first marking is a disclaimer placed at the top of the message body; the second is a prefix added to message subjects. In the rule below, we see that some HTML text is used for compose the disclaimer while a simple “#External:” prefix is used for the message subject.
Refining the Rule
Exchange applies the rule to any message sent from an external domain to a recipient within the organization. You can get pretty creative with the conditions that cause a rule to fire with the aim of only applying marking to messages that deserve to be treated with some caution. For instance, you could add a condition so that the rule would only fire if the message had an Spam Confidence Level (SCL) higher than 1. This means that any message that came through Exchange Online Protection’s spam checking with an SCL that says it definitely isn’t spam would not be marked. Exchange Online delivers messages with an SCL of 5 or higher to users’ Junk Email folders.
You could also look for a value in a message header and use it to decide if to apply marking. For instance, you might decide to mark all messages that don’t pass DMARC checking (look in the Authentication-Results header for dmarc=none or dmarc=fail).
The Message Header Analyzer tool is very useful when reviewing message headers to decide which to use and what value to look for. This is an add-in that you can load into Outlook (and OWA) to run against messages in your mailbox.
Adding Exceptions
As in the case of rules to add disclaimer text or auto-signatures to outbound messages, I usually add some exceptions to the rule. The first exception is to stop Exchange applying the rule to messages where the #External: prefix already exists in the subject. The logic here is that if someone is involved in a messaging thread, they’ve made the decision that it’s safe to do so and don’t need to be reminded for each reply.
The second exclusion is to not apply the marking for well-known domains. The exact list of these domains will differ from organization to organization but is likely to include important partners and trusted companies, like petri.com and microsoft.com as shown in the example. You could also add onmicrosoft.com to exclude Office 365 tenants that use their service domains for email. However, some spammers have used Office 365 tenants in the past, so this exclusion comes with some risk.
Using exceptions and refining the rule so that not all inbound email is marked has two effects. First, it means that marked messages have a meaning that they won’t have if every inbound message is marked. Second, it stops users complaining when perfectly legitimate business communications are marked. You wouldn’t paste a great big warning label across every parcel that comes into the company by post, so there’s no need to warn about every message coming into your tenant.
Composing HTML Marking
Most email is in HTML format today, so it makes sense to compose the marking in HTML. You might be fluent in HTML, but I am not, so I used the online HTML editor to compose the text and then cut and pasted the HTML into the EAC rule editor.
I also added a small (25 x 25 pixel) graphic to make the marking more visually interesting. All you need is a small graphic file located on a web site that can be reached by Exchange. The HTML I ended up with is:
<p><strong><span style="background-color: #ff6600;"> [WARNING]</span> </strong>This message comes from an external organization. Be careful of embedded links. <img src="https://i0.wp.com/office365itpros.com/wp-content/uploads/2019/03/stop.jpg" alt="Stop" /></p>The Rule
The important parts of the rule (as returned by the Get-TransportRule cmdlet) are shown below:
FromScope : NotInOrganization
SentToScope : InOrganization
HeaderContainsMessageHeader : Authentication-Results
HeaderContainsWords : {dmarc=fail, dmarc=none}
ExceptIfSubjectContainsWords : {#External:}
ExceptIfSenderDomainIs : {bwwmediagroup.com, audi.ie, revenue.ie, dell.com...}
ApplyHtmlDisclaimerLocation : Prepend
ApplyHtmlDisclaimerText : <p><strong><span style="background-color:#ff6600;">[WARNING]</span> </strong>This message comes from an external organization. Be careful of embedded links.<img src="https://i0.wp. com/office365itpros.com/wp-content/uploads/2019/03/stop.jpg" alt="Stop" /></p>
ApplyHtmlDisclaimerFallbackAction : WrapThe Visual Effect
The visual marking for the message body is shown below. Of course, the danger always exists that users will become used to the warning and ignore it over time, so it might be good to change the wording, color, or images used over time.
Remember to check that the marking shows up well on all email clients in use, including mobile devices. Also, any change to an Exchange Online transport rule takes some time to be effective within a tenant due to rule caching and the need to update multiple servers.
Markings Only Warn
The best and most obvious markings that a message might be suspect can and will be ignored by human beings. That sober recognition of what people are capable of might discourage you from adding marking rules, but that’s no reason not to go ahead and use this technique. After all, if it stops one person being phished, it’s worthwhile.
Need more help with Exchange transport rules? Look no further than Chapter 17 of the Office 365 for IT Pros eBook. It’s packed full of useful information about email processing and anti-malware techniques.
Tony, is this line correct? “This means that any message that came through Exchange Online Protection’s spam checking with an SCL that says it definitely isn’t spam would be marked.” Shouldn’t it say “would not be marked”?
Yes, typo. Caused by brain fart.
I thought it was just your speedy fingers at work. Easily done. Thanks for updating it.
Another question for clarification: the text says ” … while a simple “#External:” prefix is used for the message subject” … but the screenshot looks like it has a trailing space, as in ‘#External: “. When I tried this yesterday, Exchange Online said I couldn’t have a trailing space – how did you pull that off?
Hello Tony, thanks for this great post.
We will also activate this rule, but how can we handle signed or encrypted incoming emails?
Exchange can’t edit the Body of an signed or encrypted email, right?
Exchange can process some encrypted email (protected with rights management). The messages that it can’t will be ignored. But always do some testing to understand exactly what you will deal with before full implementation.
For instance, you could add a condition so that the rule would only fire if the message had an Spam Confidence Level (SCL) higher than 1.
This does not work. I’ve tried and tested it. Seeing documentation that the SCL is stamped after the Transport Rules. Doesn’t make sense that it would be an option in the rules if this was the case, but my testing bears that out. Give it a try. Recipient is from Outside Org and Sender is located Inside Org and the message has an SCL greater than or equal to 0, Do the following. Prepend the Disclaimer. SCL with 0 and above will not get the disclaimer applied.
Is there a way to create a transport rule for incoming emails to only fire when there is only one recipient? Only one address in To: and nothing in Cc: or Bcc:?
What’s the use case for such a rule? I don’t think this is possible but I am curious why it is needed.
Hi Tony,
A big challenge for some customers is the aesthetics of how the Inbox preview is impacted by the prepended External body tag across the multiple Exchange clients which all have different display behaviors.
Is there any current or future integration with AIP Labeling for example? I have seen in documents that AIP can raise certain labels in the Outlook receive form envelope banner (gray). Similar to the new Unauthenticated Sender notice that puts a question mark next to the sender image.
Thanks, Stu
Sensitivity rules can mark Outlook messages, but they can’t highlight external email in the way that Exchange transport rules can.
But… don’t you think it’s the worst user experience possible?
you’re messing with email’s content, maybe changing some in the way the email must be shown…
Let’s use a presentation email from a UI agency, a content from a lawyer etc et
And just think about the mobile client preview: the are receiving only the warning message: they are forced to open EVERY single message to just read the first two lines.
Is there user friendly way of handling this? I guess in 2020 there MUST be a feasable option.
Can be use a email tag to show some specific flag ???
It’s messy, but it’s OK in legal terms because you can show to a court the exact processing steps that are used to impose the marking. An expert witness would be easily about to convince a judge (I’ve acted as an expert witness in these kind of cases). The point is that organizations don’t have to do this, but when they do, it’s because they think it necessary to protect their company – ugly or not as the messages might be.
Let’s leave the legalese apart..
I understand the concern of the organization and their point of view, but still… no other way to do it? except for the “[External]” in the mail subject, I mean…
Is there really no other way? I mean some x-microsoft-header-warning: “External email: be carefoul with links” ? to enable some “flag” in the header view ??
Apart from transport rules, I don’t know of any other way to do this in a reliable, robust, and high-performance manner. Transport rules are built to process email, so you have a choice of including the disclaimer or updating the message subject. I don’t think you can expose an x-header.
There exists a tool named TagExternal that does not change the subject line and body to mark a message but assigns a special category to a message.
See https://www.ivasoft.com/tagexternal.shtml
For incoming email, how do you extract the sender’s email so that it can be included in the prepended HTML. I’m looking for something similar to AD properties, eg %%disayname%%, that you might append to outbound messages.
Thanks
Praful
I don’t believe this is supported. The properties that can be added come from Azure AD and an inbound sender is not one of the supported set.
Thanks for replying. A friend said he’d seen this done before but didn’t know how.
Understandably, an external sender is not going to be an AD property (which is about internal users) 🙂
However are AD properties the only ones you can add to inbound messages? What about in PowerShell?
Thanks again
PowerShell is just another way of configuring transport rules. It can’t apply magic to extend transport rules over and above what the GUI can do.
Interestingly, the sender is one of the properties that is available in the GUI (to use in conditions). It just doesn’t seem to be exposed for amending the message in the GUI. So the sender is available. Are you sure it’s not exposed to PowerShell?
In my experience, scripting languages do more than GUIs because they can have access to the underlying API, which GUIs do but don’t necessarily expose everything.
For example, in PowerShell you could get the current date/time or other properties of the environment and presumably include them in a message? If you’re a developer, my mental model was an observer in PowerShell (or C#) as messages came in.
Or is the PowerShell functionality simply restricted to running cmdlets to add rules to the GUI?
Thanks
Praful
I have this same question, “how do you extract the sender’s email so that it can be included in the prepended HTML”. It is possible because I have seen it from a friend’s email. See the picture on this SE post: https://stackoverflow.com/questions/64811433/include-sender-address-in-disclaimer?noredirect=1#comment114666052_64811433
Someone has figured it out.
I’ve asked the Exchange developers. In the meantime, why don’t you ask your friend to see if they can get a copy of the transport rule which includes the information in the prepended text.
I asked the Exchange developers and the engineer in charge of mail flow rules says that he has never heard of using a sender’s display name and email address in a prepended disclaimer. If you can ask your friend how they accomplished this, I will be happy to take it up again with the devs.
the line ExceptIfSenderDomainIs : {bwwmediagroup.com, audi.ie, revenue.ie, dell.com…}
does this include subdomains? such as test.audi.ie
thus it is like a wild card *.audi.ie
I believe it includes subdomains.
@ Tony
It is not related to this topics though.
I want to colour code subject line(Stand Out) for all users if message is coming from Service desk with Service ALert. Is there any way?
Thank you in Advance
I don’t think you can add color codes to subjects with transport rules.
Is they any PS to add conditional formatting to all users?
Thank you
I meant Outlook conditional formatting
The only formatting that’s possible is a string that you prepend or append to the message body, which is what people do when they want to highlight external email. You can insert HTML-formatted text to prepend or append. I don’t think you can process subjects in the same way.
Believe I am doing in a wrong way. Getting below:
Failed to update the transport rule
Error:
Invalid Operation:
Cannot process argument transformation on parameter ‘PrependSubject’. Cannot convert value “This text is important!” to type “System.Nullable`1[Microsoft.Exchange.Data.SubjectPrefix]”. Error: “The value for this parameter is invalid. Please provide a valid input for this parameter.
Parameter name: Subject prefix”
I can’t debug what you’re doing. See https://learn.microsoft.com/en-us/powershell/module/exchange/new-transportrule?view=exchange-ps for directions on using the PowerSgell cmdlet or make the change using the Exchange admin center.