Thread hijacking email attacks

17 March 2026 · 14 min read

Thread hijacking is the email attack that gets past people who think they are too careful to be phished. There is no urgent invoice from a stranger, no badly spelled lottery win, no lookalike domain you can spot if you squint. Instead, a reply lands in a conversation you started, quoting the message you actually sent, continuing a discussion you genuinely had, from a sender who appears to be the colleague or supplier you were already talking to. You reply on autopilot, because everything about the thread says it is real. That is the whole point of the technique, and it is why thread hijacking has become one of the most reliable delivery mechanisms for malware and invoice fraud over the past few years.

This article is specifically about thread hijacking: how attackers obtain a real conversation, the two structurally different ways they continue it, exactly where email authentication stops the attack cold, and exactly where DMARC, SPF and DKIM are powerless because the mail is not even forged. If you finish this understanding that "we have DMARC at p=reject" is a partial answer rather than a complete one, the article has done its job.

What thread hijacking actually is

A thread hijack is a phishing message that injects itself into an existing, legitimate email conversation. The attacker is not starting a cold approach. They are continuing a thread that already exists, complete with the original subject line (usually carrying a chain of Re: or Fwd: prefixes), the quoted history of earlier messages, and the social context of a relationship that is already warm.

That context is what defeats the usual advice. We tell people to be suspicious of unexpected messages, unfamiliar senders and out-of-the-blue requests. A hijacked thread is none of those things. It is expected, the sender is familiar, and the request follows naturally from a discussion that was already happening. The recipient's guard is down before the malicious content arrives, because the brain has already classified the thread as trusted.

Two things have to happen for a thread hijack to work:

The attacker must get hold of a real conversation, including its content and headers.
The attacker must continue that conversation in a way that reaches the target and looks like it came from the expected party.

Step one is almost always an account compromise or a mailbox breach somewhere in the chain. Step two is where the attack splits into two very different techniques, and where authentication does or does not bite. Keep that split in mind, because most confusion about "does DMARC stop this?" comes from collapsing the two cases into one.

How the attacker gets the conversation in the first place

You cannot hijack a thread you have never seen. The raw material, the real subject, the real quoted history, the real participant names, has to come from somewhere. There are a few common routes.

Direct mailbox compromise. The most common source. An employee's credentials are phished, reused from a breach, or stolen by an info-stealer on their device. The attacker logs into the mailbox (or its OAuth-connected apps) and reads everything: sent items, inbox, the lot. They now have months of real threads to choose from.
A compromised party further down the chain. It does not have to be your mailbox. If your supplier, your client, your accountant or your lawyer is breached, every conversation you have had with them is now in the attacker's hands, including your own messages quoted inside the thread. This is why a hijack can target you using a thread you and a trusted partner genuinely exchanged, even though your own systems were never touched.
Malware that exfiltrates mailbox data. Several malware families (the Emotet lineage made this notorious, and others have copied it) specifically harvest email content and address books from infected machines, then feed real threads back into spam runs. The hijacked replies are generated at scale, automatically, from stolen conversations.
Open or misconfigured archives. Less common, but exposed mail archives, misconfigured shared mailboxes, leaked backups and mis-shared inboxes occasionally hand over conversation history without any account login at all.

The key insight: thread hijacking is downstream of a compromise, usually somebody else's. By the time the malicious reply reaches your inbox, the attacker already knows what you said, who you said it to, and what tone to imitate. That is a content problem and an account-security problem first. Email authentication enters the story only at the next step, the delivery of the reply, and how much it helps depends entirely on which delivery technique the attacker chose.

The two delivery techniques (and this is the part that matters)

Technique A: send from a spoofed or lookalike sender

In the first variant, the attacker does not control the real mailbox at the moment of sending. They have the conversation (perhaps from a breach elsewhere, perhaps from malware), but they are firing the malicious reply from their own infrastructure while pretending to be the legitimate participant.

To make the reply look right, they have to put a convincing address in the visible From header. They have a few options, and they vary enormously in how easy they are to stop:

Exact-domain spoofing. Put the real domain in the From header (finance@realsupplier.com) and send from a server that has no authority over that domain. This is the classic forgery DMARC was designed to kill.
Lookalike or cousin domains. Register real-supplier.com, realsuppllier.com, realsupplier.co or an internationalised homoglyph, and send a perfectly authenticated message from that. The domain is not yours, so it passes its own authentication cleanly.
Display-name spoofing. Leave the actual address as some throwaway mailbox but set the display name to "Jane Smith (Real Supplier)". Many mail clients, especially on mobile, show only the name.
Reply-To trickery. Authenticate as a benign domain but set Reply-To: to an attacker mailbox, so the conversation quietly continues off to the side.

This is where email authentication does real work, but only against the first option. When the attacker spoofs the exact domain, DMARC is exactly the control that catches it. If realsupplier.com publishes p=reject with aligned SPF or DKIM, a message that puts realsupplier.com in the From header but cannot produce an aligned, passing signature is rejected outright at the receiving server. The hijacked reply never reaches the inbox. That is the core promise of getting a domain to enforcement, and it is genuine: exact-domain thread hijacking against a protected domain simply fails.

The other three options route around authentication rather than breaking it, and that gap is the whole reason this article exists. We will come back to it.

Technique B: send from the genuine, compromised account

In the second variant, the attacker is not pretending to be the participant. They are the participant, as far as the mail system is concerned, because they have logged into the real mailbox and are sending the reply from inside it.

Think about what that means for authentication. The message leaves the legitimate provider's own outbound servers. It is signed with the domain's real DKIM key. It passes SPF for the domain's real sending infrastructure. The From header contains the real, owned domain because it is the real domain. Every authentication check passes, because nothing has been forged. The mail is authentically from the account; it is just being sent by a criminal who controls that account.

No DMARC policy stops this, because DMARC is not designed to. DMARC answers one question: "is this message authorised to use this domain in the From header?" When the message genuinely originates from the domain's own authenticated infrastructure, the honest answer is yes. Authentication verifies the channel, not the intent of the human (or script) at the keyboard. A compromised account is a trusted channel carrying hostile content, and that is invisible to SPF, DKIM and DMARC by design.

This is the single most important thing to take away. Authentication proves a message used your domain legitimately. It does not prove the person sending it should be trusted. Account-based thread hijacking lives entirely in that gap.

Where authentication helps, precisely

Be precise about the win, because overstating it is how organisations end up complacent. DMARC, SPF and DKIM at enforcement stop thread hijacks that rely on exact-domain spoofing of a domain you control.

Concretely, with your own domain at p=reject and alignment correctly configured:

An attacker who harvested your threads from a partner breach and tries to reply as you (you@yourdomain.com) from their own server is rejected. They cannot forge your domain into the From header and survive the DMARC check.
An attacker who tries to inject a malicious reply into an internal thread by spoofing a colleague's exact internal address is rejected, assuming the internal domain enforces and receiving systems honour the policy.
Receivers also stop treating your domain as a free spoofing target generally, which removes one whole category of hijack delivery against your brand.

You can confirm your domain is actually at that level, rather than stuck at p=none where nothing is enforced, with the DMARC checker, and verify the underlying mechanics with the SPF checker and DKIM checker. If your domain is not yet enforcing, reaching p=reject without breaking email and the enforcement journey walk through doing it safely. Sitting at p=none is the trap the false security of p=none describes: you have reports but no protection, and an exact-domain hijack still lands.

A subtle point that matters for hijacking specifically: alignment is what makes this real. A message can pass SPF or DKIM for some other domain and still be a forgery of yours. DMARC only counts a pass when the authenticated domain aligns with the From domain. If you are unsure why a message that "passed SPF" still failed DMARC, DMARC alignment explained and SPF versus DKIM, which one aligns cover the mechanism that does the protecting here.

Where authentication does not help, precisely

Now the uncomfortable half. Authentication does nothing against the following, and each is a live thread-hijacking technique in the wild.

Compromised legitimate accounts

Covered above, and worth repeating because it is the most damaging case. If the attacker is sending from the genuine mailbox, the mail is genuinely authenticated. DMARC, SPF, DKIM and even BIMI all pass. Your verified brand logo may even appear next to a fraudulent reply, because the message really did come from the domain entitled to display it. No authentication control addresses a stolen-but-valid credential. This is the realm of multi-factor authentication, session and token monitoring, impossible-travel detection, and behavioural analysis, not DNS records.

Lookalike and cousin domains

If the attacker registers yourcompany-billing.com or yourc0mpany.com and stands up correct SPF, DKIM and DMARC for that domain, every authentication check passes, because the attacker genuinely owns the domain they are authenticating. Your DMARC policy protects the From header of your domain. It says nothing about a different domain that merely resembles yours. A hijacked reply from a cousin domain is fully authenticated and fully malicious at the same time. Watching for these is a monitoring problem; the lookalike domain checker exists for exactly this reconnaissance.

Display-name spoofing

The From address might be random12345@gmail.com, but the display name reads "Jane Smith, Acme Finance". DMARC validates the domain in the address, not the friendly name shown to the user. On a phone, where the address is often hidden entirely behind the name, this is brutally effective and authentication never gets a chance to matter, because the underlying gmail.com message is itself perfectly authentic.

Reply-To and conversation diversion

The visible, authenticated sender can be benign while Reply-To: quietly points at an attacker-controlled mailbox. The first message passes every check; the danger is in where your reply goes. Authentication has no opinion about the Reply-To header.

Forwarded and relayed hops

Thread hijacking often rides through forwarders, mailing lists and relays, where SPF breaks and DKIM signatures sometimes break too. Attackers know that messages arriving via a forwarder already look "a bit off" to authentication, which muddies the signal receivers use. The mechanics of why legitimate forwarded mail fails are in forwarding and DMARC and DKIM alignment and forwarding; the relevant point for hijacking is that the forwarding grey area gives malicious mail cover.

The honest summary: authentication closes the exact-domain-spoofing door firmly, and attackers respond by walking through one of the doors it does not control. A mature thread-hijacking campaign assumes the target enforces DMARC and is built specifically to avoid needing to forge the protected domain.

A worked example

Picture a genuine thread between your finance team and a supplier about an outstanding invoice. The real exchange exists; both sides have it in their mailboxes.

The supplier's mailbox is compromised by an info-stealer. The attacker reads the thread and decides to hijack it. Here is the same hijack delivered two ways.

Delivered via the compromised supplier mailbox (Technique B):

From:       accounts@realsupplier.com   (the genuine, owned address)
Subject:    Re: Invoice 4471 - payment confirmation
DKIM:       pass   (d=realsupplier.com, the real signing key)
SPF:        pass   (sent from realsupplier.com's real outbound servers)
DMARC:      pass   (aligned, p=reject would still deliver this)
Body:       quoted real history + "We have changed bank, please
            use the new account details below for this invoice."

Every check is green. The bank-change request is fraud, but nothing in the authentication layer can tell you so, because nothing is forged. Your DMARC policy waves it straight through, correctly, on its own terms.

Delivered via spoofing from attacker infrastructure (Technique A, exact-domain):

From:       accounts@realsupplier.com   (forged into the header)
Subject:    Re: Invoice 4471 - payment confirmation
DKIM:       fail / none   (attacker has no valid key for the domain)
SPF:        fail          (attacker's server is not authorised)
DMARC:      fail -> rejected if realsupplier.com publishes p=reject

Here authentication does its job and the hijack is rejected before delivery. Same stolen thread, same fraudulent intent, completely different outcome, decided entirely by whether the attacker forged a protected domain or sent from a channel that did not need forging. The difference between the two rows is the difference between what DMARC protects and what it cannot touch.

Defences that actually address thread hijacking

Because the attack spans authentication, account security and human process, the defence has to as well. Treat the following as layers, not alternatives.

Layer 1: close the exact-domain door (authentication at enforcement)

Get every sending domain and every parked, non-sending domain to p=reject with aligned SPF and DKIM. This eliminates the cheapest hijack variant and stops your domains being used to attack your own people, partners and customers. Do not forget parked domains: an attacker will happily hijack a thread "from" a brand domain you never send mail from, precisely because nobody protected it. Confirm coverage with the DMARC checker, and if you want this driven to enforcement safely without an outage, that is exactly what the done-for-you DMARC service does.

Layer 2: protect the accounts (the Technique B defence)

Authentication cannot save you from a stolen-but-valid login, so the account itself has to be hard to take over.

Enforce phishing-resistant multi-factor authentication (security keys or passkeys, not SMS) on every mailbox.
Monitor for impossible-travel logins, new OAuth grants and unusual outbound volume.
Kill credential reuse and run device hygiene against info-stealers, since that is the most common harvesting route.
Treat any partner's compromise as your problem too, because their stolen threads target you.

Layer 3: read the reports (catch the spoofing attempts)

DMARC aggregate reports show you exactly where someone is trying to forge your domain, including hijack reconnaissance, before a campaign matures. Unfamiliar sources failing authentication for your domain are the early warning. Reading your first DMARC report and the DMARC report analyzer turn the raw XML into something you can triage; DMARC reports show unknown sources helps you sort genuine senders from forgery attempts.

Layer 4: watch the perimeter you do not own (lookalikes and brand abuse)

Authentication protects your domain, not domains that resemble it. Monitor for newly registered cousin domains and homoglyph variants with the lookalike domain checker, and use the spoofing risk calculator to gauge how exposed a given domain is before an attacker does.

Layer 5: inspect the message, not just the envelope

For the techniques authentication cannot see (display-name spoofing, Reply-To diversion, cousin domains, compromised accounts) the defence is content and header inspection plus human process.

Train people to expand and read the actual From address, not the display name, especially on mobile.
Make any change-of-bank-details or change-of-payee request trigger an out-of-band verification by a known phone number, never by replying to the thread. This single process control defeats the compromised-account case that no DNS record can.
Use header analysis on suspicious replies. The email header analyzer shows the full authentication results, the real sending path and the Reply-To, and the phishing email checker gives a quick read on a message that "feels off" inside a known thread.

Layer 6: keep watching

A hijack campaign frequently follows a quiet change in your authentication posture or a new sending source appearing. Continuous monitoring with change alerts means a sudden spike in forgery attempts, or a policy that silently regressed from reject to none, reaches you fast rather than after the fraud clears. That is what monitoring and change alerts and the monitor service are for.

The practical takeaway

Thread hijacking is two attacks wearing one coat. One version forges your domain to continue a stolen conversation, and DMARC at p=reject stops it dead. The other version sends from a genuinely compromised account, or from a lookalike, or behind a spoofed display name, and authentication passes cleanly because nothing was forged. Email authentication is necessary and it removes the cheapest, most scalable form of this attack, but it is not sufficient, and anyone who tells you p=reject "solves phishing" has not thought about the compromised-account case.

So do both halves. Close the exact-domain door by getting every domain to enforcement, then assume a competent attacker will route around it and defend the accounts, the people and the payment process accordingly. Start by confirming where your domain actually stands with the DMARC checker; if it is not yet at enforced p=reject with clean alignment, that is the first gap a thread hijacker will use, and the done-for-you service will take it there safely without breaking a single legitimate message.