VI-03 · Email forensics

Reading the records behind a redirected-payment email

A supplier payment went to the wrong account after an emailed instruction. Headers, authentication results and audit logs show whether the sender was genuine.

Synthetic case for educational use. Organisations, people, numbers and hashes are invented.

01The question

Did the payment-change email genuinely originate from the supplier's mailbox, and is there evidence that a rule in the finance mailbox hid the supplier's later replies?

02Background

A fictional firm, Delta Lojistik, paid an invoice to a changed bank account after receiving an email that appeared to come from a known supplier. Message exports and mailbox audit logs were provided with the account holders' consent. The examination reads the records; it does not describe how any account might be accessed.

03Constraints

  • Only exported messages and provider audit logs were available, not the mail servers themselves.
  • Header interpretation depends on the receiving provider having recorded authentication results.

04Evidence received

ItemFormHashNote
Original payment-change message in .eml with full headersF-02sha256: 7c3a…11fdExported with headers intact; hashed on receipt.
Mailbox audit log export for the finance mailboxF-05sha256: bd60…9a4eProvided under a preservation notice with the account holder's consent.

05Examination method

  1. Read the full header chain

    The Received chain was read from bottom to top to establish the path and the originating server. The From, Reply-To and Return-Path were compared; a Reply-To that differed from the display sender was noted. Message-ID and the sending domain were recorded.

  2. Check authentication results

    The Authentication-Results header recorded by the receiving provider gave SPF, DKIM and DMARC outcomes. DKIM alignment was checked against the From domain; an SPF pass for a look-alike domain is not an SPF pass for the real one. Results were recorded exactly as the provider wrote them.

  3. Compare the look-alike domain against the genuine one

    The sending domain was compared character by character with the supplier's real domain. A substituted character and a different registration were recorded. The genuine prior correspondence from the supplier was used as a reference for the real domain and headers.

  4. Read the mailbox audit log for rules and access

    The finance mailbox's audit log was read for inbox-rule creation and for mail-item access. An inbox rule that moved messages from the supplier's genuine domain to a rarely used folder was recorded with its creation time. Each audit entry was tied to its UTC timestamp and kept with its raw log line.

    Local time to UTCTimestamp decoder

06Findings

  • Established

    The payment-change email did not come from the supplier's genuine domain; it came from a look-alike domain and failed DMARC alignment at the receiving provider.

    BasisHeader chain, sending domain and the provider's Authentication-Results agree.

  • Probable

    An inbox rule in the finance mailbox moved genuine supplier replies out of the inbox during the relevant period.

    BasisThe audit log records the rule's creation and criteria; message movement is consistent, but the log's completeness depends on the provider's retention.

07Limits

  • Email authentication shows alignment and delivery path, not the identity of the person who sent a message.
  • Audit-log completeness depends on the provider's retention and on auditing having been enabled.
  • The examination does not trace the destination bank account; that is a financial-investigation step outside this scope.

08Report excerpt

The message's From domain differs from the supplier's genuine domain by one substituted character and failed DMARC (dmarc=fail) in the provider's Authentication-Results. A finance-mailbox inbox rule created on 2026-… moved mail from the genuine domain to a seldom-opened folder. We state the rule's effect as probable because log retention bounds what we can see.

09Lessons

  • Record authentication results exactly as the receiving provider wrote them; do not re-derive them.
  • A look-alike domain can pass its own SPF; alignment to the real From domain is what matters.
  • Mailbox rules are a common way genuine replies are hidden; read the audit log for rule creation.

10Sources

  1. RFC 7208 — Sender Policy Framework (SPF)
  2. RFC 6376 — DomainKeys Identified Mail (DKIM)
  3. RFC 7489 — Domain-based Message Authentication (DMARC)