How to turn on alert policies for compromised mailboxes

What this check looks at

Checks that Microsoft’s built-in alert policies for a compromised or abused mail account are switched on: suspicious sending, forwarding and connector activity, delayed mail and the tenant being restricted from sending.

Microsoft 365 includes built-in alert policies that raise an alert, and email chosen recipients, when Exchange Online sees signs of a compromised or abused account. This check covers the six CISA’s baseline requires: Suspicious email sending patterns detected, Suspicious connector activity, Suspicious Email Forwarding Activity, Messages have been delayed, Tenant restricted from sending unprovisioned email, and Tenant restricted from sending email, plus "A potentially malicious URL click was detected" where the tenant has it (Defender for Office 365 Plan 2). They are on by default, but can be switched off.

The check reads the alert policies from Purview and fails when any required policy is switched off or missing, naming them. It warns when a policy came back without whether it is on, and passes when all are on. It does not test who receives the alerts (CISA’s MS.DEFENDER.5.2v1 covers that), so check the recipients while you are there.

These are the alerts that fire when a compromised mailbox starts sending spam or phishing to your customers, when a forwarding rule starts sending mail outside, when an attacker adds a connector to relay mail through you, or when Microsoft restricts the whole tenant from sending. Switched off, or sent to a mailbox nobody reads, the first anyone hears is a customer asking about a strange invoice, or every user’s email bouncing.

Why it matters

These alerts are often the first sign that an account is sending spam or forwarding mail out. Switched off, the first anyone hears of it is a customer complaint or Microsoft blocking all outbound mail.

A typical case: a finance assistant’s account is phished on a Friday afternoon, and over the weekend the attacker sends thousands of invoice-fraud emails from it to the firm’s customers. With the suspicious sending alert going to the MSP, the password would have been reset within the hour. Instead, by Monday customers have paid fake invoices from a trusted address and the firm’s domain is on blocklists.

The costs land quickly: customers’ lost payments and the conversations about who bears them, mail delivery problems while the domain is cleaned up, and an incident investigation. The alert costs nothing to leave on.

CISA SCuBA MS.DEFENDER.5.1v1 asks that the alerts the baseline names are enabled. It supports ISO 27001 A.8.16 (monitoring activities), the NCSC Cyber Assessment Framework’s C1.c on generating alerts and PCI DSS 10.4.1 on reviewing security events.

How to fix it

Where: Microsoft Defender portal → Policies & rules → Alert policy

Before you start

• Choose the mailbox the alerts go to, and make sure someone acts on them (or forward them to the SIEM).

Step by step

1. 1Decide who receives the alerts. Choose a monitored address that someone acts on during working hours: the MSP’s alerts mailbox, a security@ shared mailbox, or the SIEM’s mail intake. By default built-in policies email the tenant’s global administrators, who often do not read them.
2. 2Open the alert policies. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Alert policy. Search for each policy named in the evidence.
3. 3Switch each required policy on. Select the policy and, in its details pane, set its status to On. Repeat for every required policy listed as switched off.
4. 4Send the alerts to your chosen address. In the same pane, select Edit policy, move to the recipients page, tick "Opt-in for email notifications", add the address, set the daily notification limit to no limit, and save. Do this for all the required policies, including those that were already on.
5. 5Look into any policy that is missing. If a required policy does not appear at all, check the tenant’s licences (the malicious URL click alert needs Defender for Office 365 Plan 2) and whether Microsoft has renamed it. Built-in policies cannot be recreated by hand; if one is missing with the right licence, raise it with Microsoft support.
6. 6Confirm the change. Connect to Security & Compliance PowerShell (Install-Module ExchangeOnlineManagement, then Connect-IPPSSession) as a Compliance Administrator. Run Get-ProtectionAlert | Where-Object Disabled | Select-Object Name: none of the policies from the evidence should be listed. Get-ProtectionAlert -Identity "Suspicious email sending patterns detected" | Select-Object Name, NotifyUser shows your address.

What users will notice

None for users. The alert recipients receive an email when one of these events happens.

How to confirm it worked

Get-ProtectionAlert | Where-Object Disabled | Select-Object Name lists none of the policies in the evidence.

Frameworks and controls

This check maps to controls in 15 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.

The framework mappings were last checked against the published standards in October 2026.

Microsoft’s documentation

• Alert policies in the Microsoft Defender portal (Microsoft Learn)

Related checks

• How to find inbox rules forwarding mail outside the company
• How to block sign-in to shared mailboxes
• How to find mail flow rules that skip spam filtering
• How to find apps users have allowed to read mail and files

The full Microsoft 365 security checklist, worst first