Remediate Risks with Microsoft Defender for Office 365

The email protection stack

Every inbound email to your M365 tenant passes through a series of protection layers before reaching the inbox. The order matters because it determines where a threat was caught, where it slipped through, and what remediation options remain after delivery.

The first two layers are Exchange Online Protection (EOP), included with every M365 subscription. Anti-spam filtering evaluates sender reputation, content patterns, and IP intelligence. Anti-malware scanning checks attachments against known signatures. These layers catch commodity threats: bulk spam, known malware families, emails from blocklisted senders. If EOP blocks an email, the DeliveryAction in EmailEvents reads "Blocked" and the email never reaches the mailbox.

The next three layers are Defender for Office 365 features. Anti-phishing uses machine learning and impersonation detection to identify emails where the sender pretends to be someone the recipient trusts. The detection evaluates display name similarity to protected users and domains, mailbox intelligence patterns (does this sender normally contact this recipient?), and behavioral signals. Safe Links rewrites URLs in email bodies and scans them at time of click, not only at delivery. A URL that was clean when the email arrived but became malicious two hours later is caught when the user clicks it. Safe Attachments detonates suspicious attachments in a sandbox VM before delivery, observing process execution, file system changes, and network connections.

After delivery, Zero-Hour Auto Purge (ZAP) provides a retroactive safety net. When threat intelligence reclassifies a previously-delivered email (a URL initially classified as clean is reclassified as phishing, or a new malware signature matches an attachment), ZAP automatically moves the email from the inbox to quarantine or the Junk folder. ZAP is the layer that catches threats that slipped through every previous filter because the intelligence to detect them did not yet exist.

Figure 1.4: Inbound email flows left to right through EOP, then Defender for Office 365 features, with ZAP acting retroactively after delivery. Each layer the email survives narrows your remediation options.

Threat Explorer: investigating email at scale

Threat Explorer operates as a search and remediation interface over the same EmailEvents data that Advanced Hunting queries. The difference is the interaction model: Threat Explorer gives you a visual interface with point-and-click filtering, email previews, and bulk remediation buttons. Advanced Hunting gives you raw KQL access with full join capability.

When investigating a phishing campaign, you start in Threat Explorer with the sender address or sender domain. The results show every email from that sender, with columns for recipient, subject, delivery action (Delivered, Blocked, Replaced), detection technology (URL detonation, file detonation, impersonation), and latest delivery location (Inbox, Junk, Quarantine, Deleted Items). The "Delivered" count is your remediation target, because those emails are currently in user mailboxes and may not yet have been acted on by ZAP. An email with DeliveryAction "Blocked" was stopped before reaching the user. An email with DeliveryAction "Delivered" reached the inbox and sits there until you remove it.

The URL clicks tab shows you which users clicked links in the email and what happened when they did. Each click records the original URL, the wrapped Safe Links URL, the click verdict (Allowed, Blocked, Pending verdict), and the timestamp. This is your scope assessment for user interaction: how many users moved from receiving the email to actively engaging with the phishing content. Users who clicked need the containment sequence from Section 1.2 applied to their accounts. Users who only received the email need the email removed but may not need account containment.

The campaign view groups related emails into a single campaign based on sender infrastructure, URL patterns, and attachment characteristics. A campaign that targeted 19 users with the same phishing template, varying subject lines, and the same credential-harvesting domain appears as one campaign in this view even though the individual emails have different subjects. Campaign views save time when scoping an attack because you see the full breadth without building the filter manually.

The email timeline for individual messages shows every action the system took on that email from arrival to current state. You can trace a single email through connection filtering, content filtering, Safe Attachments detonation, delivery to inbox, and subsequent ZAP action. When you need to explain to a user or to management why a phishing email reached the inbox, the email timeline is the evidence: it shows exactly which layer classified the email as clean and when the classification changed.

// Scope a phishing campaign and identify who clicked
let phishSender = "voicemail-alert@northgate-voicemail.com";
EmailEvents
| where Timestamp > ago(7d)
| where SenderFromAddress == phishSender
| join kind=leftouter (
    UrlClickEvents
    | where Timestamp > ago(7d)
) on NetworkMessageId
| summarize
    TotalEmails = dcount(NetworkMessageId),
    Delivered = dcountif(NetworkMessageId, DeliveryAction == "Delivered"),
    UsersClicked = dcount(AccountUpn1)

This query gives you the same scoping data as Threat Explorer's campaign view, but extends it by joining UrlClickEvents to count users who clicked. You can further extend with a join to IdentityLogonEvents to determine whether any clicker subsequently signed in from an unusual IP, linking the email investigation to the identity investigation in one query. Section 1.8 builds the full cross-product version.

Remediation actions

Once you've scoped the campaign, you need to remove the phishing emails from every mailbox that received them. Threat Explorer provides bulk remediation: select the emails from the results table (up to 200,000 per query) and choose a remediation action.

Soft delete moves emails to Deleted Items, then to Recoverable Items with 14-day retention. This is the default action for confirmed phishing. The emails leave the inbox immediately, but they are recoverable if the classification was wrong. Use soft delete first, verify the accuracy, then escalate to hard delete if needed.

Hard delete permanently removes emails after the retention period. Use this for confirmed malware or high-confidence phishing where recovery is not desired. If you hard-delete 200 emails and one was a false positive, that legitimate business email is unrecoverable.

Move to Junk sends emails to the Junk Email folder. Use this for lower-confidence classifications where the user should have the option to review.

Block sender adds the sender address or domain to the Tenant Allow/Block List, preventing future delivery. The block takes effect within minutes for new inbound email. Be careful with granularity: blocking a domain like outlook.com would block all email from that provider. Block the specific sender address or the attacker-controlled domain, not the legitimate domain the attacker is spoofing.

Every remediation creates an admin action alert and an investigation record in the Action Center. The record tracks what was remediated, who approved it, how many messages were affected, and the current status. This audit trail answers the inevitable question from leadership: what exactly did we do about the phishing campaign?

The two-step approval process applies to all remediation actions initiated from Threat Explorer. When you select emails and submit a remediation request, the system creates a pending action in the Action Center. A Security Administrator (which may be you, or a separate approver depending on your organization's RBAC configuration) reviews and approves. This two-step flow prevents accidental bulk deletion by requiring explicit confirmation before execution. The Action Center at security.microsoft.com under Actions & submissions shows all pending and completed actions across all investigation sources.

Automated Investigation and Response for email

When Defender for Office 365 Plan 2 detects a phishing campaign, Automated Investigation and Response (AIR) can trigger automatically. AIR runs organization-level investigations that go beyond the individual email that triggered the alert. It identifies all messages from the same campaign (matching sender, URL patterns, attachment hashes), checks which were delivered versus blocked, identifies which users clicked the malicious URL, and recommends remediation actions.

AIR triggers on specific alert types: phishing emails that were delivered, ZAP actions on previously delivered emails, user-reported suspicious messages through the Report Message add-in, and suspicious mailbox behavior such as forwarding rules to external addresses or delegate access grants to unknown accounts. Each trigger starts an investigation playbook that analyzes the threat organization-wide. The playbook checks for other emails from the same sender, emails containing the same URLs or attachment hashes, and related suspicious sign-in activity. The result is a comprehensive campaign scope rather than a single-mailbox investigation.

The key word is "recommends." AIR identifies the emails to remediate and proposes the action (soft delete, hard delete, block sender), but it does not execute until a Security Administrator approves. The approval interface shows each evidence entity with its proposed action and current status.

The approval step exists because AIR operates at organizational scale. A single approval can soft-delete hundreds of emails across dozens of mailboxes. If the campaign scoping was wrong and AIR included legitimate emails that share characteristics with the phishing campaign, the damage is significant. You review each entity, confirm the classification, and approve. AIR executes the remediation across all identified mailboxes simultaneously.

The investigation summary appears in the Investigations tab of the XDR incident, linking the email threat investigation to the broader incident context. When the same incident also includes identity alerts from the three users who clicked, you see both the email investigation results and the identity compromise evidence on a single incident page.

Plan 1 versus Plan 2: what changes

The investigation capabilities in this section require Defender for Office 365 Plan 2, included in M365 E5. Plan 1 (included in M365 Business Premium) provides protection: anti-phishing policies, Safe Links, Safe Attachments, and Real-time Detections. Real-time Detections is a subset of Threat Explorer that shows recent threats but does not include the All Email view, campaign views, or bulk remediation actions.

The practical difference: on Plan 1, you can see that a phishing email was blocked, but you cannot search across all mailboxes to scope a campaign. You cannot select and soft-delete emails from multiple mailboxes simultaneously. You cannot trigger AIR for organization-wide investigation. The protection layer works; the investigation and remediation layer is limited to individual mailbox operations through Exchange admin tools.

This distinction matters when advising on licensing decisions. The protection gap between Plan 1 and Plan 2 is smaller than the investigation gap. Plan 1 blocks most commodity phishing. Plan 2 lets you investigate and remediate the phishing that gets through, and in a targeted attack, the investigation capability is the more critical need.