What this analysis does
Paste a sequence of raw message headers separated by a clear boundary. Mailybox extracts dates, sender identities, signing domains, Message-ID domains and receiver authentication, orders parseable timestamps, compares each adjacent message and highlights the highest-risk identity transition without claiming that a stable identity proves safety.
An email incident is rarely explained by one message. It is explained by the point in a sequence where the evidence changed. Ordering a set of messages chronologically and tracking identity across them locates that transition precisely.
Order by received evidence, not by client display
Client display order reflects local sorting and can be manipulated by a supplied Date header, which is written by the sender. The reliable ordering comes from the Received chain, where each timestamp was added by a system that handled the message.
Once ordered, the timeline tracks the identity fields across every message: From domain, envelope sender, signing domain, reply path and route. Stability across the sequence is the baseline, and the message where that stability ends is the transition point.
- The Date header is sender-supplied and can be false.
- Received timestamps are added by handling systems.
- The transition is located by comparing identity across the ordered sequence.
Distinguish the transition from the request
The message containing the fraudulent request is usually not the message where the compromise began. Attackers commonly observe a thread for a period before acting, so the identity change frequently precedes the financial request by several messages.
Establishing that gap matters for the response. It defines how long the attacker had visibility, which other conversations may have been observed, and which additional parties need to be notified.
Compare two messages in detailRead the timeline reconstruction guide
Preserve evidence before analyzing it
Collect complete original messages rather than forwarded copies, because forwarding discards the original headers that the entire reconstruction depends on. Most clients provide a save or download original function for exactly this purpose.
Hash each file at collection and record the hashes before analysis begins. If the incident becomes a formal matter, that record is what demonstrates the files examined later are the files that were collected.
Example: a change three messages before the request
Evidence supplied
Nine messages from a thread that ended with a request to change payment details.
How to read the result
The timeline orders the messages by received evidence and reports that the reply path changed at the sixth message, three before the request. That interval defines the window during which the conversation was observed.
Known limits
- Reconstruction is bounded by the messages supplied; a missing message can hide the transition.
- Forwarded copies lack the original headers the analysis depends on.
- Clock differences between systems produce small timing inconsistencies that are normal.
Common questions
How many messages are needed?
Enough to include a period before the suspected transition. A sequence that begins at the fraudulent request cannot show where the identity actually changed.
Can forwarded messages be used?
Poorly. Forwarding replaces the headers the reconstruction relies on. Use saved originals wherever possible.
Should law enforcement be contacted?
For financial loss, promptly — recovery of transferred funds depends heavily on how quickly it is reported. Preserve the original files as collected.