What this analysis does
Mailybox compares a known earlier message with a later message from the conversation, then scores material changes across the visible From identity, display name, Reply-To, Return-Path, DKIM signing domain, Message-ID domain and receiver-stamped authentication. Payment and urgency language is treated only as context, never as proof of fraud.
Conversation hijacking works because the thread is real. An attacker with visibility into an existing exchange continues it at the moment a payment or credential decision is due, and the recipient evaluates the message against a conversation they genuinely recognize.
Compare two messages from the same thread
A single message offers little to judge. The analysis compares a message known to be legitimate against the one in question, and reports what changed between them: the sending domain, the envelope sender, the DKIM signing domain, the reply path and the infrastructure in the route.
Change in any of those is not proof of compromise, because platforms and routing legitimately change over time. The signal worth acting on is change that appears precisely when the conversation turns to payment, credentials or a delivery address.
- Compare a known-good message against the suspect one.
- Identity changes matter most when they coincide with a financial request.
- Legitimate infrastructure changes do occur and must be considered.
The patterns that recur
A Reply-To pointing somewhere other than the From domain is the most common, since it lets an attacker read replies without controlling the original mailbox. A lookalike domain substituted mid-thread is the second, relying on the recipient reading the address quickly.
The hardest case is a genuinely compromised mailbox, where every authentication check passes because the mail really does originate from the legitimate account. Only behavioural signals remain: an unexplained change in tone, an unusual request, urgency that discourages verification, or a change in the infrastructure that account normally sends through.
Verification has to be out of band
No header analysis substitutes for confirming a payment change through an independently known channel. Call a number from your own records — never one supplied in the message — and confirm with a person you can identify.
This is a process control rather than a technical one, and it works even against a fully compromised mailbox where every authentication signal is genuine. Organizations that require it for every payment-detail change are the ones that avoid this loss category.
Work through a payment-change verificationReconstruct the full thread timeline
Example: a reply path introduced mid-thread
Evidence supplied
An early message from the counterparty and a later message requesting updated bank details.
How to read the result
The comparison reports that the From domain is unchanged while a Reply-To pointing at an unrelated domain appears only in the later message. That change, coinciding with a payment request, is the finding that warrants out-of-band verification.
Known limits
- A compromised legitimate mailbox produces passing authentication and no identity change.
- Legitimate platform migrations can produce identity changes that resemble the pattern.
- Analysis is bounded by the two messages supplied and does not observe the wider thread.
Common questions
Everything authenticates. Is the message safe?
Not necessarily. A compromised account sends genuinely authenticated mail. Authentication establishes origin, not intent.
Which two messages should I compare?
The most recent message you are confident was legitimate, and the message in question. Both as complete originals rather than forwarded copies.
What is the single most effective control?
Mandatory out-of-band verification for any change to payment details, using contact information from your own records.