Agent Foskett Academy • Lesson 72 • Email Investigation

Investigating ReportId in Microsoft Defender XDR.

A reported phishing email had created multiple Defender records.

The sender, subject and recipient evidence all mattered.

But Agent Foskett needed to connect related events without losing the investigation timeline.

The answer was hidden inside ReportId.

In Microsoft Defender XDR, ReportId helps defenders correlate related records, group investigation evidence and understand how email events fit together.

Agent Foskett Academy lesson explaining ReportId in Microsoft Defender XDR
Lesson overview

Learn how to investigate ReportId in EmailEvents and use it to correlate related Defender records, investigation evidence and email security timelines.

Review ReportId activity
Identify related Defender records
Connect events, senders and delivery outcomes
Support reliable investigation timelines

Why ReportId matters

ReportId helps defenders correlate related Microsoft Defender XDR records instead of treating each email event as an isolated line of evidence.
It supports event correlationReportId helps connect related Defender records that belong to the same investigation or message activity.
It strengthens timelinesReportId helps defenders line up related activity with timestamps, senders, recipients, delivery actions and threat classifications.
It reduces isolated analysisDefenders can avoid reviewing single rows in isolation by using ReportId with other identifiers and investigation fields.

The fields used in this lesson

ReportIdA Defender XDR report identifier used to help correlate related records and investigation evidence.
NetworkMessageIdA Microsoft 365 message identifier commonly used alongside ReportId for email, URL, click and attachment correlation.
SubjectThe email subject used to identify suspicious lures and possible campaign themes.
SenderFromAddressThe visible sender address shown to recipients.
RecipientEmailAddressThe mailbox that received the message.
DeliveryActionWhat Microsoft 365 did with the message during delivery.

Step 1 — Review ReportId activity

Start by reviewing recent email records where Defender recorded a ReportId.
review-reportid-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
EmailEvents
| where Timestamp > ago(30d)
| where isnotempty(ReportId)
| project Timestamp,
          ReportId,
          NetworkMessageId,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject
| order by Timestamp desc

Step 2 — Investigate a specific ReportId

Once the ReportId is known, pivot directly to related Defender records and supporting email evidence.
specific-reportid.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
EmailEvents
| where ReportId == <ReportId>
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          DeliveryAction,
          DeliveryLocation,
          ThreatTypes
| order by Timestamp desc

Step 3 — Find related records for the same ReportId

Use ReportId to review records that may belong to related email activity.
reportid-related-records.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
EmailEvents
| where ReportId == <ReportId>
| summarize RecipientCount = dcount(RecipientEmailAddress),
            MessageCount = count()
          by ReportId,
             Subject,
             SenderFromAddress

Step 4 — Pivot from a suspicious message to ReportId

Subjects and senders can help locate suspicious activity, but ReportId helps correlate related Defender records.
message-to-reportid-pivot.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
EmailEvents
| where Timestamp > ago(30d)
| where Subject contains "Invoice"
| project Timestamp,
          ReportId,
          NetworkMessageId,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject

Step 5 — Compare ReportId with delivery outcomes

This helps determine whether related records show delivered, quarantined, junked or blocked outcomes across recipients.
reportid-delivery-outcomes.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
EmailEvents
| where Timestamp > ago(30d)
| where isnotempty(ReportId)
| summarize MessageCount = count()
          by ReportId,
             DeliveryAction,
             DeliveryLocation,
             ThreatTypes
| order by MessageCount desc

Step 6 — Identify high-volume ReportId activity

High-volume ReportId activity can help reveal repeated or related records that deserve deeper investigation.
high-volume-reportid.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
EmailEvents
| where Timestamp > ago(30d)
| where isnotempty(ReportId)
| summarize RecipientCount = dcount(RecipientEmailAddress),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
          by ReportId,
             Subject
| order by RecipientCount desc

How to read the results

ReportId is correlation evidence. It should be reviewed with sender, recipient, subject, delivery and other Microsoft Defender message identifiers.
Related records need contextReportId helps group evidence, but defenders still need sender, recipient, subject, delivery and threat context.
Delivery can differ by recipientThe same message may have different delivery outcomes depending on policy, mailbox state, timing or post-delivery action.
Correlation needs more than one fieldUse ReportId with NetworkMessageId, InternetMessageId, recipient, subject and delivery fields to build a reliable timeline.

Common investigation uses

User-reported phishingConfirm whether multiple reports relate to the same email message or just similar phishing lures.
Mail flow investigationUse message identifiers to support deeper review in Exchange Online and Microsoft 365 mail tracking workflows.
Campaign scopingIdentify whether a message reached one mailbox, many users or repeated groups across the organisation.
Evidence correlationConnect message identity with delivery, threat classification, sender identity and recipient exposure.

Common mistakes

Treating ReportId as the only answerReportId helps correlate evidence, but it should still be validated with NetworkMessageId, InternetMessageId and delivery fields.
Using one identifier onlyReportId is useful, but Defender investigations often require NetworkMessageId, InternetMessageId and other fields as well.
Ignoring delivery and recipient contextKnowing the message identifier is only the start. Check who received it, where it went and what action Microsoft took.

What you learned

ReportId helps correlate recordsIt gives defenders a way to group related Microsoft Defender XDR records during an investigation.
Identifiers support correlationUse ReportId with NetworkMessageId, InternetMessageId and other fields to connect evidence across investigations.
Correlation still needs contextSender, recipient, subject, delivery and threat fields help explain what the ReportId is pointing to.

Related Agent Foskett Academy lessons

Investigating NetworkMessageIdConnect the same message across Microsoft Defender email, URL, click and attachment telemetry.
Investigating SubjectReview subject lines used in phishing lures and campaign themes.
Investigating RecipientEmailAddressIdentify mailboxes that received suspicious messages.
Investigating SenderDisplayNameReview the friendly sender name presented to recipients.
Investigating DeliveryActionUnderstand what Microsoft 365 did with the message.
Investigating EmailAuthenticationResultsReview SPF, DKIM, DMARC and composite authentication outcomes.

Coming next

Lesson 73 — Advanced UrlClickEvents Investigations in Microsoft Defender XDR Next, Agent Foskett Academy explores advanced UrlClickEvents investigations, showing how defenders determine whether users clicked malicious links, correlate phishing emails and build complete investigation timelines.
Why this matters ReportId helps correlate related investigation records. Advanced UrlClickEvents investigations reveal what happened after an email was delivered, helping defenders determine whether a phishing attempt became an active security incident.

Final thought

A single event rarely tells the whole story. ReportId helps defenders connect related records before building the timeline.
Agent Foskett mindsetDo not treat one row as the whole investigation. Use ReportId to connect related Defender evidence.
Follow the report evidenceReportId turns scattered Defender records into evidence that can be grouped, reviewed and tested.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Investigating ReportId in Microsoft Defender XDR

Agent Foskett Academy Lesson 72 teaches defenders how to investigate ReportId during Microsoft Defender XDR email investigations.

Learn ReportId investigation in Defender XDR

This lesson explains how ReportId, NetworkMessageId, InternetMessageId, Subject, SenderFromAddress, RecipientEmailAddress, DeliveryAction and ThreatTypes help defenders correlate email evidence and build reliable Microsoft Defender XDR investigation timelines.