The Alert policies in O365 are an often overlooked or underestimated security feature for indicators of compromise (IOC). They enable especially administrators for smaller tenants to supervise their environments on a critical level in terms of security events. As part of a multilevel defense the O365 Alerts add a lot value, as they are easy to setup and part of every O365 and therefore free of additional costs.

This is a multi part security series for O365 with the following articles:

Table of Contents

  1. Introduction
  2. Getting started
  3. Custom Alerts


I personally would describe O365 Alerts as the poor mans SIEM, because it follows the same principles and uses Microsoft Insights under the hood. This article will give you a good overview of the capabilities of the tool, but keep in mind that these features will be more advanced if you use E5, Threat intelligence or Advanced compliance subscriptions. They are obviously not nearly as good as a full-scale SIEM such as Azure Sentinel but are a good start into to the security operations and analytics topic, especially for admins in smaller environments with a limited budget.

Getting started

The feature is part of the O365 Security center and can be configured there as well. The basic concept is that you define special events or actions in your tenant and if they are triggered you (or a defined group) will get an alert via mail. As always with O365 administration you have two ways to setup these policies. It is possible to use the GUI/web-interface for the administration or go all-in with a Powershell security connection. To be honest I would recommend that you start with the GUI, as it will show all the possible alerts and conditions in a well formatted way. To setup and change alert policies you simply go to O365 Admin portal > Security > Alerts > Alert Policies. Here you can see all existing alert policies (enabled/disabled) for your tenant.
If you want to create several alert policies at once or feel more comfortable using the shell, use the SCC Powershell. Make sure you are connected to Security & Compliance Center settings via Powershell. You can find the instructions how set this up here.

You can list all alert policies of your tenant with a simple Powershell command:

Get-ProtectionAlert | Format-List Name,Category,Comment,NotifyUser

In case you aim to rollout all alert policies with Powershell, the complete list of commands and parameters of this cmdlet can be found in the official MSFT docs

Custom Alerts

You will probably see several alerts policies, even if you have never set them up manually. That’s because Microsoft has some default policies to alert you in case of major events in your environment, such as an automatic restriction of a user to send mails due to potentially compromising behavior.

However, the real fun begins when you add your own custom policies, tailored to the needs of your environment. After all you know best which data is confidential, or which user could do the most harm. When setting up these custom rules, there is three parameters you need to think about, the group or users that will be alerted (by mail), the severity and the category of the incident. I would recommend being light on the amount of people are alerted for two main reasons: First, you want somebody to be responsible for the alert and react to it accordingly. It does not help if ten people get a mail, but nobody does anything about it, because they believe someone else will take care of it. And second, keep in mind there will be a lot of type II errors (false positives), which can be the doom of every security system. If your security analysts and administrators get too many alert mails, they might eventually just ignore them…

Below I have pointed out my favorite triggers from different categories that I use and they have saved me several times already (No normal user will setup a mail forward rule at 10:45pm on a Thursday, trust me).


  • New domain being forwarded mails
  • Mail loop

Common user activities:

  • Granted Exchange admin permission
  • Granted mailbox permission
  • Created mail forward/redirect rule
  • Shared file externally
  • Detected malware in file

File sharing activities:

  • Denied access request
  • Added exempt user agent

Keep in mind that if you have to many alerts/false positives that you can always add another condition to your alert trigger. This is especially important if you want to secure users with sensible information or privileged access, such as accountants and CEOS. For example, if you have a trigger for “shared file externally” you can map this alert only to files from the financial department.

Afterall I believe that these O365 Alerts are a powerful and often overlooked feature, which definitely deserve a place in every IT security strategy, especially with a small budget. The potential queries offered by Microsoft are good insights into unusual behavior of the O365 user environment, even if you have no deep knowledge regarding cyber security.