13.3 Email Forensics: RFC 5322 Headers, Authentication (SPF, DKIM, DMARC) & Mbox/PST Extraction

13.3 Email Forensics: RFC 5322 Headers, Authentication (SPF, DKIM, DMARC) & Mbox/PST Extraction

Quick Answer: Email forensics encompasses the technical tracing, authentication, and parsing of electronic mail communications. While SMTP transports messages between Mail Transfer Agents (MTAs), RFC 5322 defines message formatting. Critical forensic evidence resides in Received: headers, which are prepended chronologically by each receiving MTA; investigators must parse them bottom-up (earliest to latest) to trace the true originating sender IP. Crucially, adversaries can forge user-facing From:, Return-Path:, and client-injected headers, but they cannot forge the Received: header stamped by the victim's receiving border MTA. Domain anti-spoofing is enforced through SPF (DNS TXT record specifying authorized sending IPs), DKIM (asymmetric cryptographic signature of email headers and body), and DMARC (policy enforcement specifying reject, quarantine, or none, requiring domain alignment). On client endpoints, forensic artifacts reside in Microsoft Outlook PST/OST databases and Unix Mbox spools.

---

Email Architecture & Protocol Foundations

Understanding email forensics requires distinguishing between the functional software agents that handle messages and the communication protocols that govern transport.

+-------------------------------------------------------------------------+
|                   EMAIL INFRASTRUCTURE ARCHITECTURE                     |
+-------------------------------------------------------------------------+
| Component | Full Name              | Function & Representative Software |
|-----------|------------------------|------------------------------------|
| **MUA**   | Mail User Agent        | Client program used to compose,    |
|           |                        | send, and read email (Outlook,     |
|           |                        | Thunderbird, Apple Mail, Webmail)  |
| **MSA**   | Mail Submission Agent  | Ingests mail from MUA; authenticates|
|           |                        | user and forwards to local MTA     |
| **MTA**   | Mail Transfer Agent    | Routes messages across internet via|
|           |                        | SMTP (Postfix, Sendmail, Exchange) |
| **MDA**   | Mail Delivery Agent    | Receives mail from MTA and writes  |
|           |                        | to user mailbox store (Dovecot)    |
+-------------------------------------------------------------------------+

Standard Message Flow:
[Sender MUA] --> (SMTP:587) --> [Sender MSA/MTA] --> (SMTP:25) --> [Receiver MTA] --> [MDA] --> (IMAP/POP3) --> [Receiver MUA]

Transport & Retrieval Protocols

• Simple Mail Transfer Protocol (SMTP): Governs push-based message transmission. Operates on Port 25 (unencrypted server-to-server MTA routing), Port 587 (client-to-server submission with mandatory STARTTLS encryption), and legacy Port 465 (SMTPS / SSL).
• Post Office Protocol version 3 (POP3): Operates on Port 110 (cleartext) and Port 995 (POP3S / SSL). Downloads messages from the mail server to the local client and deletes them from the server by default, centralizing evidence on the local host.
• Internet Message Access Protocol (IMAP): Operates on Port 143 (cleartext) and Port 993 (IMAPS / SSL). Synchronizes folders, message flags (Read, Flagged), and draft states bidirectionally between client and server, keeping evidence distributed across both endpoints.

SMTP Command-Reply Session Walkthrough

An SMTP conversation consists of ASCII command strings issued by the sending client and three-digit numerical reply codes returned by the receiving MTA:

S: 220 mail.victim.com ESMTP Postfix
C: EHLO mail.attacker.com
S: 250-mail.victim.com
S: 250-STARTTLS
S: 250 OK
C: MAIL FROM:<ceo@spoofed-company.com>
S: 250 2.1.0 Ok
C: RCPT TO:<cfo@victim.com>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "CEO Name" <ceo@spoofed-company.com>
C: To: <cfo@victim.com>
C: Subject: Urgent Wire Transfer Request
C: Date: Tue, 22 Sep 2026 14:00:00 -0400
C: Message-ID: <12345@spoofed-company.com>
C:
C: Please execute the attached invoice immediately.
C: .
S: 250 2.0.0 Ok: queued as 4S9X2Z001
C: QUIT
S: 221 2.0.0 Bye

The Critical Distinction: Envelope vs. Header

• Envelope Sender (MAIL FROM: / RFC 5321): Specified during the SMTP protocol handshake. Dictates where delivery failure notifications (bounces / Non-Delivery Reports) are routed. Stored as Return-Path: by the receiving server.
• Header From (From: / RFC 5322): Contained within the message DATA payload. This is the only address displayed to the end user in Outlook or webmail.
• Forensic Implication: SMTP does not require the Envelope MAIL FROM: to match the Header From:. Anyone can connect to an open mail relay, specify an arbitrary Header From:, and impersonate any identity unless anti-spoofing controls (SPF/DKIM/DMARC) are enforced.

---

RFC 5322 Email Header Anatomy & Bottom-Up Parsing

An email message consists of two sections: Headers (structured transmission metadata) and Body (message content and MIME attachments), separated by a single blank line (<CR><LF>).

+-------------------------------------------------------------------------+
|                   CRITICAL RFC 5322 EMAIL HEADERS                       |
+-------------------------------------------------------------------------+
| Header Field           | Origin / Purpose       | Forensic Utility      |
|------------------------|------------------------|-----------------------|
| **Received:**          | Added by each MTA in   | Core tracking hop;    |
|                        | the transmission path  | parsed bottom-to-top  |
| **Return-Path:**       | Added by destination   | True bounce-back      |
|                        | MDA from MAIL FROM     | address (envelope)    |
| **Message-ID:**        | Generated by sending   | Unique message GUID;  |
|                        | MTA or client MUA      | identifies mail server|
| **Authentication-**    | Added by receiving     | Records SPF, DKIM,    |
| **Results:**           | border MTA             | and DMARC pass/fail   |
| **X-Originating-IP:**  | Added by webmail /     | Reveals true physical |
|                        | internal MSAs          | client IP of sender   |
| **X-Mailer:**          | Added by MUA client    | Identifies software   |
|                        |                        | used to generate mail |
+-------------------------------------------------------------------------+

The Bottom-Up Rule for Received: Headers

Whenever an MTA receives a message, it generates a new Received: header and prepends it to the very top of the existing header block. Consequently:

• The bottom-most Received: header represents the earliest point in the recorded transmission path.
• The top-most Received: header represents the final hop (the receiving organization's internal mail server delivering to the MDA).

Sample Header Trace (Read from Bottom to Top):

[Hop 3 - Top / Final Hop]
Received: from mail-relay.victim.com (10.0.0.15) by mailbox01.victim.com (10.0.0.50)
 with ESMTP id 987654; Tue, 22 Sep 2026 18:32:05 +0000
      ▲
      │  (Delivered internally to recipient mailbox)
[Hop 2 - Middle Hop / Perimeter Boundary]
Received: from mail.attacker-vps.com (198.51.100.88) by mail-relay.victim.com (10.0.0.15)
 with ESMTPS id 456789; Tue, 22 Sep 2026 18:32:02 +0000
      ▲
      │  (First authenticated external receiving point!)
[Hop 1 - Bottom Hop / Potential Injected Header]
Received: from [192.168.1.100] (account-exec [10.20.30.40]) by mail.legitimate.com
 with ESMTP id 123456; Tue, 22 Sep 2026 14:31:55 -0400

Identifying Spoofed Received: Headers

Adversaries frequently insert fabricated Received: headers into the message body before transmitting it to simulate a legitimate route.

• The Golden Anchor: An attacker cannot forge the Received: header stamped by the victim's own receiving gateway server (Hop 2 above). The victim's perimeter MTA independently queries the TCP socket connection and records the connecting IP address (198.51.100.88). Any Received: headers located below that gateway entry must be corroborated against public DNS records, reverse pointer (PTR) records, and authentication results to verify validity.

---

Anti-Spoofing & Authentication Frameworks: SPF, DKIM & DMARC

+-------------------------------------------------------------------------+
|               EMAIL AUTHENTICATION FRAMEWORKS COMPARISON                |
+-------------------------------------------------------------------------+
| Framework | What It Validates        | Cryptographic? | DNS Record Type |
|-----------|--------------------------|----------------|-----------------|
| **SPF**   | Connecting MTA IP against| No (IP-based   | TXT record on   |
|           | authorized IP list       | authorization) | sender domain   |
| **DKIM**  | Message integrity of     | Yes (RSA/Ed25519| TXT record on   |
|           | headers and body         | keypair)       | <sel>._domainkey|
| **DMARC** | Domain alignment between | Relies on SPF  | TXT record on   |
|           | From: and SPF/DKIM;      | and DKIM       | _dmarc.<domain> |
|           | defines policy (reject)  | signatures     |                 |
+-------------------------------------------------------------------------+

1. Sender Policy Framework (SPF - RFC 7208)

SPF allows domain owners to publish a list of IP addresses or subnets authorized to send email on behalf of their domain.

example.com.  IN  TXT  "v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all"

Breakdown of SPF Elements:

• v=spf1: Identifies the SPF version.
• Mechanisms: Evaluated from left to right:
  • ip4 / ip6: Explicit IPv4 or IPv6 network ranges authorized to send.
  • a: Authorizes the IP address resolved by the domain's A record.
  • mx: Authorizes all IP addresses resolved by the domain's MX records.
  • include:<domain>: Imports another domain's SPF record (e.g., Google Workspace).
• Qualifiers: Determine the disposition if a mechanism matches:
  • + (Pass): Default; authorized sender.
  • - (Fail / HardFail): Explicitly unauthorized; server should reject.
  • ~ (SoftFail): Suspect; message accepted but tagged as spam/junk.
  • ? (Neutral): No policy stated; treat as unauthenticated.

2. DomainKeys Identified Mail (DKIM - RFC 6376)

DKIM provides asymmetric cryptographic verification of email integrity and authenticity.

1. Signing: The sending MTA calculates a cryptographic hash of selected headers (h=) and the canonicalized body (bh=). It encrypts this hash using its private key, embedding the result into the DKIM-Signature: header (b=).
2. Verification: The receiving MTA extracts the domain (d=) and selector (s=) from the header, queries DNS for the public key located at <selector>._domainkey.<domain>, and decrypts the signature to verify that neither headers nor body were tampered with in transit.

Sample DKIM-Signature Header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=company.com; s=s202601;
 h=from:to:subject:date:message-id;
 bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
 b=d2VvcmtpbmcgZGtp bSBzaWduYXR1cmUgYnl0ZXMgZXhhbXBsZQ==

3. Domain-based Message Authentication, Reporting & Conformance (DMARC - RFC 7489)

SPF and DKIM alone have a fatal architectural flaw: neither binds authentication to the visible RFC 5322 From: header. An attacker can transmit an email with an authentic SPF pass for evil.com, but present ceo@victim.com in the visible From: header.

DMARC resolves this by enforcing Domain Alignment:

• The domain in the visible From: header must match the domain authenticated by SPF (Envelope MAIL FROM:) and/or the DKIM signing domain (d=).

_dmarc.company.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-rua@company.com; aspf=r; adkim=r"

Core DMARC Directives:

• v=DMARC1: Protocol identifier.
• p=<policy>: Action required if authentication/alignment fails:
  • p=none: Monitor only; deliver normally and generate forensic reports.
  • p=quarantine: Route failing messages to Spam/Junk folder.
  • p=reject: Completely drop/reject the message at the SMTP gateway.
• sp=<policy>: Subdomain policy (inherits p= if unspecified).
• pct=<percent>: Percentage of failing messages subject to policy (100 = 100%).
• rua=mailto:...: Aggregate reporting destination for daily XML statistics.
• aspf= / adkim=: Alignment mode: r (Relaxed - subdomains align) or s (Strict - exact domain match required).

---

Email Client Storage & Artifact Extraction

When investigating endpoint workstations, email evidence resides within proprietary database containers or plain-text spool files.

+-------------------------------------------------------------------------+
|               EMAIL CLIENT STORAGE CONTAINER ARTIFACTS                  |
+-------------------------------------------------------------------------+
| File Format | Typical Storage Location      | Architecture & Contents   |
|-------------|-------------------------------|---------------------------|
| **PST**     | %LocalAppData%\Microsoft\     | Standalone database;      |
| (Personal   | Outlook\*.pst                 | POP3 mail, local archives,|
| Storage)    |                               | contacts, calendar items  |
| **OST**     | %LocalAppData%\Microsoft\     | Offline synchronization   |
| (Offline    | Outlook\*.ost                 | cache for Exchange/O365/  |
| Storage)    |                               | IMAP; includes deletions  |
| **Mbox**    | /var/mail/[user] or           | Flat ASCII text file;     |
|             | ~/.thunderbird/[prof]/Mail    | concatenated RFC 5322     |
|             |                               | messages separated by 'From '|
| **EML**     | Individual files              | Single raw RFC 5322 email |
| **MSG**     | Individual files              | Microsoft OLE structured  |
|             |                               | compound storage container|
+-------------------------------------------------------------------------+

1. Outlook PST vs. OST Forensics

• PST Files: Contain user folders, email messages, attachments, contacts, and calendar schedules. When a user deletes an email in Outlook, the MAPI record is unindexed but the raw data remains in unallocated blocks within the PST file until compaction occurs. Forensic tools (FTK, EnCase, readpst) can carve deleted records directly from PST containers.
• OST Files: Function as an offline cache. Unlike PSTs, OST files cannot be directly opened by another Outlook installation due to internal MAPI encryption ties to the original Active Directory user SID. Investigators utilize commercial forensic tools (e.g., Kernel for OST to PST) to convert orphaned OST files into readable PST structures.
• Outlook Encryption Options: Outlook files use Compressible Encryption (default; simple byte substitution, easily cracked) or High Encryption (AES / 3DES encryption requiring the user password).

2. Unix Mbox Architecture

In Unix and Linux systems, mail spools reside in /var/mail/ or /var/spool/mail/. An Mbox file is a single monolithic text file where individual messages are concatenated sequentially. Each message begins with a line starting with From (followed by the envelope sender and a delivery timestamp). Investigators carve individual messages using utilities like formail, awk, or Python's mailbox module.

---

Phishing, Spear-Phishing & Business Email Compromise (BEC)

Business Email Compromise (BEC) Typologies

In BEC attacks, adversaries bypass perimeter defenses without using malware, relying instead on social engineering, display name spoofing, or compromised legitimate accounts:

1. Executive Impersonation (CEO Fraud): Attacker registers lookalike domains (typosquatting, e.g., examp1e.com instead of example.com) or utilizes display name spoofing to order urgent wire transfers.
2. Vendor Invoice Fraud: Threat actor compromises an external supplier's email account, monitors communication threads, and injects updated bank wire routing numbers into legitimate ongoing invoice discussions.

Mailbox Forwarding Rule Forensics

Once an adversary compromises an enterprise Microsoft 365 or Exchange account, they establish persistence by creating automated inbox forwarding rules:

• Rules are configured to move incoming emails matching terms like "invoice", "wire", "fraud", or "confidential" directly to the RSS Feeds or Deleted Items folder.
• An automatic forwarding rule sends a copy to an external adversary-controlled email address (attacker@proton.me).

# Exchange Online PowerShell: Audit all inbox rules across enterprise mailboxes
Get-Mailbox -ResultSize Unlimited | Get-InboxRule | Select-Object MailboxOwnerId, Name, Description, ForwardTo, MoveToFolder

# Audit tenant-level external forwarding configurations
Get-TransportRule | Where-Object { $_.BlindCopyTo -ne $null -or $_.RedirectMessageTo -ne $null }