My honest thought: DMARC was never built to catch this
You set up SPF. You set up DKIM. You moved your DMARC policy to p=reject, probably after reading the last guide I wrote. Good. Do all of that.
It still won’t stop this.
Here’s the story, and I’ve heard some version of it three times this year already, so I’m not even going to pretend it’s rare anymore. A bookkeeper at a small agency gets a reply inside a real invoice thread — a vendor they’ve paid a dozen times, same subject line, same tone, everything checks out. New bank details in the attachment though. Someone finally picks up the phone instead of just approving it, calls the vendor to confirm — and the vendor has no idea what they’re talking about. Turns out their inbox got compromised three days earlier. Nobody there even knew yet.
Microsoft’s threat data puts BEC attacks at 10.7 million in Q1 2026 alone. One quarter. And 28% of those go through something called Thread Hijacking, which is exactly what it sounds like — the attacker doesn’t send you anything new. They just reply.
Everything from the DMARC setup guide still applies. SPF, alignment, the whole checklist. That’s not the part that’s wrong. The part that’s wrong is thinking it’s the whole answer.
Lookalike domains are basically a solved problem now
The old version of this attack was almost quaint. acme-payr0ll.com instead of acme-payroll.com. A zero where an O should be. Filters catch that now, DMARC catches that now, half the internet catches that now.
So attackers stopped bothering with fake domains and just started breaking into real ones. A vendor’s actual cloud email account — usually some smaller shop with weaker security than whoever they’re targeting. A bookkeeping firm. A logistics company. Some niche SaaS tool nobody’s really watching. Once they’re in, there’s nothing to fake. SPF passes because it’s the real domain. DKIM passes for the same reason. DMARC passes because, technically, this is that vendor’s mail server sending mail.
What actually happens inside a hijacked thread
An agency’s been getting invoices from a small translation vendor for two years. Real relationship. Dozens of prior emails. The AP person knows that name, knows the format, doesn’t think twice when it shows up.
Someone gets into that vendor’s account — usually just a reused password that got scraped in some unrelated breach, nothing dramatic. And they don’t send a new suspicious email. They reply inside the thread that’s already there. Same subject. Same recipient. Same domain that’s been authenticated a hundred times already. The only thing different is the routing number on page two of the PDF.
None of that trips anything. The mail server is real. The signatures check out. DMARC isn’t evaluating whether the content is safe — it’s only answering whether the sender is who they say they are. And they are. That’s the whole problem.
The part that stings if you already did everything right
This is the annoying bit. Your own DMARC setup, even perfect, does nothing here — because this attack was never aimed at your domain. It’s aimed at a vendor you already trust, wearing that vendor’s real authenticated identity.
p=reject stops people from pretending to be you. It has zero opinion on whether someone you already do business with just got compromised. That gap doesn’t live in your DNS. It lives in whatever security posture your least-careful vendor happens to have this month, which you have no visibility into and no control over.
And it’s not just finance. Same exposure with a compromised ESP login, a freelancer’s inbox, an agency partner sending campaigns on your behalf. Any of it becomes an authenticated channel that sails past everything we just spent an entire article configuring.
What I actually tell clients to do about it
Not abandoning DMARC. Obviously. Everything from before still stands — this is additive, not a replacement.
Verify anything involving money or credentials off the original channel. Bank detail change, payment routing change, login reset request — doesn’t matter how long you’ve worked with them, it gets a phone call to a number you already had on file before it before anyone acts on it. Not the number in the signature. Not a reply-to-confirm. A call.
This is genuinely the first thing I set up when I’m building out vendor or automation workflows for anyone — before DMARC’s even live, honestly. It’s the cheapest insurance in this whole conversation, and it’s also the first thing people skip, right up until the week they really wish they hadn’t.
Notice when the pattern breaks, not just when authentication fails. A vendor who’s invoiced you the same way for two years suddenly changes format, or tone, or gets weirdly urgent — that’s worth more than any SPF check. Mostly this is a training problem. Teach the people handling this stuff to notice when something feels off, not just wait for a technical flag that isn’t coming.
Ask new vendors about their own setup before you onboard them. Their weak security becomes your attack surface the moment they’re compromised. Especially anyone sending you invoices or running campaigns for you.
Don’t let a single email thread authorize anything financial. If your current process allows that — and a lot of processes quietly do — that’s the actual hole. Require a second channel, every time, no matter how legitimate the thread looks.
Where I land on this
DMARC’s not optional, still isn’t, wasn’t the point of this piece to argue otherwise. But it answers exactly one question — is this sender who they claim to be — and it was never going to answer whether that sender got compromised somewhere along the way. Attackers figured that out well before most security teams caught up to it.
That 10.7 million number isn’t mostly companies who skipped authentication. It’s companies who did authentication right and still got hit, because authentication was never the layer built to stop this particular thing.
Fix your own domain. Then go build the layer that assumes even a fully authenticated sender might not be who they used to be five minutes ago
Sources
Calysto Group: Email Patterns Bypassing Spam Filters in 2026 — blog.calystogroup.com/post/email-patterns-bypassing-spam-filters-2026
Microsoft Security: Q1 2026 BEC Threat Data (via Calysto Group analysis) — blog.calystogroup.com/post/email-patterns-bypassing-spam-filters-2026
Sublime Security: Thread Hijacking Analysis (via Calysto Group citation) — blog.calystogroup.com/post/email-patterns-bypassing-spam-filters-2026
DuoCircle: DMARC, SPF, DKIM in 2026 — duocircle.com/blog/dmarc-spf-dkim-2026-email-authentication-regulatory-requirement-best-practice
PowerDMARC: DMARC Requirements 2026 — powerdmarc.com/dmarc-requirements
E.Gerion Reviews: DMARC in 2026 — egerionreviews.com