How to Set Up Email Bomb Alerts in Microsoft Defender

Email bomb attacks are not theoretical. In real intrusions, attackers sign up a target's corporate email address for dozens of mailing lists simultaneously, or use botnets to flood the inbox with messages. The goal is not to breach the mailbox directly. The goal is to bury any security signal in noise. By the time the victim finishes deleting several hundred subscription confirmations, a password reset or OAuth consent grant has already gone through unnoticed.

This is a documented attacker pattern. Security teams need to catch the flood before it overwhelms them.

Microsoft Defender for Microsoft 365 includes built-in detection for email floods, but it is not always configured to alert the security team in a way that makes the signal actionable. This guide explains what email bomb detection looks like in Defender, how to configure alerts, and what to do when one fires.

What an Email Bomb Attack Actually Looks Like

An email bomb is a volume-based denial-of-service attack against an inbox. Attackers use three main methods:

Mailing list sign-up bomb: Automated scripts subscribe the target address to dozens or hundreds of mailing lists at once. The victim receives a flood of welcome emails, confirmation messages, and digest notifications.
Botnet flood: Compromised devices send thousands of messages to the target address from different sources, making IP-based blocking ineffective.
Credential stuffing collateral: During a credential stuffing attack, the attacker triggers password reset emails and account notification floods as a distraction from the actual account changes.

The most dangerous version is the sign-up bomb during an active account takeover. An attacker compromises a user's credentials, changes the password, grants OAuth access to a malicious app, and then bombs the inbox to keep the victim blind to the activity. LAPSUS$ and similar groups have used this tactic documentedly.

How Microsoft Defender Detects Email Floods

Microsoft 365 Defender monitors inbound mail volume per mailbox using machine-learning baselines. When an unusual spike occurs, Defender can generate an alert under the Email flooding detection category.

What Defender looks for:

A sudden increase in inbound mail to a single mailbox, measured against the user's historical volume baseline

Messages from multiple new sending domains that the user has not received mail from before

A pattern consistent with subscription confirmation floods (high volume, low unique sender diversity)

Pair Defender alerts with DMARC report monitoring for the outbound half of the picture. If attackers are using your domain to subscribe the target to mailing lists, your DMARC reports will show authentication failures from sending IPs you do not recognize. DMARCFlow aggregates these failure reports and can flag anomalous spikes in DMARC rejections, giving your team an early warning that your domain may be part of an email bomb campaign before the inbox flood becomes overwhelming.

Where you will see this alert:

Microsoft Defender XDR > Incidents and alerts > Alert catalog

The detection name is typically "Email flooding" or "Unusual increase in email received"

Severity is usually set to Medium or High depending on your organization's alert tuning

The baseline learning takes time. A brand-new user mailbox will not trigger accurate flood alerts for the first few weeks. Established mailboxes with stable traffic patterns get the most reliable detection.

How to Configure Email Bomb Alerts in Microsoft Defender

Defender's built-in email flood detection is enabled by default, but the notification routing is not always set up for security team visibility. Here is how to make sure you actually see these alerts.

Step 1: Verify the built-in flood detection is active

In Microsoft Defender XDR (security.microsoft.com), go to:

Email and collaboration > Alert policies (or in the new unified portal: Settings > Email and collaboration > Alert policies)

Look for the "Email flooding" policy. It should be set to On. If it is not, enable it.

Step 2: Configure notification recipients for flood alerts

In the alert policy, set the notification recipients to the security operations team address, not the affected user's manager. The affected user should not be notified that their inbox is being monitored for floods during an active incident.

Step 3: Set alert severity and triggers

The default threshold for email flood detection is Defender's learned baseline. If your organization has seasonal mail patterns (newsletter launches, marketing campaigns), you may see false positives. Adjust the threshold in the alert policy to a higher sensitivity if you need more alerts, or use a custom threshold if your baseline is genuinely higher.

Step 4: Create a custom detection for tighter control (optional, requires Microsoft Sentinel)

If you need more control over the threshold and want cross mailbox correlation, use Microsoft Sentinel with a KQL query:

kql
EmailEvents
| where Timestamp > ago(1h)
| summarize MailCount = count(), UniqueSenders = dcount(SenderFromDomain)
  by RecipientMailbox
| where MailCount > 200 and UniqueSenders > 50
| order by MailCount desc

This catches mailboxes receiving more than 200 messages from more than 50 distinct domains within one hour. Adjust the thresholds to match your organization's normal volume.

Step 5: Route alerts to your SIEM or ticketing system

In Defender XDR, go to Settings > Microsoft Defender XDR > Streaming APIs to forward alerts to a SIEM. This ensures email flood alerts appear alongside your other security signals rather than siloed in the Defender portal.

What to Do When an Email Bomb Alert Fires

Getting the alert is only half the work. Here is how to respond correctly.

1. Check recent sign-in activity for the affected user

Go to Azure AD sign-in logs or Microsoft Purview audit logs and look for:

Password resets or force sign-outs (indicator of credential change)

New OAuth app consent grants (especially for mail.read, mail.send, Files.ReadWrite)

Changes to mailbox forwarding rules

Addition of new mailbox delegates

2. Determine whether the flood is intentional or benign

A genuine email bomb will show:

Hundreds of messages from previously unknown sending domains (subscription confirmations)

Similar message subject patterns (all "Welcome to [site]")

No replies or direct messages from known contacts

A benign volume spike will show:

Known senders (colleagues, clients)

Threaded conversations

Calendar invitations or Teams messages

3. Contain if you find an active account compromise

If the sign-in logs show an unauthorized password reset or OAuth consent, treat it as an active incident:

Revoke the suspicious OAuth app permissions immediately

Force sign-out for the affected account

Reset the password

Check for any rules created on the mailbox (mailbox forwarding to external addresses)

Notify the user

4. Dismiss with documentation if it is a false alarm

If the flood was caused by a legitimate event (user subscribed to a mailing list during a marketing push, a colleague mass-messaged the team), document the false positive and adjust your baseline thresholds if needed.

How to Reduce the Attack Surface

You cannot prevent attackers from targeting your users, but you can make the technique less effective.

Block external mailing list sign-ups at the DNS level

Configure your DNS to publish an SPF record that explicitly denies mail sending from your domain for third-party mailing services. This does not stop incoming mail but makes it harder for attackers to use your domain as the subscription confirmation target.

Use DMARC to monitor who is sending mail on your domain's behalf

DMARC report monitoring catches unauthorized sending sources quickly. If you see a sudden spike in DMARC failures from sending IPs you do not recognize, it may indicate an attacker is attempting to use your domain in the email bomb. DMARCFlow aggregates these reports and flags anomalies.

Set up external sender warnings in Outlook Web App

OWA can show a banner on messages from external senders. Users trained to notice these warnings are less likely to treat a flood of external "confirmation" emails as normal.

Limit OAuth app consent to admin-approved apps only

In Azure AD, set user consent settings to "Do not allow user consent" or "Allow user consent for apps from verified publishers." This prevents attackers from getting silent OAuth access during the distraction window.

Summary

Email bomb attacks work because they exploit the gap between mailbox volume and security attention. Microsoft Defender's built-in flood detection catches these patterns, but only if the alerts are configured to route to your security team and not buried in the Defender portal. Set up the Email flooding alert policy, route notifications to your SOC, and have a response playbook ready so that when the alert fires, you check for account takeover indicators before you dismiss it as noise.

Monitor your domain's sending reputation and authentication health with DMARCFlow to catch the outbound signals that email flood campaigns often leave behind.