What this analysis does
Mailybox combines conversation-identity forensics with an explicit out-of-band verification gate. It never asks for bank account numbers and never treats email authentication as payment authorization; instead it shows whether sender evidence changed and whether the request was confirmed through a trusted contact method sourced outside the disputed thread.
A request to change payment details arriving by email is the single highest-value fraud pattern in ordinary business correspondence. It works because the request is plausible, the thread is often genuine, and the process for verifying it is usually informal.
Technical evidence first, but it is not decisive
Compare the request against earlier correspondence from the same counterparty. Changes in the sending domain, the reply path, the signing domain or the route are meaningful, particularly when they appear for the first time in the message that asks for new details.
Absence of any change is not clearance. When a mailbox is genuinely compromised, every technical signal matches the legitimate baseline exactly, because the mail is legitimate in every respect except intent.
- Compare against earlier messages from the same counterparty.
- A first-time reply path change alongside a payment request is a strong signal.
- Matching technical evidence does not rule out a compromised mailbox.
Out-of-band verification is the control that works
Confirm the change by voice with a person you can identify, using a number from your own records — never a number supplied in the message or in an attached document. Attackers include their own contact details precisely because they expect verification to be attempted.
This works against a fully compromised mailbox, which is what makes it the only control that covers the hardest case. It is also the step most often skipped under time pressure, which is why urgency is a standard element of these requests.
Make it a process, not a judgement call
Individual vigilance fails under pressure. Organizations that avoid this loss category require verification for every payment-detail change without exception, so no individual has to decide whether a particular message warrants it.
Support the rule with a small number of practical controls: a documented callback procedure using stored numbers, dual authorization above a threshold, a delay before the first payment to changed details, and explicit permission for staff to hold a payment while verifying.
Check for lookalike counterparty domainsReconstruct the thread if fraud is suspected
Example: a plausible request with one change
Evidence supplied
A payment-detail change referencing a real invoice number, from the expected From domain, with a Reply-To that appears for the first time.
How to read the result
The verification reports the new reply path as the material change and identifies the correct invoice reference as consistent with thread visibility rather than as evidence of legitimacy. Out-of-band confirmation is required before acting.
Known limits
- A compromised legitimate mailbox produces no detectable technical anomaly.
- Analysis covers the evidence supplied and cannot verify the underlying business relationship.
- No technical check substitutes for out-of-band confirmation.
Common questions
The message came from the correct address. Is it safe?
No. That is consistent with a compromised mailbox. Verify by voice using a number from your own records.
Can I call the number in the email signature?
No. Attackers control the entire message including the signature. Use contact details you already hold independently.
What if payment has already been sent?
Contact your bank immediately to attempt recall and report it to law enforcement. Recovery depends heavily on speed.