Anti-phishing
The purpose of this policy to provide phishing protection for impersonation, spoofing, and DMARC failures. Actions, such as quarantining items that match these detection methods are configured here. General phishing actions based on message content is actually configured in the anti-spam policy.
Quickconfig
Quick configs provide a list of settings, Microsoft's recommendation, my typical recommendation, links to Microsoft's documentation, and my documentation. These are provided for convenience and educational purposes, consider your scenario and testing before using these in your environment.
Considerations before deployment
- Are your users used to working with Quarantine items
- If not it would be a good idea to communicate quarantine to avoid overloading the support desk with calls
- How much bandwidth do you have for releasing messages from quarantine
- This will determine what action and quarantine policy you might deploy, for example you might make spoofing admin only release while allowing users to release user impersonation messages
Policy Configuration
Depending on the size of your organization it is usually best to create a new custom policy with the highest precedence that you scope to a smaller subset of users such as IT for testing.
The end goal would be removing that policy and having all users protected by the default policy. Only break off custom policies for the few users that have a valid exception. Another possible reason is if you are a very large organization you may have different policies for different sets of user impersonation protections since there is a limit of 350 per policy.
Scoping users, groups, and domains
Pay attention to the conditions on custom policies, they are evaluated together because of the AND statements. If you put a user and a group, the user must be a member of the group and anyone else who is a member of that group will not be included in this policy unless they are listed on the user list.
Phishing threshold
Phishing threshold can be set to a value of 1 to 4, 1 being the least aggressive and 4 being the most aggressive. Microsoft categorizes incoming email with a phishing confidence level based on machine learning, these categories are low, medium, high, or very high confidence. When the phishing threshold value is set at 1 only very high confidence email is treated as high confidence.
As you increase the threshold the next tier of confidence then becomes considered high confidence phishing. So at a phishing threshold of 2, Microsoft treats high and very high confidence phishing as high confidence phishing.
Warning
The below graphs are provided for illustrative purposes to help visually understand phishing threshold. This is a mix of Microsoft documentation and my practical experience. Some assumptions I am making:
- Microsoft has some phishing confidence level of none
- At strict settings Microsoft recommends your phishing threshold be 4, this means low phishing confidence gets treated as very high confidence. If there wasn't a category below low then everything would be quarantined.
- For any email not funneling into our high confidence phishing based on our threshold, those are the emails being treated as just "phishing"
Please feel free to contact me if you have evidence or other considerations that may go against my logic.
To help illustrate, let's imagine an environment receiving 100 emails and those emails will be categorized by Microsoft as follows:
| Microsoft's confidence | Quantity |
|---|---|
| none | 50 |
| low | 20 |
| medium | 10 |
| high | 5 |
| very high | 10 |
Select the corresponding phishing threshold to see how the emails are handled
---
config:
themeCSS: ''
theme: base
themeVariables:
background: '#000000'
primaryColor: "#000000"
primaryTextColor: '#808080'
sankey:
linkColor: 'target'
---
sankey-beta
Phishing threshold 1,none,50
Phishing threshold 1,low,20
Phishing threshold 1,medium,15
Phishing threshold 1,high,5
Phishing threshold 1,very high,10
none,Treated as safe,50
low,Treated as phishing,20
medium,Treated as phishing,15
high,Treated as phishing,5
very high,Treated as high confidence,10---
config:
themeCSS: ''
theme: base
themeVariables:
background: '#000000'
primaryColor: "#000000"
primaryTextColor: '#808080'
sankey:
linkColor: 'target'
---
sankey-beta
Phishing threshold 2,none,50
Phishing threshold 2,low,20
Phishing threshold 2,medium,15
Phishing threshold 2,high,5
Phishing threshold 2,very high,10
none,Treated as safe,50
low,Treated as phishing,20
medium,Treated as phishing,15
high,Treated as high confidence,5
very high,Treated as high confidence,10---
config:
themeCSS: ''
theme: base
themeVariables:
background: '#000000'
primaryColor: "#000000"
primaryTextColor: '#808080'
sankey:
linkColor: 'target'
---
sankey-beta
Phishing threshold 3,none,50
Phishing threshold 3,low,20
Phishing threshold 3,medium,15
Phishing threshold 3,high,5
Phishing threshold 3,very high,10
none,Treated as safe,50
low,Treated as phishing,20
medium,Treated as high confidence,15
high,Treated as high confidence,5
very high,Treated as high confidence,10---
config:
themeCSS: ''
theme: base
themeVariables:
background: '#000000'
primaryColor: "#000000"
primaryTextColor: '#808080'
sankey:
linkColor: 'target'
---
sankey-beta
Phishing threshold 4,none,50
Phishing threshold 4,low,20
Phishing threshold 4,medium,15
Phishing threshold 4,high,5
Phishing threshold 4,very high,10
none,Treated as safe,50
low,Treated as high confidence,20
medium,Treated as high confidence,15
high,Treated as high confidence,5
very high,Treated as high confidence,10User impersonation
The emails and display names specified here will be protected from impersonation. Ideally you would specify your organization's leadership, board, executives, etc. The type of people whose name might incline your users to give away credentials, money, or sensitive data. You can also specify external addresses as well.
Warning
If the user has previously corresponded with the impersonated email address, they will no longer receive this protection.
This primarily works by looking at the display name of the email. It is common to see benign positives when someone emails themselves from their personal account. Alan Alda in Exchange likely has Alan Alda as their display name on their gmail account which would be flagged for impersonation. For users trying to email from their personal account, do not add that to your trusted sender list, have the user release the message and correspond with it to prevent further detection for impersonation.
Copy Impersonated Users Protections from one policy to another
Domain impersonation
Domain protection looks for things like the domain name being paired with a different top level domain. If your domain was contoso.com and someone emails from contoso.edu that would be an example of domain impersonation. This will also take into account homoglyphs such as ćóntoso.com.
Owned domains
This is a good protection to use, I have not come across a reason not to use this protection.
Custom domains
Specify other organizations you work with frequently here, especially any domain you may have financial transactions with that an attacker might try to exploit.
Trusted impersonated senders and domains
Specify exceptions to your impersonation protections for users and domains here. Avoid adding any entries into here for...
- Domains you do not completely trust or control
- Domains or senders you are trying to stop from being flagged as spoofing, phishing, or spam, this list only prevents impersonation detection
- This is done here
- Senders that are personal accounts of users belonging to your organization
- Have the user correspond with their personal email, this disables future user impersonation detection on that sender address
The only good use case for an entry in this list I have come across was a vendor sharing a name with an executive at an organization. For example, Jamie Farr is COO of your organization and as such in the user impersonation protection list. Your organization is working on a big ERP migration involving a vendor, one of their employees was also named Jamie Farr. Anyone the vendor Jamie emails will have the message quarantined for impersonation. Since this is a one sender email to many recipient emails, unlike our personal email problem, it would be recommended to add the vendor's email to the trusted list. It is also likely as the ERP project continues, Jamie will be emailing more and different teams making this trusted list perfect to solve this problem.
Tip
If you report a message flagged for impersonation as clean, Microsoft will determine if an allow is necessary and will add that to the trusted sender list! So it's often not necessary to edit this list yourself!
Mailbox intelligence
This is essentially machine learning/artificial intelligence protections. Microsoft documentation states this is primarily to detect users you frequently email and helps distinguish between legitimate emails and impersonation.
Mailbox intelligence for User impersonation
Since you are limited to 350 user impersonations, this feature helps protect the rest of your users from being impersonated. This feature works by looking at whom the recipient corresponds with frequently and checks for impersonation on those email addresses. There is a flowchart below to help explain this but if the impersonation is coming from someone they don't correspond with that will not be prevented.
In the example below Sara is our recipient mailbox.
The left box contains David, Sara frequently corresponds with David, therefore anyone attempting to impersonate David to Sara should be flagged by Mailbox Intelligence User Impersonation.
The right box contains Joan, another employee where Sara works. They do not frequently communicate with one another so if someone attempts to impersonate Joan this is unlikely to be flagged by Mailbox Intelligence User protection.
flowchart LR
hidden1:::hidden
hidden2:::hidden
d[fa:fa-user David]:::user
s[fa:fa-user Sara]
fd[fa:fa-user-secret Fake David]:::adversary
j[fa:fa-user Joan]:::user
fj[fa:fa-user-secret Fake Joan]:::adversary
classDef adversary stroke:#f00
classDef user stroke:#0f0
classDef hidden display: none;
%% https://github.com/mermaid-js/mermaid/issues/3806
subgraph Sara corresponds with David frequently
hidden1
d
fd
end
subgraph Sara never communicates with Joan
hidden2
j
fj
end
d <--> s
s ~~~ j
s o--o|allowed| fj
fd -.-x|blocked| sWhile this may seem counterintuitive Fake Joan can impersonate Joan, Sara should be cautious of receiving an email from someone she is not expecting an email from. To help with that, the first contact safety tip would be in effect for the Fake Joan email, additionally it would be a good idea to have a banner notifying users the email is actually external. If Sara recognizes Joan's name and because of Joan's position she would be inclined to take action on the email, consider adding Joan to the User Impersonation list.
Spoof intelligence
If you are unfamiliar with the concept of spoofing, essentially It's where an email says it is being sent from contoso.com, but actually it didn't originate from contoso.com's email servers. As such it will not have the correct authentication headers. I am unaware of any good reason to disable this setting, you can use enhanced filtering to prevent spoofing issues if you're using a third party email tool and your MX record isn't pointing to M365.
When it comes to dealing with exceptions to spoofing, I try to only entertain allowing spoofing for domains and sending infrastructures I own. If its another organization, vendor, etc. I can't say for sure their systems are secure, so it's best to avoid allowing spoofing from those domains. With that being said you can handle this within the tenant allow/block list. For those domains and services we do control, I always try to get email authentication properly configured so spoofing isn't a problem before adding them to the tenant allow list.
Actions
Actions contains what action you would like to take based on the configuration of the policy discussed above. It also contains safety tips which are banners at the top of the message your users receive in their inbox.
If a message is detected as user impersonation
Microsoft recommends quarantining the message with the quarantine policy set to DefaultFullAccessWithNotificationPolicy or similar. This is a good recommendation as it allows the user to release a message potentially from their personal email without IT admin intervention. However, if you have the bandwidth you can certainly set this so the user has to request the message be released from quarantine.
If a message is detected as domain impersonation
Microsoft recommends quarantining the message with the quarantine policy set to DefaultFullAccessWithNotificationPolicy or similar. This is usually a rarer detection and as such it may be smarter to not allow users to release these.
If Mailbox intelligence detects an impersonated user
On the less restrictive side, Microsoft recommends sending this to junk, on the stricter side they recommend this go to quarantine with DefaultFullAccessWithNotificationPolicy. Both options are fine, one potential positive to sending it to quarantine is reducing the number of places users have to go to receive email. Email generally goes into the Inbox or focused inbox, moving some to junk and some to quarantine can be confusing or tedious to users.
Honor DMARC record policy when the message is detected as spoof
DMARC is an important part of email authentication. If my domain is contoso.com, and I have SPF and DKIM configured for my domain, the DMARC policy says, if the SPF and DKIM on an email you are receiving from my contoso.com domain is not passing I want you to reject or quarantine that email (this can also be set to none!). This is an excellent way to let users know all the email my users send should be authenticated appropriately, please take this action when it's not. This is also important for anyone planning on sending lots of emails to other domains, here is Google's requirement for DMARC policies.
It is common for users to get confused thinking this has something to do with their domain's DMARC policy. This setting only applies to incoming email to your domain, outgoing email and your domain's DMARC policies are not relevant when configuring this setting. Microsoft recommends this be enabled. This setting must be enabled to use the next to anti-phishing actions.
If the message is detected as spoof and DMARC Policy is set as p=quarantine
Microsoft recommends quarantining the email.
If the message is detected as spoof and DMARC Policy is set as p=reject
Microsoft recommends rejecting the email. Counterarguments I have seen for this is it will send a rejection notice letting the sender, perhaps an attacker, known they can't get in your domain without authenticated emails. It also seems to be much harder to track down an email that was rejected, if everything is quarantined but perhaps set to AdminOnlyAccess quarantine policy, your users can't get to the messages, but you can see easily what's being blocked. Even with a message trace it is hard to find emails that were flat out rejected.
If the message is detected as spoof by spoof intelligence
On the less restrictive side, Microsoft recommends sending this to junk, on the stricter side they recommend this go to quarantine with DefaultFullAccessWithNotificationPolicy. Both options are fine, one potential positive to sending it to quarantine is reducing the number of places users have to go to receive email. Email generally goes into the Inbox or focused inbox, moving some to junk and some to quarantine can be confusing or tedious to users.
First contact safety tip
Microsoft recommends this, the message displayed will be either this:
You don't often get email from
<email address>.
or:
Some people who received this message don't often get email from
.
Tip
I am not sure how this handled for brand new mailboxes but if you are doing a migration you may want to consider disabling this for a month so not every email coming in is being marked as a "first contact" since the service doesn't have understanding of normal contacts post migration.
User impersonation safety tip
Microsoft recommends this be enabled. The messaged displayed will be this:
This sender appears similar to someone who previously sent you email, but may not be that person.
Domain impersonation safety tip
Microsoft recommends this be enabled. The message displayed will be this:
This sender might be impersonating a domain that's associated with your organization.
Unusual characters safety tip
Microsoft recommends this be enabled, and it pertains to impersonated users, not every email received. The message displayed will be this:
The email address
includes unexpected letters or numbers. We recommend you don't interact with this message.
Unauthenticated senders symbol (?) for spoof
This changes the profile logo of the sender in Outlook to a question mark to possibly help clue in a message may not be trustworthy to your end users.
Show "via" tag
This is related to spoofing, perhaps I authenticated via a Gmail domain, but I am attempting to send email as a different domain or my DKIM is not matching. Microsoft's example for this is:
chris@contoso.com via fabrikam.com
Other notes
Brand impersonation
You will sometimes see brand impersonation, this does not have a configurable location, and I am not entirely sure which policy it follows, my assumption would be the phishing within the inbound anti-spam policy. Documentation on it is vague beyond the category added to the email header to distinguish it.