Why email notifications matter
A reminder first: this course is independent of Microsoft and isn't endorsed by it. Microsoft's SC-200 study guide is free on Microsoft Learn. This lesson doesn't reproduce it. Check Microsoft's exam page for length, price and languages, and treat this as preparation, not a promise that you'll pass.
The incident queue in the Microsoft Defender portal only helps if someone is looking at it. At 3 a.m., or when the queue is full of low-severity noise, an important incident can wait for hours. Email notifications send the incident to someone's inbox. Think of them as a smoke alarm: the queue is the building, and the email is what wakes you up.
The study guide names three kinds: incidents, actions and threat analytics. All three are set up in one place:
Defender portal (security.microsoft.com)
└─ Settings
└─ Microsoft Defender XDR
└─ General ▸ Email notifications
├─ Incidents tab → new or updated incidents
├─ Actions tab → manual or automated response actions
└─ Threat analytics tab → new or updated threat analytics reports
Permissions gotcha: to configure notifications you need the Manage security settings permission. With basic permissions management, that means Security Administrator or higher. With RBAC, you can only create, edit, delete and receive notifications for device groups you're allowed to manage.
Walkthrough 1: an incident notification rule
Scenario: the server team wants an email for High-severity incidents that affect the Prod-Servers device group, and nothing else.
Incidents tab ▸ Add incident notification rule
1. Basics
Name: Prod servers high sev
Description: Pages server on-call for High incidents only
2. Notification settings
Alert severity: [x] High [ ] Medium [ ] Low [ ] Informational
Device group scope: Selected device groups → Prod-Servers
[x] Send only one notification per incident # stops repeat emails as alerts are added
[x] Include organization name in the email # useful if staff cover several tenants
[x] Include tenant-specific portal link # the link opens the right tenant
3. Recipients
server-oncall@contoso.com → Add
soc-lead@contoso.com → Add
▸ Send test email # always do this; spam filters do eat these
4. Review rule ▸ Create rule
You can also filter on service source (for example, only Defender for Endpoint) and on specific detection sources (for example, EDR). You can even set a severity per source: Medium and High for EDR, but every severity for Microsoft Defender Experts. The email includes the incident name, severity and categories, plus a link to the incident itself.
Two details from experience:
- New recipients are only notified about incidents after they're added. Adding someone doesn't send them a backlog.
- Deleting a rule is permanent. If you're unsure, edit the rule instead (Edit rule on the rule pane).
Walkthrough 2: action notifications
Incident emails say that something bad happened. Action emails say that something was done about it. Response actions come from two places:
- Manual: an analyst isolates a device or quarantines a file.
- Automated: automatic attack disruption or automated investigation and response takes the action.
Scenario: the CISO wants to know whenever Defender isolates a device on its own, and especially when that fails.
Actions tab ▸ Add notification rule
1. Basics Name/Description: letters, numbers and spaces only
2. Notification settings
Action source: [ ] Manual [x] Automated # you can tick both
Action: [x] Isolate device # the list depends on which Defender workloads you have
Device groups scope: All device groups # includes current AND future groups
Action status: [x] Completed [x] Failed # a failed containment is the scary one
3. Recipients ciso@contoso.com, soc-lead@contoso.com → Add ▸ Send test email
4. Review rule ▸ Submit
Gotcha: response action email notifications don't currently support custom detections that contain response actions. If a custom detection isolates a machine, this rule won't email you about it.
Actions you can review in the Action center (pending and completed remediation) are the same actions this rule can tell people about.
Walkthrough 3: threat analytics notifications
Threat analytics reports are Microsoft's write-ups of active threats and campaigns. Your threat intelligence or vulnerability team wants to hear when reports are published or updated. These emails aren't about incidents in your tenant.
Threat analytics tab ▸ + Create a notification rule
1. Name (required), Description (optional), toggle rule on/off
Name: RansomwareReports # English letters and numbers only; no spaces, dashes or underscores
2. Choose reports: all new/updated reports, OR only a certain type, OR a specific tag (e.g. Ransomware)
3. Recipients: at least one ▸ Send test email
4. Review ▸ Create rule ▸ Done
Notice the naming rules differ between tabs. The Actions tab allows spaces in names. The Threat analytics tab doesn't.
Choosing the right type, and the noise trade-off
| Need | Use |
|---|---|
| "Tell on-call when a serious incident hits our estate" | Incidents |
| "Tell me when Defender (or an analyst) isolated, blocked or quarantined something, or failed to" | Actions |
| "Tell the threat intelligence team when Microsoft publishes or updates a report on ransomware" | Threat analytics |
The hard part is tuning. Email every Low and Informational incident to a team list and within a week people add an Outlook rule that files them away. That's alert fatigue, and it's how the one real High gets missed. Filter too tightly, say High only for one device group, and a Medium incident that's really the early stage of an attack never reaches anyone. That's a missed escalation.
A practical pattern is to use several narrow rules rather than one broad one:
- High (and Medium for EDR) goes to the on-call distribution list, with one notification per incident.
- Everything else stays in the queue, where analysts triage it during the shift.
- Failed automated actions go to the SOC lead.
Notifications are a paging layer, not a replacement for working the queue. Fine-tuning which alerts fire in the first place is a separate topic, coming soon.
What the exam asks about this
Expect short scenarios like "who should be notified, about what, and where do you configure it?" Know:
- the path: Settings ▸ Microsoft Defender XDR ▸ Email notifications
- which tab matches which need
- the filters for incident rules: severity, device group scope, service and detection source
- what Action source and Action status mean
- the Manage security settings and RBAC device-group limits
Distractors often name the wrong tab, or put a filter on the wrong rule type, for example a device group filter on threat analytics.
Key takeaways
- All three notification types live under Settings ▸ Microsoft Defender XDR ▸ Email notifications, each on its own tab: Incidents, Actions, Threat analytics.
- Incident rules filter by alert severity, device group scope, service and detection source, and can send only one notification per incident.
- Action rules filter by action source (manual/automated), action, device groups and status (completed/failed). They don't cover custom detections that contain response actions.
- Threat analytics rules track new or updated reports, filtered by type or tag.
- You need Manage security settings. With RBAC, you're limited to the device groups you manage.
- Use several narrow rules to balance alert fatigue against missed escalation, and always send a test email.