Microsoft Defender for Office 365 Threat Explorer and Email Investigation – SC-200 Study Guide

Purpose of This Lesson

Microsoft Defender for Office 365 provides security analysts with tools for investigating suspicious email, phishing attempts, malicious attachments, unsafe links, and coordinated email campaigns.

A central investigation tool is Explorer, commonly called Threat Explorer. It allows analysts to search email activity, examine delivery outcomes, inspect senders and recipients, review authentication results, investigate URLs and attachments, and initiate remediation actions.

For the SC-200 exam, you should understand how to:

• Locate and analyze suspicious email activity.
• Distinguish between delivered, blocked, dropped, and removed messages.
• Investigate an email as a security entity.
• Review message headers and email authentication results.
• Identify targeted users, malicious URLs, attachments, and campaigns.
• Remove harmful messages from mailboxes.
• Start automated investigations or propose remediation actions.
• Determine whether an email represents malware, phishing, spam, spoofing, or a benign operational issue.

This topic supports the Security Operations Analyst responsibilities of detection, triage, investigation, containment, remediation, and documentation.

---

Key Concepts

Microsoft Defender for Office 365

Microsoft Defender for Office 365 protects Microsoft 365 email and collaboration workloads against threats such as:

• Phishing
• Business email compromise
• Malicious attachments
• Malicious URLs
• Spam
• Impersonation
• Spoofing
• Coordinated email campaigns

It extends the protection available through Exchange Online Protection by providing more advanced investigation, detection, response, and threat intelligence capabilities.

Defender for Office 365 primarily focuses on:

• Exchange Online email
• Microsoft Teams
• SharePoint Online
• OneDrive for Business
• Microsoft 365 collaboration activity

For email-related incidents, Defender for Office 365 is normally the Microsoft security product most directly associated with the investigation.

---

Accessing Explorer

Explorer is available from the Microsoft Defender portal under the email and collaboration security tools.

The general workflow is:

1. Open the Microsoft Defender portal.
2. Locate the Email & collaboration section.
3. Open Explorer.
4. Select the appropriate investigation view.
5. Filter the results by date, recipient, sender, subject, threat type, delivery status, URL, or other available properties.

Microsoft has historically referred to this feature as Threat Explorer. Portal labels and navigation paths may change, but the underlying purpose remains the same: searching and investigating email threats.

Explorer availability and capabilities can depend on the organization’s Microsoft Defender for Office 365 licensing.

---

Explorer Investigation Views

Explorer provides multiple views that help analysts focus on different types of email activity.

All Email

The all-email view provides a broad view of messages processed by the tenant.

Analysts can use it to investigate:

• Delivered messages
• Blocked messages
• Quarantined messages
• Failed or dropped messages
• Messages removed after delivery
• Operational Microsoft 365 notifications
• Suspicious messages that were not initially classified as threats

This view is useful when the analyst already knows information such as:

• Sender address
• Recipient address
• Subject
• Approximate delivery time
• Sender IP address
• Message ID

A message does not need to be classified as malware or phishing before an analyst can investigate it.

Malware

The malware view focuses on messages containing files, payloads, or content identified as malicious.

An analyst may review:

• Malware family
• Attachment name
• File hash
• Recipient
• Delivery action
• Detection technology
• Post-delivery action

A lack of results does not prove that the tenant has never received malware. It only means that no matching malware events were found within the selected filters and time range.

Phishing

The phishing view displays messages classified as phishing or related deceptive activity.

Possible indicators include:

• Credential-harvesting links
• Impersonated senders
• Look-alike domains
• Spoofed sender addresses
• Suspicious reply-to addresses
• Failed authentication checks
• Social engineering language
• Malicious URLs

Campaigns

A campaign represents a coordinated group of related malicious messages or attacks.

Microsoft may associate messages into a campaign based on common characteristics such as:

• Sender infrastructure
• URLs
• Attachments
• Payloads
• Subjects
• Templates
• Targeted users
• Delivery patterns

Campaign analysis is more useful than examining individual messages when many users receive similar malicious content.

Content Malware

Content-related views can help identify malware associated with files or collaborative content, depending on the Defender capabilities and workloads available in the tenant.

The exact portal labels may vary, but the analyst’s goal is to determine whether malicious content entered or moved through Microsoft 365.

---

Filtering and Reviewing Email Activity

Explorer becomes more useful when analysts narrow the search.

Common filters include:

• Date and time
• Sender
• Sender domain
• Sender IP address
• Recipient
• Subject
• Direction
• Delivery action
• Delivery location
• Threat type
• Detection technology
• URL
• Attachment
• Message ID

Why Filtering Matters

A large tenant may process thousands or millions of messages. Searching all email without applying filters can produce excessive noise.

A practical investigation may begin with:

1. Limit the search to the suspected time window.
2. Search for the affected recipient.
3. Filter by sender, subject, URL, or attachment.
4. Review the delivery action.
5. Expand the search to additional recipients.
6. Determine whether the message was part of a larger campaign.

This progression helps establish both the initial event and the broader scope.

---

Understanding Delivery Status

An analyst must distinguish between the message’s original delivery action and its current location.

Original Delivery Location

This identifies what happened when Microsoft 365 initially processed the message.

Examples may include:

• Inbox
• Junk folder
• Quarantine
• Blocked
• Dropped
• Failed

Latest Delivery Location

This identifies the message’s most recent known location.

For example, a message may have been:

1. Initially delivered to the inbox.
2. Later identified as malicious.
3. Removed through automated protection or analyst remediation.

The original delivery location might therefore be Inbox, while the latest delivery location might reflect removal, quarantine, or deletion.

Delivered

The message reached a mailbox or mailbox folder.

Delivered does not automatically mean safe. A message may be delivered before later analysis identifies it as malicious.

Blocked or Dropped

The message was prevented from reaching the intended mailbox.

The analyst should still determine why it was blocked. Possible causes include:

• Anti-spam policy
• Anti-phishing policy
• Spoof protection
• Malware detection
• Transport rule
• Invalid recipient
• Sender reputation
• Authentication failure
• Tenant allow/block configuration

Do not assume that every dropped message contained malware.

Quarantined

The message was isolated rather than delivered normally.

Depending on the policy and permissions, an administrator, security analyst, or end user may be able to review or release it.

---

Investigating an Email Entity

Selecting Open email entity provides a more detailed view of a specific message.

The email entity page may include:

• Sender
• Recipient
• Subject
• Sender IP address
• Direction
• Delivery action
• Delivery location
• Detection verdict
• Threat type
• Authentication results
• URLs
• Attachments
• Timeline
• Related alerts
• Investigation information
• Remediation status

The email entity page helps bring multiple pieces of evidence into one investigation view.

---

Using the Email Timeline

The timeline records important events associated with the message.

Depending on the message and available telemetry, the timeline may show:

• Message receipt
• Initial delivery
• Detection
• Blocking
• Quarantine
• Post-delivery remediation
• Automated investigation activity
• Analyst remediation
• Final delivery location

The timeline is important because email verdicts can change after delivery.

For example:

1. An email is initially delivered.
2. Microsoft later identifies the URL as malicious.
3. The message is removed through post-delivery protection.
4. An alert or incident is generated.

The analyst should review the complete timeline rather than relying only on the original delivery action.

---

Reviewing Senders, Recipients, and Targeted Users

Explorer can identify users who received or interacted with suspicious messages.

Analysts should determine:

• Which users received the message?
• Was the message delivered or blocked?
• Did any users click a URL?
• Did any users open an attachment?
• Were privileged users targeted?
• Was the message sent to a distribution group?
• Did the same sender target multiple users?
• Did similar messages arrive from other senders or IP addresses?

Targeting information helps determine severity.

A phishing message sent to one unused mailbox may present less immediate risk than a credential-harvesting message delivered to several administrators.

---

URL Click Investigation

Explorer can display information about URLs found in messages and user click activity.

Useful information may include:

• URL
• Number of clicks
• Users who clicked
• Time of click
• Click verdict
• Whether the click was allowed or blocked
• Whether Safe Links protection was applied

A URL appearing in an email does not prove that a user visited it. Analysts should distinguish between:

• URL present in the message
• URL rewritten or evaluated by Safe Links
• User clicked the URL
• Click was blocked
• User reached the destination
• User entered credentials or downloaded content

A click event should lead to additional investigation of the user, device, sign-in activity, and related alerts.

---

Email Authentication Results

Email investigation commonly includes three authentication technologies:

SPF

Sender Policy Framework checks whether the sending server is authorized to send mail for the domain used in the SMTP envelope.

SPF relies on DNS records published by the sending domain.

DKIM

DomainKeys Identified Mail uses a digital signature placed in the message header. The receiving service retrieves the sender’s public key from DNS and verifies that the signed portions of the message were not altered.

DKIM does more than simply determine whether a domain exists. It validates a cryptographic signature associated with the message.

DMARC

Domain-based Message Authentication, Reporting, and Conformance evaluates alignment between the visible sender domain and the domains authenticated through SPF or DKIM.

DMARC also allows domain owners to publish instructions describing how receivers should handle messages that fail authentication.

Important Limitation

Passing SPF, DKIM, or DMARC does not guarantee that an email is safe.

An attacker may:

• Use a legitimately registered domain.
• Compromise a legitimate sender.
• Configure valid authentication for a malicious domain.
• Send a harmful link from a properly authenticated service.

Authentication results are one part of the investigation, not the final verdict.

---

Message Header Analysis

Email headers contain routing, authentication, and processing information.

An analyst may copy the raw message headers into a message header analyzer to make the information easier to interpret.

Header analysis can reveal:

• Mail servers that handled the message
• Sending IP addresses
• Return-path address
• Reply-to address
• SPF results
• DKIM results
• DMARC results
• Anti-spam processing details
• Message IDs
• Timestamps
• Routing anomalies

Header analysis is especially useful when investigating:

• Spoofing
• Impersonation
• Suspicious forwarding
• Unexpected reply-to addresses
• Messages sent through unfamiliar infrastructure
• Differences between the visible sender and technical sender

Header Analysis Limitation

Headers alone may not prove that a message is malicious. They should be correlated with:

• Message content
• URLs
• Attachments
• User behavior
• Sender history
• Threat intelligence
• Related alerts
• Endpoint activity

---

Taking Action on Email

Explorer allows analysts to perform or initiate response actions.

Available options vary by licensing, role permissions, message status, and portal configuration.

Move to Junk

Moves the selected message to the user’s junk email folder.

This may be appropriate for unwanted mail that is not sufficiently dangerous to justify deletion.

Move to Inbox

Moves a message to the inbox.

This can be used when a legitimate message was incorrectly classified or moved.

Soft Delete

Soft deletion removes the message from the normal mailbox view while retaining the possibility of recovery through supported recovery mechanisms.

This is generally safer when:

• The verdict is not fully confirmed.
• Recovery may be required.
• The organization wants a reversible remediation action.

Hard Delete

Hard deletion is intended to permanently remove the selected message from normal mailbox recovery paths.

Because this action is more destructive, analysts should use it carefully and according to organizational procedures.

Report as Clean

Marks or submits the message as legitimate when it was incorrectly identified as malicious or unwanted.

This can help address false positives.

Report as Phishing, Junk, or Malware

These actions submit or classify the message according to the selected threat category.

The analyst should select the most accurate classification:

• Phishing: Deceptive attempt to obtain information, credentials, money, or access.
• Junk: Unwanted or unsolicited email without a confirmed malicious payload.
• Malware: Message contains or distributes malicious code or files.

---

Tenant-Level Sender and Domain Blocking

Explorer may allow an analyst to block:

• A specific sender
• A sender domain
• Other associated indicators

Tenant-level blocking has broader impact than removing one message.

Before blocking an entire domain, analysts should consider:

• Is the domain fully malicious?
• Could legitimate business email originate from it?
• Is the sender compromised rather than inherently malicious?
• Is the block temporary or permanent?
• Does the action require change approval?
• Is there an existing tenant allow/block entry?
• Could a broad block interrupt business operations?

Blocking a single malicious sender is usually narrower than blocking an entire domain, but attackers can easily rotate sender addresses. The correct action depends on scope and confidence.

---

Automated Investigation and Response

From an email investigation, analysts may be able to initiate an automated investigation.

Automated investigation and response can:

• Analyze the message.
• Examine related recipients.
• Investigate the sender.
• Inspect URLs and attachments.
• Correlate related evidence.
• Recommend remediation actions.
• Perform approved response actions, depending on configuration.

Automation can reduce response time, but analysts should still review:

• Investigation scope
• Evidence
• Pending actions
• Completed actions
• False-positive risk
• Tenant-wide impact

Automation is most effective when paired with clear approval policies and analyst oversight.

---

Proposing Remediation

A remediation action can be created or proposed for suspicious email.

The analyst may provide information such as:

• Remediation name
• Description
• Severity
• Affected messages
• Recommended action

A remediation request supports structured SOC operations by creating a documented response activity rather than relying on an undocumented manual change.

Depending on the environment, remediation may require approval before execution.

---

Investigating Related Entities

A suspicious email rarely exists in isolation. The analyst may need to investigate related entities.

Email or Message

Review:

• Subject
• Sender
• Delivery status
• URLs
• Attachments
• Authentication
• Detection verdict

Recipient

Review:

• Other messages received
• URL clicks
• Sign-in activity
• Mailbox rules
• Account risk
• Related incidents

Sender

Review:

• Other messages from the sender
• Sender domain
• Sending IP
• Reputation
• Authentication results
• Previous detections

URL

Review:

• Threat verdict
• Click activity
• Redirect chain
• Other messages containing the URL
• Devices that contacted the destination

Attachment

Review:

• Filename
• File type
• File hash
• Malware verdict
• Sandbox or detonation results
• Devices where the file appeared

Device

If a user clicked a link or opened a file, investigate the device through Microsoft Defender for Endpoint.

Identity

If credentials may have been entered or an account may have been compromised, review identity and sign-in activity through Microsoft Entra ID and the broader Defender investigation experience.

---

Threat Tracker and Trending Campaigns

Threat tracking tools focus on active, emerging, or relevant threats.

Depending on the tenant and available features, analysts may find information such as:

• Trending campaigns
• Tracked threats
• Threat summaries
• Affected users
• Related messages
• Recommended actions

Threat Tracker is useful when the analyst wants to understand broader threat activity rather than investigate only one message.

Explorer vs Threat Tracker

Tool	Primary Purpose
Explorer	Search and investigate specific email events, messages, senders, recipients, URLs, attachments, and delivery actions
Threat Tracker	Review tracked, emerging, or trending threats and campaigns that may affect the organization
Advanced Hunting	Run custom queries across supported Defender XDR telemetry
Incidents and alerts	Investigate correlated security detections across multiple Microsoft security products

---

Campaign Investigation

A campaign is a set of related attack activity grouped by Microsoft based on shared indicators or behavior.

When investigating a campaign, analysts should determine:

• Number of messages
• Number of recipients
• Delivery success rate
• Users who clicked
• Common sender infrastructure
• Common URLs
• Common attachments
• Whether privileged accounts were targeted
• Whether any endpoints or identities were compromised

Campaign-level investigation helps identify the full scope of an attack.

Deleting one message from one mailbox is not sufficient when the same campaign reached dozens of users.

---

Microsoft Security Operations Context

Example SOC Workflow

A practical email investigation may follow this sequence:

1. Validate the Detection

Confirm:

• What triggered the alert?
• Was the message classified as phishing, malware, spam, or suspicious?
• Was it delivered, blocked, or quarantined?
• Is the verdict supported by evidence?

2. Inspect the Email Entity

Review:

• Sender
• Recipient
• Subject
• Sender IP
• Authentication
• URLs
• Attachments
• Delivery timeline

3. Determine Scope

Search Explorer for:

• Other recipients
• Similar subjects
• Same sender
• Same sender domain
• Same sender IP
• Same URL
• Same attachment or hash

4. Review User Interaction

Determine whether users:

• Opened the message
• Clicked a URL
• Opened an attachment
• Entered credentials
• Reported the message
• Forwarded it to other users

5. Investigate Related Workloads

Use the appropriate tools:

• Defender for Endpoint for device activity
• Microsoft Entra ID for sign-ins and identity risk
• Defender for Identity for on-premises identity activity
• Defender for Cloud Apps for cloud application behavior
• Microsoft Sentinel for broader log correlation
• Defender XDR incidents for cross-product evidence

6. Contain the Threat

Possible actions include:

• Remove the email.
• Block the sender.
• Block the malicious domain or URL.
• Quarantine a file.
• Isolate an affected device.
• Disable or restrict a compromised account.
• Revoke sessions.
• Reset credentials.
• Escalate to identity, messaging, endpoint, or incident response teams.

7. Document the Investigation

Record:

• Initial alert
• Affected users
• Delivery status
• Click activity
• Evidence reviewed
• Search criteria
• Scope
• Remediation actions
• Escalations
• Final verdict

8. Improve Future Detection

After containment, consider:

• Updating anti-phishing policies
• Adjusting Safe Links or Safe Attachments policies
• Creating tenant block entries
• Tuning alert policies
• Developing hunting queries
• Creating Sentinel analytics rules
• Improving user reporting procedures

---

Alert Triage and Prioritization

An analyst should not prioritize an email solely because it was detected.

Severity should reflect factors such as:

• Message delivered versus blocked
• User clicked versus no interaction
• Malware executed versus attachment blocked
• Credentials entered versus link merely viewed
• Privileged user targeted
• Number of affected users
• Evidence of account compromise
• Evidence of endpoint compromise
• Active campaign
• Business impact

Example Priorities

Situation	Likely Priority
Spam blocked before delivery	Low
Phishing message quarantined with no clicks	Low to medium
Phishing delivered to several users	Medium to high
Privileged user clicked a credential-harvesting link	High
Malicious attachment executed on an endpoint	High or critical
Coordinated campaign affecting multiple departments	High

Severity should be based on actual organizational risk, not only the product-generated classification.

---

Exam-Relevant Takeaways

Remember the following for the SC-200 exam:

• Use Microsoft Defender for Office 365 to investigate email, phishing, malicious URLs, and malicious attachments.
• Use Explorer or Threat Explorer to search email activity and examine delivery outcomes.
• Open the email entity to review detailed message evidence and the event timeline.
• A delivered message can later be identified and removed as malicious.
• Original delivery location and latest delivery location may be different.
• A blocked message is not automatically malware.
• Review the actual detection reason, authentication results, policy action, and message evidence.
• Use URL click information to identify users who may require further investigation.
• Investigate the recipient, sender, URL, attachment, identity, and device as related entities.
• SPF, DKIM, and DMARC help evaluate sender authenticity but do not prove that content is safe.
• Use soft delete when a recoverable removal is preferred.
• Use hard delete cautiously because it is more destructive.
• Tenant-wide domain blocking can disrupt legitimate communications.
• Use automated investigation to analyze related evidence and accelerate response.
• Use campaign information when multiple related messages or users are involved.
• Use Advanced Hunting when a custom query is required across Defender telemetry.
• Use Microsoft Sentinel when broader correlation across connected data sources is required.

---

Tool / Feature Decision Guide

Scenario	Best Microsoft Security Tool or Feature	Why
Search for a message sent to a specific recipient	Explorer	Provides detailed email search and filtering
Determine whether an email was delivered, blocked, or removed	Explorer and email entity timeline	Shows original and latest delivery information
Investigate a phishing message	Defender for Office 365	Designed for email and collaboration threats
Find users who clicked a suspicious link	Explorer URL click data	Correlates URLs with user click activity
Examine raw email routing and authentication	Message header analysis	Organizes header, routing, SPF, DKIM, and DMARC information
Remove a harmful message from mailboxes	Explorer remediation action	Supports soft delete, hard delete, and other message actions
Analyze related messages and entities automatically	Automated investigation and response	Reduces manual investigation effort
Review a coordinated phishing operation	Campaign investigation	Groups related messages and attack indicators
Review trending or tracked email threats	Threat Tracker	Focuses on emerging and tracked campaigns
Search email telemetry with a custom query	Advanced Hunting	Supports custom KQL-based investigation
Investigate activity after a user opens a malicious attachment	Defender for Endpoint	Provides device process, file, and network evidence
Investigate suspicious account sign-ins after phishing	Microsoft Entra ID and Defender XDR	Provides identity and authentication evidence
Correlate email activity with firewall, identity, and cloud logs	Microsoft Sentinel	Correlates data from multiple connected sources
Investigate multiple correlated Defender alerts	Defender XDR incident	Combines alerts, evidence, and entities into an incident
Block one confirmed malicious sender	Tenant Allow/Block List or applicable email policy	Applies a narrow tenant-level control
Block a fully malicious domain	Tenant-level domain block	Prevents mail from the domain but has broader operational impact

---

KQL Notes

The lesson introduces Advanced Hunting but does not demonstrate a specific KQL query.

For the exam, understand that Advanced Hunting allows analysts to query supported Microsoft Defender XDR data directly.

Email-related hunting tables can include data concerning:

• Email events
• Attachments
• URLs
• Post-delivery actions
• User click activity

Simple Example: Find Email Sent to a Recipient

EmailEvents
| where RecipientEmailAddress == "user@contoso.com"
| where Timestamp > ago(7d)
| project Timestamp, SenderFromAddress, RecipientEmailAddress,
          Subject, DeliveryAction, DeliveryLocation
| order by Timestamp desc

This is an illustrative example rather than a query taken directly from the lesson.

Query Breakdown

• EmailEvents selects the email event table.
• where RecipientEmailAddress == limits results to one recipient.
• where Timestamp > ago(7d) limits the search to the previous seven days.
• project displays only the fields relevant to the investigation.
• order by Timestamp desc displays the newest events first.

Example: Find Other Recipients of a Suspicious Sender

EmailEvents
| where Timestamp > ago(7d)
| where SenderFromAddress =~ "suspicious@example.com"
| summarize MessageCount = count(),
            Recipients = dcount(RecipientEmailAddress)
            by SenderFromAddress, Subject

This query could help determine whether a suspicious sender targeted multiple users.

Important Operators

Operator	Purpose
where	Filters records
project	Selects which columns to display
order by	Sorts results
summarize	Aggregates records
count()	Counts matching events
dcount()	Estimates the number of distinct values
ago()	Defines a relative time window
=~	Performs a case-insensitive string comparison

Exam Perspective

You may not be required to memorize every Defender hunting table. You should understand:

• KQL is used for custom hunting and investigation.
• The correct table must contain the required telemetry.
• Time and entity filters reduce noise.
• project controls output columns.
• summarize identifies patterns and scope.
• Hunting queries search existing data; they do not automatically create incidents unless converted into or associated with a detection mechanism.

---

Common Exam Traps

Trap 1: Treating Every Blocked Email as Malware

An email can be blocked because of spam policy, spoofing, authentication, recipient problems, transport rules, or sender reputation.

Always inspect the detection reason.

Trap 2: Assuming Delivered Means Safe

A message may be delivered and later reclassified or removed.

Review both the original and latest delivery state.

Trap 3: Assuming DKIM Proves the Sender Is Trustworthy

DKIM validates a signature associated with the sending domain. A malicious domain can still configure valid DKIM.

Trap 4: Confusing Defender for Office 365 with Defender for Endpoint

Use Defender for Office 365 for the email itself. Use Defender for Endpoint when investigating what occurred on a device after the email was opened.

Trap 5: Confusing Explorer with Microsoft Sentinel

Explorer investigates Microsoft 365 email telemetry. Sentinel performs broader SIEM correlation across connected data sources.

Trap 6: Deleting One Message Without Determining Scope

Search for other recipients, URLs, attachments, subjects, and sender infrastructure before closing the incident.

Trap 7: Blocking an Entire Domain Too Quickly

A domain-wide block may interrupt legitimate communications. Use the narrowest effective containment action.

Trap 8: Selecting Hard Delete by Default

Hard deletion is more destructive. Soft delete may be safer when recovery or validation is still required.

Trap 9: Confusing an Alert with an Email Entity

An alert is a detection. The email entity is the message and its associated evidence. An incident may contain multiple alerts and entities.

Trap 10: Using Advanced Hunting When a Built-In Search Is Sufficient

Use Explorer for straightforward message investigation. Use Advanced Hunting when custom logic, aggregation, or cross-table analysis is necessary.

---

Real-World SOC Analyst Notes

Alert Fatigue

Email systems generate substantial volumes of spam, delivery failures, authentication warnings, and user-reported messages.

Analysts should avoid treating every blocked message as an incident. Prioritize based on:

• Delivery
• User interaction
• Privilege
• Scope
• Payload
• Evidence of compromise

False Positives

Legitimate email may be blocked because of:

• Misconfigured SPF
• Missing DKIM
• DMARC alignment problems
• New sender infrastructure
• Bulk-mail behavior
• Forwarding
• Transport rules
• Poor sender reputation

Before modifying tenant-wide policies, confirm that the message is truly legitimate.

Evidence Preservation

Before destructive remediation, preserve relevant evidence such as:

• Message ID
• Subject
• Sender
• Recipient
• Sender IP
• URLs
• Attachment hashes
• Headers
• Screenshots
• Detection details
• Timeline events

This information may be needed for escalation, legal review, threat hunting, or post-incident analysis.

Automation Safety

Automated investigation can significantly reduce response time, but automatic actions should be governed by:

• Role-based access
• Approval requirements
• Severity thresholds
• Change control
• Audit logging
• False-positive handling
• Recovery procedures

Tenant-Wide Impact

Actions such as blocking a domain or modifying anti-phishing policy can affect every user.

Broad controls should be coordinated with:

• Messaging administrators
• Security engineering
• Identity teams
• Help desk
• Business stakeholders
• Incident response leadership

Access Permissions

An analyst may need specific Defender or Microsoft 365 security roles to:

• Search all email
• View message content
• perform remediation
• Submit messages
• Start investigations
• Review campaigns
• Manage tenant-level blocks

A user being able to view Explorer does not necessarily mean that the user can perform every remediation action.

Data Retention

Search results depend on available telemetry and retention. If an event falls outside the retention period, Explorer or hunting queries may not return it.

Organizations with investigation or compliance requirements should understand their licensing and retention configuration.

Cost Considerations

Defender for Office 365 investigation data is not the same as Microsoft Sentinel log ingestion.

Sending Microsoft 365 or Defender data into Sentinel can provide broader correlation, but Sentinel costs may be affected by:

• Data volume
• Retention
• Analytics rules
• Workspace design
• Ingestion configuration

Use Defender’s native investigation tools when they satisfy the requirement, and use Sentinel when broader SIEM correlation provides additional value.

---

Quick Reference Summary

• Explorer is the primary Defender for Office 365 tool for searching email activity.
• Use filters to narrow results by sender, recipient, subject, time, URL, or delivery action.
• Open the email entity for detailed evidence and timeline information.
• Original and latest delivery locations may differ.
• Delivered email is not automatically safe.
• Blocked email is not automatically malware.
• Review SPF, DKIM, DMARC, headers, URLs, attachments, and related entities.
• Determine whether users clicked URLs or opened files.
• Search for all affected recipients before remediating.
• Use soft delete for a more recoverable removal.
• Use hard delete carefully.
• Investigate campaigns when multiple related messages are involved.
• Use automated investigation for related evidence and recommended response actions.
• Use Defender for Endpoint when email activity leads to device activity.
• Use Entra ID and Defender XDR when phishing may have compromised an identity.
• Use Sentinel for broader cross-source correlation.
• Use Advanced Hunting when custom KQL analysis is necessary.

---

Flashcards

Q: What is the primary purpose of Explorer in Microsoft Defender for Office 365?
A: To search, investigate, and remediate email threats and email delivery activity.

Q: What is another commonly used name for Explorer?
A: Threat Explorer.

Q: Does a delivered email automatically mean the message is safe?
A: No. A delivered message may later be identified and removed as malicious.

Q: What is the difference between original delivery location and latest delivery location?
A: Original delivery shows what happened when the message was first processed; latest delivery shows its most recent known location or status.

Q: What should an analyst investigate after discovering that a user clicked a phishing URL?
A: The user’s identity, sign-ins, device activity, related alerts, sessions, and other recipients of the message.

Q: Which product should be used to investigate endpoint activity caused by a malicious attachment?
A: Microsoft Defender for Endpoint.

Q: What does DKIM validate?
A: A cryptographic signature associated with the sending domain and the integrity of signed message content.

Q: Does passing SPF, DKIM, and DMARC guarantee that an email is safe?
A: No. Properly authenticated email can still contain malicious content.

Q: What is the primary benefit of soft deletion?
A: It removes the message while preserving greater recovery potential than hard deletion.

Q: When should an analyst use campaign investigation?
A: When multiple messages, recipients, URLs, attachments, or senders appear to be part of the same coordinated attack.

Q: When is Advanced Hunting preferable to Explorer?
A: When custom KQL logic, aggregation, or broader telemetry analysis is required.

Q: Why should an analyst avoid immediately blocking an entire sender domain?
A: The domain may also send legitimate business email, creating tenant-wide disruption.

Q: What does an automated investigation do?
A: It analyzes related messages, users, senders, URLs, attachments, and evidence and can recommend or perform remediation.

Q: Which Microsoft tool is best for correlating email activity with logs from firewalls and non-Microsoft systems?
A: Microsoft Sentinel.

Q: What is the first major question when triaging an email threat?
A: Whether the message was delivered and whether a user interacted with it.

---

Practice Questions

Question 1:

A security analyst receives an alert concerning a phishing message sent to several Microsoft 365 users. The analyst needs to determine which recipients received the message and whether it was delivered or blocked.

Which tool should the analyst use first?

A. Microsoft Defender for Endpoint device inventory
B. Microsoft Defender for Office 365 Explorer
C. Microsoft Sentinel workbook
D. Microsoft Entra ID sign-in logs

Correct Answer:
B. Microsoft Defender for Office 365 Explorer

Explanation:
Explorer is designed to search email activity and review recipients, delivery actions, URLs, attachments, and threat classifications. The other tools may become relevant later if the investigation identifies endpoint or identity compromise.

---

Question 2:

Explorer shows that a suspicious email was originally delivered to a user’s inbox but has a latest delivery location indicating that it was removed.

What is the most likely explanation?

A. The message could not be processed by Exchange Online.
B. The sender manually recalled the message.
C. The message was delivered and later removed through post-delivery protection or remediation.
D. The mailbox no longer exists.

Correct Answer:
C. The message was delivered and later removed through post-delivery protection or remediation.

Explanation:
The original delivery location records the initial action. The latest delivery location reflects the message’s current or most recent state. Microsoft protection or analyst remediation can remove a message after delivery.

---

Question 3:

An email passes SPF, DKIM, and DMARC but contains a credential-harvesting link.

Which conclusion should the analyst make?

A. The message is safe because all authentication checks passed.
B. The message cannot be phishing because DKIM passed.
C. Authentication passed, but the content and URL must still be investigated.
D. The message must have originated from Microsoft 365.

Correct Answer:
C. Authentication passed, but the content and URL must still be investigated.

Explanation:
Email authentication validates aspects of the sending domain and message handling. It does not prove that the sender or content is trustworthy.

---

Question 4:

A phishing email was delivered to a privileged administrator, and Safe Links data shows that the administrator clicked the URL.

What should the analyst do next?

A. Close the alert because Safe Links recorded the click.
B. Investigate the user’s sign-ins, identity risk, sessions, and device activity.
C. Delete only the original message and take no further action.
D. Disable email authentication for the sender domain.

Correct Answer:
B. Investigate the user’s sign-ins, identity risk, sessions, and device activity.

Explanation:
A clicked phishing URL may indicate credential theft, token theft, malware delivery, or other compromise. The analyst must investigate the related identity and endpoint and determine the full scope.

---

Question 5:

An analyst confirms that a malicious message was sent to 50 users. The analyst wants to remove the messages while preserving the greatest practical opportunity for recovery if the verdict is later overturned.

Which action is most appropriate?

A. Move to Inbox
B. Report as clean
C. Soft delete
D. Hard delete

Correct Answer:
C. Soft delete

Explanation:
Soft delete provides a less destructive remediation option. Hard delete is more permanent and should be used when the threat is confirmed and organizational procedures support permanent removal.