SOC Phishing Email Triage

Phishing triage should preserve the original evidence and avoid creating new exposure. Do not click a link, open an attachment, reply to the sender, or forward the message as ordinary inline text. Use your organization’s approved report flow, mail investigation tooling, and sandbox procedures.

Figure 1: Preserve the original message and review its source details without opening embedded content.

---

Step 1: Preserve the Report and Message

01

Capture the Original Message Safely

Evidence Intake

Record the reporting user, mailbox, received time and time zone, subject, recipient, and message ID if available. Preserve the original item using the approved submission workflow or export format so headers and attachment metadata remain intact. If evidence must be transferred, use the approved case store; do not send it to a personal mailbox or public analysis service.

Case and reporter:
Mailbox and recipient:
Received time / time zone:
Subject and message ID:
Preservation method and evidence location:

❯ View Expected Console Output

Original message preserved; no link or attachment opened.

---

Step 2: Review Sender and Routing Headers

02

Inspect the Message Details or Raw Source

Header Review

In new Outlook or Outlook on the web, open the message’s More actions → View → View message details. In other mail clients, use the equivalent source or internet-header view. Compare the visible From address with Reply-To, Return-Path, Message-ID, and the trusted mail gateway’s Received and Authentication-Results headers. Received lines are added as the message moves through mail servers; lines before the message reaches infrastructure you trust can be forged. Keep the original header block with the case.

From / Reply-To / Return-Path:
Message-ID and recipient:
Trusted inbound gateway:
Received path within the trusted mail boundary:
Unexpected sender, relay, or reply destination:

❯ View Expected Console Output

Header observations are tied to the mail gateway and original message.

---

Step 3: Interpret SPF, DKIM, and DMARC Results

03

Check Authentication at the Trusted Boundary

Sender Validation

Read SPF, DKIM, and DMARC results from the trusted receiving system, not a similarly named header supplied by an untrusted sender. Check the authenticated domain and alignment with the visible From domain. A pass means a specific authentication check passed; it does not prove the message is benign. Forwarding and mailing lists can also change SPF results, so interpret them with the route and DKIM/DMARC evidence.

SPF result and authenticated domain:
DKIM result and signing domain:
DMARC result and alignment:
Trusted system that added the result:

❯ View Expected Console Output

No single authentication result is treated as the verdict.

---

Step 4: Assess Links and Attachments Without Opening Them

04

Record Indicators Using Approved Tools

Safe Content Review

Extract visible URLs from the preserved message and defang them in case notes, for example hxxps://example[.]test/path. Do not visit them in a normal browser. Use only an approved URL analysis or sandbox service and follow data-sharing rules before submitting content externally. For attachments, record the filename, actual file type, size, and hash; inspect them only in the approved isolated analysis environment.

URL as displayed / defanged URL:
Link display text and actual destination:
Attachment name / type / size / SHA-256:
Reputation or sandbox source and result:

❯ View Expected Console Output

No message content was executed or opened on the analyst workstation.

---

Step 5: Check Whether Other Mailboxes Received It

05

Scope the Message Across the Tenant

Recipient Scope

Use the approved mail trace, Defender email investigation view, or SOC search workflow to look for the message ID, sender, subject, URL, and attachment hash. Record recipients, delivery locations, user reports, clicks, and any quarantine or remediation status. Threat Explorer is included with Defender for Office 365 Plan 2; Real-time detections is included with Plan 1. Product access also depends on role permissions and tenant configuration.

Search keys: Network Message ID / Message-ID / sender / subject / URL / hash
Time range and mail system queried:
Recipients and delivery state:
Known clicks, replies, or follow-up reports:

❯ View Expected Console Output

Tenant scope and collection limits documented for the case.

---

Step 6: Classify, Contain, and Hand Off

06

Document the Disposition and Owner

Case Decision

State whether the evidence supports phishing, benign marketing, a false positive, or an unresolved case, and explain why. If the organization approves removal or blocking, record the approving role, scope, time, and validation. If a user clicked or submitted credentials, follow the identity incident playbook and escalate promptly; do not attempt an ad hoc password reset or broad tenant block from the mail triage record alone.

Evidence and source links:
Authentication and routing observations:
URL / attachment analysis results:
Recipient scope and user impact:
Classification and confidence:
Approved action, approver, and completion check:
Next owner and user communication:

❯ View Expected Console Output

The disposition is evidence-based, reversible actions are recorded,
and any credential exposure is handed to the identity response owner.

Do not interact with suspicious content

Do not click links, open attachments, reply, scan a QR code, or upload an original message to an unapproved public service. Preserve it and use your organization’s isolated analysis and incident response process.

References

Microsoft Support: view internet message headers in Outlook · Microsoft Defender: investigate emails in Threat Explorer · Microsoft Defender XDR: investigate alerts · Microsoft: anti-phishing protection