Most phishing and business email compromise investigations stall because responders read the message body and the display name, when the evidence that answers "where did this come from and what did the attacker do next" sits in the headers, the authentication results and the mailbox audit trail. This guide explains how to acquire a message without altering it, read the trace and authentication headers in the right order, use provider logs (message trace, email log search, mailbox audit) to scope the incident, and record findings so they stand up later. It goes deeper on the analysis than the Business Email Compromise Response Playbook, which covers the response sequence. It is written for incident responders, SOC analysts and DFIR practitioners working with Microsoft 365, Google Workspace or on-premises mail. Product limits quoted were checked against vendor documentation on 27 October 2026.
Key takeaways
- Acquire the original, not a forward. Forwarding or pasting a message rewrites or drops headers; export the original (.eml or .msg, or the provider's "show original") and hash it before analysis.
- Read Received headers bottom to top. Each mail server prepends its own trace line, so the lowest Received header added by your own boundary is the first one you can trust; everything below it can be forged by the sender.
- Trust only your own Authentication-Results. RFC 8601 results are meaningful only when stamped by your border systems (your authserv-id); a header claiming "pass" inserted earlier in the path proves nothing.
- The mailbox, not the message, tells you the impact. In BEC the questions that matter are who signed in, which rules and forwarding were created, what was read and what was sent; those answers come from audit logs such as MailItemsAccessed and UpdateInboxRules.
- Log windows are short. Exchange Online message trace reaches back 90 days and Google Workspace step-by-step delivery detail 30 days; preserve exports on day one of the case.
Acquiring email evidence without changing it
Email is easy to alter by accident. A user who forwards a suspicious message to the SOC sends a new message with new headers; the original trace and authentication results may be lost or buried. Treat the message and the logs as evidence from the start, following the Evidence Handling and Chain of Custody Guide.
| Source | How to acquire | What it preserves | Watch out for |
|---|---|---|---|
| Microsoft 365 message | Report or submission as attachment, admin download from Explorer or quarantine, Content search or eDiscovery export | Full headers including X-Forefront-Antispam-Report and X-MS-Exchange-Organization-Network-Message-Id | User forwards inline; Outlook "view message source" copied as text loses attachments |
| Google Workspace message | "Show original" and download, or Vault export | Full raw RFC 5322 message with headers | Screenshots of Gmail's rendered view are not evidence of origin |
| On-premises Exchange or other MTA | Export from the mail store, journal or archive; MTA logs from the transport servers | Headers plus server-side transport logs | Log rotation on transport servers can be days, not months |
| Provider trace and audit logs | Message trace CSV, Email Log Search results, unified audit log export, Workspace audit log export | Delivery path, recipients, post-delivery actions, mailbox activity | Fixed look-back windows; exports must be repeated if the scope changes |
| Endpoint copies | OST and PST files, mobile device data, local caches | Messages deleted server-side, local rules | OST files are tied to the profile; collect with a triage tool and record the host |
- Hash on receipt: compute SHA-256 of each exported .eml, .msg and CSV and record who exported it, from which tenant and with which account.
- Use a dedicated analysis account: export and search with a named investigator role, not a shared global administrator, so the audit trail of your own actions is clean.
- Do not click or detonate on a workstation: open attachments and URLs only in a sandbox or isolated analysis host, and note any link that could signal to the sender (tracking pixels, unique URLs).
- Record message identifiers: Message-ID, Network Message ID (Microsoft) or the Gmail message ID, sender, recipients and received time in UTC. These keys tie the message to every log you will search.
Reading the headers in order
An RFC 5322 message has a header section and a body. Trace fields (Received and Return-Path) are added by systems that handle the message, and each SMTP server prepends its Received line above the previous ones, as RFC 5321 requires. The practical rule: start at the top, find the first Received line added by a system you control or trust (your gateway or your cloud provider's inbound edge), and treat everything below it as claimed by the sender.
Header fields that matter in investigations
| Header | What it tells you | Forgeable by sender? |
|---|---|---|
Received | Each hop: the "from" host as claimed (HELO) and as seen (reverse DNS and IP), the "by" host, protocol (SMTP, ESMTPS) and timestamp | Lines below your boundary: yes. Lines added by your systems: no |
Return-Path | The envelope sender (RFC 5321 MAIL FROM, the "P1" sender) recorded at final delivery; the domain SPF evaluates | Set by sender, but checked by SPF |
From | The author shown to the user (RFC 5322 From, the "P2" sender); the domain DMARC protects | Yes, unless DMARC is enforced for that domain |
Reply-To | Where replies go; a mismatch with From is a classic BEC indicator | Yes |
Message-ID | Unique identifier set by the originating system; the format often reveals the sending software or service | Yes, but useful for correlation across mailboxes and logs |
Date | Time set by the sender's client | Yes; compare with your own Received timestamp |
DKIM-Signature | Signing domain (d=), selector (s=), signed header list (h=) | Can be added by anyone, but only verifies with the domain's key |
Authentication-Results | SPF, DKIM, DMARC (and ARC) outcomes computed by the receiver | Only trust the instance with your own authserv-id |
ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results | Authentication results preserved by intermediaries such as mailing lists and forwarding services | Trust depends on whether you trust the sealer |
Authentication-Results
RFC 8601 (Standards Track, May 2019, obsoleting RFC 7601) defines the Authentication-Results header. It starts with an authserv-id naming the system that ran the checks, then method=result statements with properties such as smtp.mailfrom (SPF), header.d (DKIM) and header.from (DMARC). The RFC warns that a sender can insert a fake header using the receiver's own identifier, which is why border MTAs must remove any existing header that claims their identifier and did not come from a trusted system. A pass is also not a verdict of trust: spam and BEC from attacker-registered lookalike domains pass SPF, DKIM and DMARC routinely.
- SPF results:
pass,fail(domain publishes-all),softfail(~all),neutral,none,temperror,permerror. - DKIM results:
pass,failwith a reason,nonewhen unsigned. A DKIM pass ford=a bulk mail service tells you who signed, not who wrote the message. - DMARC: passes only when SPF or DKIM passes for a domain aligned with the From domain. See the DMARC, SPF and DKIM Guide and the ARC Guide for forwarded mail.
Microsoft 365 anti-spam headers
Exchange Online Protection adds headers that record what the filter saw and decided. These are among the most useful fields in a Microsoft tenant.
| Field | Meaning (per Microsoft Learn) | Investigative use |
|---|---|---|
CIP | Connecting IP address | Pivot to message trace and threat intelligence |
CTRY | Country or region of the connecting IP, which may differ from the original sender | Context only; do not attribute on it |
H | HELO or EHLO string of the connecting server | Compare with PTR; mismatches suggest misconfigured or malicious infrastructure |
PTR | Reverse DNS of the source IP | Identify hosting providers and bulk services |
DIR | INB, OUT or INT | INT on a phish means a compromised internal account |
SFV | Spam filter verdict, for example SPM, NSPM, SKA (allowed sender list), SKN (mail flow rule bypass), SKQ (released from quarantine) | Explains why a phish reached the inbox: an allow list or transport rule bypass is a finding in itself |
CAT | Policy category applied, for example PHSH, HPHISH, SPOOF, UIMP, DIMP, INTOS | Tells you what protection fired, or did not |
SFTY | 9.19 domain impersonation, 9.20 user impersonation, 9.25 first contact safety tip | Impersonation of an executive or supplier |
compauth and reason | Composite authentication; for example 000 explicit DMARC fail, 001 implicit fail, 130 ARC override, 601 intra-org spoofing | Whether a spoof was caught and why it was still delivered |
The Network Message ID (X-MS-Exchange-Organization-Network-Message-Id) is unique per message copy and is the key for message trace and Defender hunting queries.
Common header patterns and what they indicate
| Pattern | Likely meaning | Next step |
|---|---|---|
| From is your CEO, Reply-To is a free mail address | Classic BEC display-name or reply diversion | Search for the Reply-To address across all mailboxes |
| From domain is one character off a supplier, SPF, DKIM and DMARC all pass | Lookalike domain registered by the attacker | Record registration details, block the domain, check other recipients |
DIR:INT, DKIM pass for your own domain, sent from a real employee mailbox | Account takeover, internal spearphishing | Move to mailbox audit and sign-in logs for that account |
| Genuine supplier domain, DKIM pass, unusual sending IP and new Reply-To | Supplier mailbox compromise (vendor email compromise) | Notify the supplier through a known contact; review payment changes |
SFV:SKA or SFV:SKN on a malicious message | Allow list or transport rule let it through | Review the allow entry or rule as part of root cause |
| Date header hours away from your first trusted Received time | Clock skew, queued delivery, or forged Date | Use your Received timestamp in the timeline |
DKIM d= is a bulk or transactional mail service | Sent through a legitimate platform, possibly with stolen API keys | Report to the platform; see the SendGrid, Mailgun and Mailchimp API Keys Security Guide |
The TruffleNet campaign is a reminder of the last row: Fortinet observed a fake vendor invoice sent through Amazon SES from a compromised AWS account, though it could not confirm the link to the key-testing activity. BEC sent through a cloud email service using stolen keys arrives with valid authentication for the abused infrastructure, so the header story is "authenticated, but not by the party it claims".
Scoping with provider logs
Message trace and email log search
- Exchange Online message trace: the default window is 2 days and you can search back 90 days; summary results are instant for 10 days or less, while older searches produce enhanced summary or extended CSV reports from archived data that can take hours. Search by Message ID, Network Message ID, sender, recipient or original client IP (the last only for 10 days). PowerShell uses
Get-MessageTraceV2andGet-MessageTraceDetailV2(Exchange Online PowerShell V3 module 3.7.0 or later), throttled to 100 requests per 5 minutes per tenant. - Google Workspace Email Log Search: searches by date, sender, recipient, sender IP, recipient IP, subject and Message ID. Ranges are up to the past 30 days; older messages need the full recipient address and the Message ID, and step-by-step delivery detail is not available beyond 30 days. It shows post-delivery status (labels, location, spam marking, deletion) but not message content.
- Use it to scope: once you have one malicious message, search the sender address, sending IP, subject and any URL domain to find every recipient, then confirm which copies were delivered, read, quarantined or deleted.
Mailbox audit and the unified audit log
In Microsoft 365, mailbox auditing is on by default and the default audit set includes MailItemsAccessed, UpdateInboxRules, Send, SendAs, SendOnBehalf, HardDelete, SoftDelete and MoveToDeletedItems for the relevant sign-in types. Verify the tenant with Get-OrganizationConfig | Format-List AuditDisabled before relying on it. Retention is governed by Microsoft Purview audit log retention policies, so confirm what your licence actually keeps. See the Microsoft 365 Unified Audit Log Guide for Detection.
| Question | Microsoft 365 evidence | Google Workspace evidence | ATT&CK |
|---|---|---|---|
| Did the attacker read mail, and which messages? | MailItemsAccessed with MailAccessType Bind (per item, InternetMessageId) or Sync (whole folder) | Gmail log events in the audit and investigation tool | T1114.002 Remote Email Collection |
| Was a rule created to hide or forward mail? | UpdateInboxRules (client), New-InboxRule and Set-InboxRule (admin and PowerShell activity), Get-InboxRule to inspect | Gmail settings change events, filters and forwarding | T1564.008 Email Hiding Rules, T1114.003 Email Forwarding Rule |
| Did they send as the victim? | Send, SendAs, SendOnBehalf; message trace for outbound | Email Log Search outbound | T1534 Internal Spearphishing |
| Did they add a delegate or app access? | Add-MailboxPermission, consent and app role assignments in Entra audit logs | Delegation and OAuth token events | T1098.002 Additional Email Delegate Permissions |
| Did they cover tracks? | SoftDelete, HardDelete, MoveToDeletedItems | Post-delivery deletion in Email Log Search | T1564.008 |
Interpreting MailItemsAccessed
- Sync records are logged when desktop Outlook for Windows or Mac downloads a folder; one record covers the folder and Microsoft's guidance is to assume every item in it was accessed. If a Sync record shares the attacker's context (ClientIPAddress, ClientInfoString, SessionId), treat the whole mailbox as exposed.
- Bind records capture individual message access with the InternetMessageId of each item; binds within a 2-minute interval are aggregated, and duplicates within an hour are filtered unless the context differs.
- Context separates attacker from user: group events by SessionId, client IP and client string, then match to the sign-in logs for the same session.
Mail access by applications rather than users needs the same rigour. In the Microsoft Midnight Blizzard breach the attacker used an OAuth application granted the Exchange Online full_access_as_app role to read mailboxes without signing in as each user, and Microsoft detected it by reviewing EWS activity and audit logs. In the Storm-0558 key breach, a customer spotted forged-token mail access only because premium audit logging and a custom alert on MailItemsAccessed were in place.
Where identity fits
An email investigation is an identity investigation once it moves past the first message. Three identity types show up repeatedly: the user account whose session was stolen (often by adversary-in-the-middle phishing, see the AiTM Phishing Guide), OAuth applications with mail scopes granted by consent phishing (see the Consent Phishing and Illicit OAuth Grants Guide), and API keys for mail delivery services. For each, list the credentials and grants that can read or send mail, check when they were last used and from where, and revoke sessions and tokens rather than only resetting passwords.
Building the timeline and report
- Anchor event: the first malicious message, with its Message-ID, Network Message ID, recipients and your first trusted Received time in UTC.
- Delivery scope: every copy delivered, quarantined or removed (message trace or Email Log Search export, hashed).
- User interaction: clicks from URL protection logs, attachment opens from endpoint telemetry, credential entry if known.
- Account activity: sign-ins and MFA events for affected accounts, then mailbox audit for rules, access, sends and deletions in the same sessions.
- Outbound activity: messages sent from compromised mailboxes, especially to finance contacts and suppliers, plus any payment detail changes.
- Containment actions: what you removed, revoked and reset, and when, logged as part of the timeline. See the Forensic Timeline Analysis Guide.
Write findings as "header X, added by system Y, shows Z", never "the email came from Russia". Note which statements rest on sender-controlled fields.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.AE-02, RS.AN-03, RS.AN-06 | Analysing adverse events, establishing root cause, preserving the integrity and provenance of investigation records |
| NIST SP 800-53 Rev. 5 | AU-6, AU-11, AU-12, IR-4, SI-8 | Audit review, retention and generation; incident handling; spam protection |
| NIST SP 800-86 | Collection, examination, analysis, reporting | Forensic process applied to email and logs |
| CIS Controls v8.1 | Control 8 (audit log management), Control 9 (email and web browser protections), Control 17 (incident response management) | Logging, DMARC and filtering, response process; see the CIS Control 9 Email and Web Browser Protections Guide |
| ISO/IEC 27001:2022 Annex A | 5.25, 5.26, 5.28, 8.15 | Assessment of events, response to incidents, collection of evidence, logging |
| MITRE ATT&CK v20 | T1566.001, T1566.002, T1534, T1114.002, T1114.003, T1564.008, T1098.002 | Phishing delivery, internal phishing, mail collection, hiding rules, delegate permissions |
Detection and measurement
- Alerts worth having: new inbox rules that move to RSS Feeds, Archive or Deleted Items or that forward externally; external auto-forwarding enabled on a mailbox; MailItemsAccessed from a new IP or client string for executive and finance mailboxes; OAuth consents granting Mail.Read or Mail.Send.
- Time to header verdict: minutes from report to a documented origin and authentication assessment (target under 30 minutes).
- Scope completeness: percentage of cases where every recipient of a campaign was identified and remediated within 4 hours.
- Audit coverage: percentage of mailboxes with auditing enabled and the default audit set intact, checked monthly.
- Evidence preservation lag: hours between case opening and hashed export of trace and audit logs.
- Allow list findings: number of malicious messages delivered via
SFV:SKA,SKNorSKIper quarter, trending to zero.
Common failure patterns
- Analysing a forwarded copy: the SOC reads headers of the user's forward and attributes the phish to your own mail server.
- Trusting the bottom Received line: analysts quote an IP the sender wrote into a forged Received header as the origin.
- Stopping at "DMARC pass": lookalike domains and compromised supplier mailboxes pass authentication; the question is whether the domain and the sending behaviour are expected.
- Missing the rules: passwords are reset but the forwarding rule and the OAuth grant stay, so the attacker keeps receiving mail. Check rules, forwarding, delegates and app consents every time.
- Losing the window: message trace detail and original client IP age out while the team debates scope; export first, analyse second.
- Assuming logging you do not have: the team discovers mid-incident that audit records for the period are not retained at the licence tier in use.
Practitioner checklist
- Publish a "report as attachment" or report button process so the SOC always receives the original message.
- Export and SHA-256 hash the original message, message trace and audit log results on case opening.
- Identify the first Received header added by your own boundary and record its IP and UTC time.
- Read Authentication-Results only from your own authserv-id; record SPF, DKIM, DMARC and compauth outcomes.
- Check From, Reply-To, Return-Path and DKIM
d=for mismatches and lookalike domains. - Scope recipients by sender, IP, subject and URL across the tenant before remediation.
- Review MailItemsAccessed, UpdateInboxRules, Send and SendAs for every affected mailbox, grouped by session.
- Check inbox rules, forwarding, delegates and OAuth app consents on each compromised account and remove them.
- Confirm mailbox auditing is enabled and audit retention covers your investigation needs.
- Record every finding against the field and system that produced it.
Standards and references
- IETF: RFC 8601 Message Header Field for Indicating Message Authentication Status
- NIST: SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
- Microsoft Learn: Anti-spam message headers in Microsoft 365
- Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
- Microsoft Learn: Manage mailbox auditing
- Microsoft Learn: New message trace in the Exchange admin center
- Google Workspace Admin Help: Find messages with Email Log Search
- MITRE ATT&CK: Email Hiding Rules
Related NHI Mgmt Group resources: Business Email Compromise Response Playbook · Phishing Incident Response Playbook · DMARC, SPF and DKIM Guide · Microsoft 365 Unified Audit Log Guide for Detection · Digital Forensics (DFIR) Guide