Agent Foskett Academy • Lesson 51 • Email Investigation Pivot

Investigating NetworkMessageId in Microsoft Defender XDR.

One email can appear in many places.

EmailEvents records the message.

EmailUrlInfo extracts the links.

UrlClickEvents records the click.

EmailAttachmentInfo records the files.

NetworkMessageId connects the evidence.

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

Learn how NetworkMessageId helps defenders follow the same email across Microsoft Defender XDR tables and build a connected email investigation.

Find the original email
Pivot into URL and click evidence
Connect attachments and URLs
Turn one message into one case

Why NetworkMessageId matters

NetworkMessageId is one of the most useful fields in Microsoft Defender XDR email investigations. It helps defenders connect the same message across email, URL, click and attachment telemetry.
It links email evidenceThe same message identifier can appear in EmailEvents, UrlClickEvents, EmailAttachmentInfo and EmailUrlInfo.
It prevents guessingInstead of matching only on subject, sender or recipient, defenders can pivot using the message identifier.
It builds the storyNetworkMessageId helps connect delivery, URLs, attachments and user interaction into one investigation.

Investigation scenario

A suspicious email arrived. It contained a link and an attachment. Later, the user clicked the link. The evidence existed in multiple tables, but the NetworkMessageId connected it.
The email was deliveredEmailEvents showed the sender, recipient, subject, delivery action and NetworkMessageId.
The URL was extractedEmailUrlInfo showed the URL that was found inside the message.
The user clickedUrlClickEvents showed post-delivery user interaction with the link.

Step 1 — Start with EmailEvents

First, find the message and capture the NetworkMessageId. This becomes the pivot value for the rest of the investigation.
networkmessageid-step-1-email-events.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
EmailEvents
| where Timestamp > ago(30d)
| where Subject has "Invoice"
| project Timestamp, NetworkMessageId, SenderFromAddress,
          RecipientEmailAddress, Subject, DeliveryAction
| order by Timestamp desc
Investigation note: Once you find the message, copy the NetworkMessageId. It is the bridge into the next tables.

Step 2 — Reuse the message identifier

A let statement makes the investigation easier to read and repeat. Store the NetworkMessageId once, then reuse it across multiple queries.
networkmessageid-step-2-let-message-id.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
let MessageId = "<paste NetworkMessageId here>";
EmailEvents
| where NetworkMessageId == MessageId
| project Timestamp, SenderFromAddress,
          RecipientEmailAddress, Subject, DeliveryAction
Why this helps: The query now focuses on one message instead of searching the entire email dataset again.

Step 3 — Pivot into EmailUrlInfo

EmailUrlInfo can show URLs extracted from the email. NetworkMessageId lets defenders connect those URLs back to the original message.
networkmessageid-step-3-email-url-info.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
let MessageId = "<paste NetworkMessageId here>";
EmailUrlInfo
| where NetworkMessageId == MessageId
| project Timestamp, NetworkMessageId, Url,
          UrlDomain, UrlLocation
| order by Timestamp asc
Investigation note: This step helps identify the links embedded in the original message before checking whether anyone clicked them.

Step 4 — Pivot into UrlClickEvents

UrlClickEvents can show whether the recipient clicked a URL from the message. This is where delivery becomes user interaction.
networkmessageid-step-4-url-click-events.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
let MessageId = "<paste NetworkMessageId here>";
UrlClickEvents
| where NetworkMessageId == MessageId
| project Timestamp, AccountUpn, Url,
          ActionType, Workload, IPAddress
| order by Timestamp asc
Timeline entry: The same NetworkMessageId can show whether a delivered email later became a click event.

Step 5 — Pivot into EmailAttachmentInfo

If the message included attachments, EmailAttachmentInfo helps defenders review filenames, hashes and attachment metadata connected to the same message.
networkmessageid-step-5-email-attachment-info.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
let MessageId = "<paste NetworkMessageId here>";
EmailAttachmentInfo
| where NetworkMessageId == MessageId
| project Timestamp, NetworkMessageId, FileName,
          FileType, SHA256, RecipientEmailAddress
| order by Timestamp asc
Investigation note: This turns the email into file evidence that can later be followed into endpoint telemetry.

Step 6 — Join message and click evidence

You can also join tables on NetworkMessageId to build one view of delivery and click activity.
networkmessageid-step-6-join-email-clicks.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
  14. 14
EmailEvents
| where Timestamp > ago(30d)
| where ThreatTypes has "Phish"
| join kind=leftouter (
                            UrlClickEvents
    | where Timestamp > ago(30d)
    | project NetworkMessageId, ClickTime = Timestamp,
              AccountUpn, Url, ActionType
) on NetworkMessageId
| project Timestamp, SenderFromAddress, RecipientEmailAddress,
          Subject, DeliveryAction, ClickTime, AccountUpn, Url, ActionType
| order by Timestamp desc
Why this matters: The join helps answer a critical question quickly: was the phish only delivered, or was it clicked?

What NetworkMessageId helps answer

This field is useful because it turns separate tables into one investigation path.
Was the email delivered?EmailEvents shows delivery outcome, sender, recipient and subject.
What URLs were inside it?EmailUrlInfo helps identify the links that were extracted from the message.
Did the user click?UrlClickEvents helps confirm post-delivery interaction and click action.
Were attachments involved?EmailAttachmentInfo helps identify files and hashes connected to the message.
Can we explain the timeline?NetworkMessageId helps connect the message to what happened next.
Can we report clearly?One identifier makes the investigation easier to explain to technical and non-technical audiences.

Common mistakes

NetworkMessageId is powerful, but defenders still need to use it carefully.
Relying only on subject linesSubjects can be reused, changed or misleading. NetworkMessageId is a stronger pivot for the specific message.
Forgetting time windowsWhen joining tables, keep sensible timestamp filters on both sides of the query.
Stopping at deliveryAn email investigation should not stop when the message is found. Check URLs, clicks, attachments and post-delivery activity.
NetworkMessageId connects the email to everything that happened next.
Use it to move from a single message to a complete Defender XDR email investigation.
Back to Academy →

What you learned

NetworkMessageId is a pivotIt helps connect the same email across multiple Microsoft Defender XDR tables.
Email investigations need joinsDelivery, URLs, clicks and attachments become more useful when connected.
One message can become one caseThe field helps defenders turn scattered telemetry into a single investigation story.

Related Agent Foskett Academy lessons

Investigating EmailEventsStart with the suspicious message and understand sender, recipient and delivery evidence.
Investigating UrlClickEventsConfirm whether a user clicked a suspicious link.
Investigating EmailAttachmentInfoReview attachments, filenames, hashes and file evidence connected to email.
Investigating EmailUrlInfoReview URLs extracted from messages and connect them to phishing investigations.
Connecting Tables with joinLearn how to combine evidence from multiple Defender XDR tables.
Using let StatementsStore evidence values and reuse them across investigation queries.
Building Investigation TimelinesPlace related events in chronological order.
Lesson 50 — The Timeline Told The StoryReview the capstone investigation that connects evidence into one story.

Coming next

Lesson 52 — Investigating EmailAuthenticationResultsNext, Agent Foskett Academy will examine how SPF, DKIM, DMARC and composite authentication appear in Microsoft Defender XDR email investigations.
Why this mattersAfter connecting evidence with NetworkMessageId, defenders need to understand whether the sender authentication actually supports trust.
What you will learn nextLearn how to compare authentication results, sender alignment, DMARC evidence and suspicious delivery outcomes.

Final thought

One message. One identifier. Many pieces of evidence.
Agent Foskett mindsetDo not treat email tables as separate islands. Use the message identifier and connect the evidence.
Follow the messageThe email may start in EmailEvents, but the investigation often continues through URLs, clicks, attachments and endpoint activity.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Investigating NetworkMessageId in Microsoft Defender XDR

Agent Foskett Academy Lesson 51 teaches defenders how to use NetworkMessageId to connect EmailEvents, UrlClickEvents, EmailAttachmentInfo and EmailUrlInfo during Microsoft Defender XDR investigations.

Learn NetworkMessageId for Defender XDR email investigations

This lesson explains how NetworkMessageId acts as the bridge between message delivery, extracted URLs, user clicks, attachments and post-delivery email evidence.