ProofRelaySomeone replied inside our email thread asking for payment. Is it real?
A conversation has been running for days or weeks. A job, a quote, a settlement, a progress claim. Several people are on it. Then a message arrives in that same thread, from a name you recognise, with the history quoted underneath — and it asks for payment to an account you have not used before.
This is thread hijacking, and it is the version of payment fraud that most often gets through. Not because the people involved are careless, but because every instinct we use to judge an email has already been satisfied before the request is even read.
There are two quite different attacks that both look like this, and they are worth separating, because one of them leaves a mark you can find and the other does not.
Why a thread feels like proof, and is not
Context does most of the work in deciding whether a message is genuine. The subject line matches something real. The history below the message is real, because it was copied from a real exchange. The names are people you have actually been dealing with. The amount is roughly what you expected, at roughly the time you expected it.
None of that is evidence about the bank account. Every one of those signals can be reproduced by someone who has read the conversation, and reading the conversation is the easy part — it only requires access to any single mailbox among everyone on the thread, or to a forwarded copy that reached somewhere less protected.
The request to change an account is the only part that matters, and it is the only part the thread cannot vouch for.
The thread proves someone had access to the conversation. It does not prove who is asking, and it says nothing about where the money should go.
Variant one: a near-copy domain injected into the thread
The attacker is outside. They have seen the conversation — often because it was forwarded to a wider group, or because one participant's mailbox was reached — and they register a domain that reads like one of the real parties. Then they send a message that appears to continue the thread.
The substitutions are chosen to survive a quick read rather than a careful one. "rn" in place of "m". A doubled letter in the middle of a long word. A hyphen added or removed. The same name under .com instead of .com.au. In a reply-chain, in a small font, on a phone, none of these are noticeable — and nobody is looking, because the conversation is already established.
Often the reply-to address points somewhere else again, so that your answer goes to the attacker even though the message appears to come from the supplier.
- The sender's domain is not quite the domain you have corresponded with before.
- Replies are addressed to a different domain than the message came from.
- The message is a reply, but the participant list has quietly changed — someone added, someone dropped.
- It arrives at a moment when a payment was genuinely expected.
Variant two: a real mailbox, genuinely compromised
Here the attacker is inside. They have credentials to a mailbox belonging to one of the participants, and they reply from the genuine address, in the genuine thread, at a moment they have chosen by reading the conversation.
There is no lookalike domain, because there is no impersonation. The address is correct. The signature is correct. The history is correct. Mail authentication passes, because the mail is authentic.
This is the variant nobody can detect by examining the message, and it is worth saying plainly rather than pretending otherwise: no checking tool, including ours, can tell you this message is fake. The only thing that establishes the account is contact through a channel the mailbox does not control.
There is one thing still worth looking at, though it proves nothing on its own. The money has to arrive somewhere the attacker controls, and that account is often not in the supplier's name. If the invoice states an account name, check whether it is actually the business you are paying. A personal name, or a company you have never heard of, is worth a question — and it is the same comparison your bank now performs when you enter a payee.
If someone is inside a real mailbox, the email is genuine in every way you can test. Reading it more carefully cannot help. A phone call to a number you already had can.
Which one you can actually check
The first variant leaves evidence: the sender's domain is not the domain you have on record. That comparison is mechanical and reliable, and it is worth doing every time, because it is the more common of the two and it costs seconds.
You can do it by hand — open an older message from that supplier, one you are confident predates this conversation, and compare the address character by character rather than by eye. Or paste the message into a checker that compares it against the domain you know.
The second variant leaves nothing. Which is exactly why the process below does not depend on the check succeeding.
What to do, regardless of which one it is
- Do not reply in the thread. A reply reaches whoever controls that mailbox — which, in the case that matters, is the attacker, and they will confirm the details happily.
- Do not call a number from the message, the signature, or an attached document. All three were chosen by whoever sent it.
- Find a number you already had: an earlier invoice, a signed contract, their website that you navigated to yourself, or your own records.
- Ring the supplier and ask them to state the BSB and account number, rather than reading yours out for confirmation. If you read first, you invite a 'yes, that's right' from someone who may not be who you think.
- Compare what they said to what the message asked for. If it differs, or you cannot reach them, do not pay.
- Have someone other than you release the payment. The attacker has persuaded one person; a second set of eyes is the control they cannot easily defeat.
If it has already been paid
Call your bank immediately and ask them to attempt a recall — speed matters more than anything else, because the money is usually moved on within hours. Then report it to ReportCyber (cyber.gov.au) and to Scamwatch.
Tell the other parties on the thread. If a mailbox is compromised, everyone in that conversation is exposed, and they will not know unless someone says so.
Common questions
The email came from the correct address. Doesn't that prove it's genuine?
It proves the message was sent from that mailbox, which is not the same as proving the account holder sent it. In a mailbox-compromise attack the address is genuinely correct — that is the whole difficulty. Address authenticity tells you nothing about whether the bank details are right.
Wouldn't SPF, DKIM or DMARC catch this?
They catch forged senders, which helps against the lookalike-domain variant only in the sense that the attacker uses a domain they genuinely own and authenticate correctly. Against a compromised mailbox they pass completely, because the mail really was sent by that server. Passing authentication is not evidence about the payment.
How did they get into the thread in the first place?
Usually through the least protected participant rather than the largest one — a small supplier, a contractor, a personal address someone was copied on. It is often not your systems or your supplier's, but a third party on the same conversation.
Should I tell the other people on the thread?
Yes, and by a channel other than that thread. If a mailbox is compromised, a warning sent into the conversation is read by the attacker before it is read by anyone else.
Is a small change to bank details less suspicious than a big one?
No. The size of the change is chosen by the attacker and says nothing about legitimacy. A change from one Australian account to another Australian account is the common case, precisely because it looks unremarkable.
Related guides
- Is this invoice a scam? Seven checks before you pay
The seven things worth checking on an invoice that doesn't feel right, and the one check that actually settles it.
- A supplier emailed new bank details. What should you do?
The single most common way businesses lose large sums — and a short, repeatable process that stops it.
- You've paid a scammer. What to do in the first hour
If money has already gone, speed decides the outcome. The order of operations that gives you the best chance.