2.4.1. Email Notifications and Alert Tuning
💡 First Principle: Not every alert deserves a person's immediate attention, and not every recurring alert deserves to exist at all. Email notifications push the important events to the right people outside the portal; alert tuning removes known-benign noise before it reaches anyone. Both are filters on attention, applied in opposite directions.
Email notifications in Defender XDR are configured under Settings > Microsoft Defender XDR > Email notifications, with separate rule types for three kinds of event:
- Incidents: notify recipients when new incidents are created, filtered by severity, by alert source (the Defender product), and by device group, with an option to send only one notification per incident instead of one per new alert.
- Actions: notify recipients when response actions are taken, such as remediation actions from automated investigation or manual actions taken by analysts.
- Threat analytics: notify recipients when threat analytics reports are published or updated, optionally filtered to reports that affect your organization.
Defender for Endpoint also keeps its own alert email notification rules (Settings > Endpoints > General > Email notifications), scoped by device group and alert severity. Two scoping rules matter: with role-based access enabled, an admin can create rules only for device groups within their scope, and new recipients receive only notifications for alerts raised after they were added. Choosing a least-privileged role (such as Security Administrator rather than Global Administrator) to manage notification rules is the standard exam answer.
Alert tuning (formerly called alert suppression) lives under Settings > Microsoft Defender XDR > Alert tuning, and you can also start a rule directly from an alert's page. A tuning rule has three parts: service sources (which Defender products it applies to), conditions built from evidence such as files, processes, scheduled tasks, scripts, or IP addresses (combined with AND/OR), and an action:
| Action | Effect |
|---|---|
| Hide alert | Suppresses the alert so it doesn't appear in the queue or create an incident; it remains in the AlertInfo and AlertEvidence hunting tables (Defender for Endpoint alerts only) |
| Resolve alert | Automatically resolves matching alerts and their incidents |
| Set as behavior | Converts matching signals into behaviors that never reach the queue but stay available for hunting |
Microsoft also ships built-in tuning rules for common benign activity; if automated investigation later finds the activity malicious, the suppressed alert is reactivated. Tuning has limits: it doesn't apply to alerts from custom detection rules (tune those through their own query logic), and it should be reserved for well-understood activity such as an internal business application or a scheduled security test.
Correlation is what turns alerts into incidents (1.2.2), and it is mostly automatic in Defender XDR: alerts sharing entities, timing, and attack context are grouped into one incident. You influence it rather than configure it. Analysts can move alerts between incidents or link them when correlation missed a connection, and the Defender for Endpoint advanced feature Restrict correlation to within scoped device groups prevents alerts from different device groups merging, which matters when separate SOC teams own separate regions.
⚠️ Exam Trap: "Stop receiving alerts for a known, approved admin script on 50 servers while keeping visibility for threat hunting" is an alert tuning rule with narrow conditions (the specific script and devices), not disabling the detection and not an indicator allowing the file everywhere. Hidden alerts stay queryable in AlertInfo; a broad allow indicator would also stop blocking.
Reflection Question: Your team receives one email per alert and some incidents generate twenty. Which incident notification setting reduces that to one message, and why might the SOC manager still want a separate notification rule for response actions?
