Agent Foskett Academy • SOC Analyst Academy • Module 5 • Lesson 41 • Email & Phishing: From Message to Compromise

Lesson 41 — The Email Looked Legitimate at First

The user did not report a badly written message or an obvious scam.

The email looked ordinary. It used a familiar company name, professional wording and a normal signature. It had even reached the inbox.

Agent Foskett ignored the appearance for a moment and asked:

Who actually sent this message, how was it authenticated, and how did Microsoft 365 deliver it?

A convincing email is not evidence of legitimacy. Start with message telemetry, not appearance.

Start the Email Triage Back to SOC Analyst Academy

Agent Foskett investigating a suspicious email in Microsoft Defender XDR

The message looked legitimate

Establish the sender, domain, authentication results, delivery action, recipients and embedded URLs before reaching a verdict.

✓ Identify the message

✓ Validate sender evidence

✓ Review authentication

✓ Establish delivery context

Case briefing

USER REPORT "Is this email legitimate?" DISPLAY NAME Accounts Team SUBJECT Updated Supplier Banking Details DELIVERY Inbox ↓ THE MESSAGE LOOKS NORMAL ↓ SOC QUESTIONS Who actually sent it? Which domain was used? Did SPF / DKIM / DMARC pass? How was the message delivered? Who else received it? What URLs are inside it?

Investigation objective

Perform first-stage phishing triage by identifying the message and validating sender, authentication, delivery and recipient evidence before deciding whether it is benign or suspicious.

Investigator's rule

Do not investigate the email the way the user sees it. Investigate the message Microsoft 365 recorded.

Stage 1 — find the message

123456789101112

EmailEvents
| where Timestamp > ago(7d)
| where Subject =~ "Updated Supplier Banking Details"
| project Timestamp,
          NetworkMessageId,
          SenderFromAddress,
          SenderFromDomain,
          RecipientEmailAddress,
          Subject,
          DeliveryAction,
          DeliveryLocation
| order by Timestamp desc

Capture the NetworkMessageId

The subject is useful for discovery, but it is not a unique identifier. Preserve the NetworkMessageId so the message can be correlated with other email telemetry.

Start with facts

Record the sender address, sender domain, recipient, timestamp and delivery result before interpreting whether the message is malicious.

Stage 2 — inspect authentication and delivery evidence

12345678910111213

let MessageId = "<NETWORK-MESSAGE-ID>";
EmailEvents
| where NetworkMessageId == MessageId
| project Timestamp,
          SenderFromAddress,
          SenderFromDomain,
          SenderMailFromAddress,
          SenderMailFromDomain,
          AuthenticationDetails,
          ThreatTypes,
          DetectionMethods,
          DeliveryAction,
          DeliveryLocation

From and MailFrom are different clues

The visible sender and envelope sender can tell different parts of the story. Differences are not automatically malicious, but they deserve context.

Authentication is evidence, not a verdict

SPF, DKIM and DMARC help establish authentication and alignment. They do not prove that the message itself is trustworthy.

Stage 3 — interpret authentication carefully

Signal	What it helps answer	What it does not prove
SPF	Was the sending source authorised for the envelope domain?	That the visible sender is who the user thinks it is.
DKIM	Was the message signed for a signing domain?	That the sender's intent was legitimate.
DMARC	Did authentication and alignment satisfy DMARC?	That the content, link or business request is safe.
Delivery action	How did Microsoft 365 handle the message?	That inbox delivery makes it benign.

A pass can still belong to an attacker

An attacker can correctly authenticate mail sent from a deceptive domain or infrastructure they control.

A failure needs context too

Forwarding and third-party mail flows can affect authentication. Treat results as evidence to investigate, not shortcuts to a verdict.

Stage 4 — inspect URLs in the message

123456789

let MessageId = "<NETWORK-MESSAGE-ID>";
EmailUrlInfo
| where NetworkMessageId == MessageId
| project Timestamp,
          NetworkMessageId,
          Url,
          UrlDomain
| order by Timestamp asc

The link can contradict the sender

A message may use a familiar display name while directing the recipient to an unrelated or look-alike domain.

Do not click to investigate

Use security telemetry and approved analysis processes rather than interacting with a suspicious URL from a normal workstation.

Stage 5 — determine who else received it

12345678910

EmailEvents
| where Timestamp > ago(7d)
| where Subject =~ "Updated Supplier Banking Details"
| summarize
    Recipients=dcount(RecipientEmailAddress),
    RecipientList=make_set(RecipientEmailAddress, 50)
    by SenderFromAddress,
       SenderFromDomain,
       Subject

One report may reveal a campaign

The reporting user may be only one recipient. Scope early enough to know whether the SOC is investigating a single message or broader targeting.

Subject matching is only a start

Attackers can vary subjects and sender addresses. Later scoping should also pivot on URLs, domains, hashes and shared infrastructure.

Stage 6 — compare appearance with telemetry

WHAT THE USER SAW Accounts Team Professional wording Company logo Normal-looking signature ↓ WHAT THE SOC CHECKED SenderFromAddress SenderFromDomain SenderMailFromDomain AuthenticationDetails DeliveryAction DeliveryLocation NetworkMessageId URL domain Recipient scope ↓ VISUAL TRUST ≠ TECHNICAL EVIDENCE

The display name is presentation

It is useful context, but it should never outrank the actual sender address, domain and message telemetry.

Branding is easy to imitate

Logos, signatures and familiar wording can explain why a user trusted an email, but they do not authenticate it.

Stage 7 — make the first triage decision

Observation	Analyst meaning
Familiar display name	Low evidentiary value by itself.
Unexpected sender domain	Requires validation against the claimed organisation or workflow.
Authentication passes	Confirms specific authentication conditions, not benign intent.
Inbox delivery	The message reached the user; it is not proof of safety.
Unrelated URL domain	Raises suspicion and creates a strong investigation pivot.
Multiple recipients	May indicate broader targeting and increases scoping priority.

Stage 8 — write the initial finding

INITIAL SOC FINDING The reported message was delivered to the user's inbox and visually presented itself as a familiar business communication. Email telemetry identified the actual sender address and domain, authentication results, delivery action and embedded URL information. The message cannot be classified as legitimate from appearance or inbox delivery alone. Further investigation should validate the sender domain, URL destination and campaign scope before a final verdict is recorded.

Lesson 41 key takeaways

Begin phishing triage with message telemetry rather than visual appearance.
Use the subject to discover a message, then preserve the NetworkMessageId.
Record the actual sender address and sender domain.
Compare visible sender information with envelope sender evidence.
Review SPF, DKIM and DMARC as evidence, not as a final verdict.
Inbox delivery does not prove that a message is benign.
Inspect embedded URLs and their domains without casually clicking them.
Check whether other recipients received related messages.
Separate what the user saw from what Microsoft 365 recorded.
Write an initial finding that states what is known and what still requires investigation.

Module 5 — Email & Phishing: From Message to Compromise

Lesson 41 establishes the foundation for email investigation. Next, Agent Foskett examines one of the simplest and most effective social-engineering tricks: a familiar display name hiding an unfamiliar domain.

Next: Lesson 42 — The Display Name Was Familiar — The Domain Wasn't

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 5: Email & Phishing: From Message to Compromise

Follow phishing evidence from message delivery through clicks, credential exposure, mailbox activity and campaign scope.

← Previous lesson

Lesson 40 — Building the Complete Endpoint Compromise Timeline Reconstruct the attack chain from execution to movement.

✅ Current lesson

Lesson 41 — The Email Looked Legitimate at First Start phishing triage with sender, authentication and delivery evidence.

Next lesson →

Lesson 42 — The Display Name Was Familiar — The Domain Wasn't Separate visual trust from sender identity.

How to investigate a suspicious email in Microsoft Defender XDR

Lesson 41 of the Agent Foskett SOC Analyst Academy teaches phishing triage using EmailEvents and EmailUrlInfo to investigate sender identity, authentication evidence, delivery actions, URLs and recipient scope.

Email phishing triage with KQL

Learn how SOC analysts move beyond display names and message appearance to establish what Microsoft 365 actually recorded about a suspicious email.