Vendor Email Compromise

15 March 2026 · 12 min read

There is a particular kind of fraud that never trips your spam filter, never fails authentication, and never asks you to click anything suspicious. The email comes from a supplier you have paid a dozen times before. The address is correct, down to the last character. The thread is real: it is the same conversation you have been having about an outstanding invoice, with your own earlier replies quoted underneath. The only thing that has changed is the bank account on the attached remittance. This is vendor email compromise, and it is one of the few attacks that walks straight past every control built to stop someone pretending to be a trusted sender, because by the time it reaches you the sender is not pretending at all.

This article is about how a breach in one organisation becomes a fraudulent invoice in another, why the usual anti-spoofing defences are necessary but not sufficient here, and the specific, layered controls that actually catch it. It is deliberately not a generic phishing explainer. Vendor email compromise has its own mechanics, and the defences that work against it are different from the ones that stop a forged display name.

What vendor email compromise actually is

Vendor email compromise, sometimes written as VEC, is a sub-type of business email compromise where the attacker controls, or convincingly borrows, a genuine mailbox at one of your suppliers, partners or contractors. From that mailbox they send you a real email asking you to change payment details, settle an invoice, or release a payment to a new account.

The crucial distinction from ordinary invoice fraud is the source of the message. In classic invoice fraud driven by a spoofed domain, the attacker forges the supplier's address from infrastructure they do not control, and the message can be made to fail SPF, DKIM and DMARC if those are configured. In vendor email compromise the email originates from the supplier's actual mail system, sent through the supplier's own authenticated path. It passes SPF because it really did come from the supplier's permitted servers. It carries a valid DKIM signature because the supplier's own keys signed it. It aligns under DMARC because the From: domain and the authenticated domain genuinely match. Every authentication check returns a green tick, and every one of those ticks is telling the truth.

That is what makes it dangerous. The attack does not defeat email authentication. It renders authentication beside the point, because authentication answers the question "did this domain really send this?" and here the honest answer is yes.

How a supplier breach becomes your problem

The chain from a distant breach to a fraudulent payment from your own bank account follows a recognisable pattern. Understanding each link is what tells you where the controls have to sit.

Step one: the initial compromise

The supplier's mailbox is taken over, usually through one of a small number of routes:

Credential phishing. Someone at the supplier entered their username and password into a fake login page, often a convincing copy of a Microsoft 365 or Google Workspace sign-in. If the supplier has no multi-factor authentication, that is the whole job done.
Token or session theft. Modern phishing kits do not just harvest passwords; they relay the login in real time and steal the authenticated session token, which sidesteps many forms of MFA.
Password reuse and stuffing. A password leaked in an unrelated breach is tried against the supplier's webmail. Where it is reused, the attacker is straight in.
Malware on an endpoint at the supplier that lifts saved credentials or live sessions.

None of this happens on your network. You have no visibility of it, no logs, no alerting. The first organisation to know is the supplier, and frequently they do not know either.

Step two: quiet reconnaissance

A competent attacker does not immediately fire off a fraudulent invoice. They sit inside the mailbox and read. They are looking for the language of money: outstanding invoices, payment runs, the names of finance contacts on both sides, the tone the supplier uses, the format of their remittance advices, when payments are typically due. They learn that your accounts payable clerk is called by their first name, that invoices come as PDFs from a particular template, that the supplier always signs off with a specific phrase.

To stay hidden, attackers commonly set inbox rules that auto-archive or auto-delete replies containing certain keywords, so the genuine mailbox owner never sees the conversation the attacker is having with you. They may also set up auto-forwarding to an external address so they can keep monitoring even if they are kicked out.

Step three: insertion into a real thread

This is the move that defeats human judgement. Rather than starting a fresh email, the attacker replies within an existing, legitimate thread, or starts a new one that references real, current business. Because they are sending from the genuine account, the reply lands in the same conversation, with your previous messages quoted beneath. There is no lookalike domain to spot, no unfamiliar address, no broken branding. The signals people are trained to check are all correct.

The ask is almost always a variation on a single theme: our bank details have changed, please update them for this and future payments. Sometimes it is urgency layered on top, a request to push a payment through before a cut-off. Sometimes it is patient, simply updating a record so the redirected account is in place for the next routine payment run.

Step four: the payment redirect

You pay. The money goes to an account controlled by the attacker or a money mule, and within hours it is moved on and out of reach. The genuine supplier, weeks later, chases the invoice they never received payment for, and the discrepancy finally surfaces, long after recovery is realistic.

Why your anti-spoofing stack does not catch this on its own

If you have done the work to take your own domain to p=reject, you have protected the world from people impersonating you. That is real and worthwhile, and it is what the done-for-you DMARC service is built to deliver. But it is essential to be honest about what that protects against, because vendor email compromise sits squarely in the gap.

DMARC, SPF and DKIM answer one question: is this message genuinely authorised by the domain in the From: header? Run any tool you like against a vendor-compromised message and the verdict is unambiguous.

SPF passes, because the message was sent from an IP the supplier's own SPF record authorises.
DKIM passes, because the supplier's private key signed it, and the DKIM signature verifies against their published public key.
DMARC passes with alignment, because the authenticated domain and the visible From: domain are one and the same. A DMARC check on that supplier returns a clean result.

There is no forged header here. The Header From is the supplier's real domain, sending through the supplier's real infrastructure. Authentication is functioning perfectly; it is simply being asked the wrong question. It verifies the domain, not the intent of the human currently logged into it.

This is the single most important thing to internalise about VEC: a passing DMARC result on an inbound email is not a guarantee that the message is safe. It is a guarantee that the domain is genuine. Those are different statements, and conflating them is exactly the assumption the attacker is exploiting.

For the same reason, the business email compromise category as a whole is poorly served by domain authentication alone. Display-name spoofing, lookalike domains and free-webmail impersonation are partly addressable by training and filtering. Compromise of a genuine account is not addressable by authentication at all, because the account is genuine.

The controls that actually catch it

Because no single layer stops vendor email compromise, the defence is a stack. Some layers reduce the chance that authentication is silently misleading you. Some catch the message in transit. The decisive ones sit around your payment process itself. Here is the realistic hierarchy, strongest first.

1. Out-of-band verification of bank-detail changes

This is the control that works when everything else has failed, and it is procedural, not technical. No change to a supplier's bank details is ever actioned on the strength of an email alone. A change is only made after a call-back to a phone number you already hold on file for that supplier, never a number supplied in the email requesting the change.

Make it a hard rule, written into your accounts payable process:

Any request to change banking details triggers a verification call to a previously known contact.
The number is taken from your own records, not from the email signature, the invoice, or anything in the message.
The person making the change is not the same person who received the request, so a single deceived individual cannot complete the loop alone.
The verification is logged, with who was called, on what number, and when.

This one control neutralises the entire attack, because the fraudulent instruction cannot survive contact with a phone call to the real supplier. Every technical layer below exists to reduce how often you have to rely on it, but it is the backstop that does not depend on spotting anything subtle.

2. Treat a clean DMARC pass as table stakes, not all-clear

Authentication still earns its place, because it strips away the easy version of the attack. With your own domain at enforcement and your inbound filtering checking authentication on everything arriving, the attacker cannot simply forge a supplier from cheap infrastructure; they are forced into the far harder work of actually compromising a real mailbox. You want to make impersonation expensive so that only the genuine-account path remains, and then you watch that path differently.

So keep the foundation solid. Confirm your own posture with the DMARC checker, keep an eye on your suppliers' posture too, and remember that a green result on inbound mail moves a message from "obviously forged" to "domain is genuine", which is precisely the population you then apply human verification to.

3. Anomaly detection on the content and context

Modern mail security can flag the behaviour that surrounds VEC even when the authentication is clean:

New or changed bank details mentioned anywhere in a message, which can be detected and held for review.
Display name and address mismatch within a known thread, or a reply that suddenly arrives from a slightly different infrastructure than the supplier normally uses.
Newly created inbox rules or auto-forwarding on your own users' accounts, which is a sign that you are the compromised vendor for someone else. Alerting on mailbox-rule creation is one of the highest-value detections you can enable.
First-contact and unusual-payment-pattern flags, where a supplier who never normally emails about banking suddenly does.

None of these are certainties. They are signals that move a message into a "verify before acting" queue, which is where step one then takes over.

4. Reduce your own blast radius so you are not the breached vendor

Every organisation is somebody's supplier. The same breach that hits your vendor can start with you, and then your customers receive the fraudulent invoice from your genuine domain. Closing that door is partly about email and partly about account security:

Enforce phishing-resistant MFA on all mailboxes. Token-theft-resistant methods such as passkeys or hardware security keys defeat the real-time relay kits that beat one-time codes.
Alert on and restrict auto-forwarding to external domains, a frequent attacker persistence mechanism.
Monitor for impossible-travel and anomalous sign-ins on mail accounts.
Keep your authentication records correct and watched, so that when an attacker does try the cheap forged-domain route against your customers, it fails. This is where continuous monitoring matters: a record that was right last quarter can drift. Emailed monitoring with change alerts tells you the moment your DMARC, SPF or DKIM posture changes, which is also how you notice unexpected sending sources that might indicate abuse.

5. Read your DMARC reports for early signs of supplier trouble

Your aggregate reports will not show you a compromised supplier directly, but they show you the sending sources using your domain, and a strange new source can be the first hint that something in your sending estate has been taken over and is being used to attack your own customers. If you have never made sense of one, the guide to reading your first DMARC report walks through the fields, and the report analyser turns the raw XML into something legible.

A worked example

Here is the shape of a real VEC message, with the headers that matter. Imagine your supplier is supplies-co.example and they are genuinely compromised.

From: "Sarah Mills" <sarah.mills@supplies-co.example>
To: accounts@yourcompany.example
Subject: RE: Invoice 4471 - payment
Authentication-Results: mx.yourcompany.example;
  spf=pass smtp.mailfrom=supplies-co.example;
  dkim=pass header.d=supplies-co.example;
  dmarc=pass header.from=supplies-co.example

Notice that everything authenticates. spf=pass, dkim=pass, dmarc=pass, all aligned to the real supplier domain. There is no lookalike, no display-name trick, no forged From. The body reads:

Hi, further to the below, our accounts have moved to a new bank as part of a group restructure. Please use the updated details on the attached remittance for invoice 4471 and going forward. Sorry for any inconvenience.

The attached PDF carries new account details. Every automated check is satisfied. The only thing that stops this payment is a person picking up the phone, dialling the number already on file for Sarah Mills, and hearing her say she never sent it. That is the control. Everything else narrows the field down to the messages that need that call.

Putting it together: a short checklist

If you take one thing from this, make it the procedure. The technology supports the procedure; it does not replace it.

Mandatory call-back verification for any bank-detail change, to a number you already hold, by a second person, logged.
Phishing-resistant MFA on every mailbox, yours and, where you can influence it, your suppliers'.
Alert on mailbox-rule creation and external auto-forwarding, the tell-tales of an account takeover in progress.
Keep your own domain at enforcement so the cheap forged-domain attacks fail and only the genuine-account path, which you verify by phone, remains.
Watch your authentication posture continuously, so drift and unexpected sources surface fast.
Treat a clean DMARC pass as the start of scrutiny on money-movement emails, not the end of it.

The honest takeaway

Vendor email compromise is the attack that exposes the limits of email authentication, and pretending otherwise helps nobody. DMARC at p=reject is genuinely valuable: it stops people impersonating your domain, protects your brand and your customers, and forces attackers off the easy forged-sender path. But it verifies that a domain is real, not that the person behind a real mailbox is honest. When a supplier's own account is compromised, the fraudulent invoice authenticates perfectly, because it is, technically, perfectly authentic.

The defence is therefore layered, and the load-bearing layer is human and procedural: never change a payment destination on the say-so of an email, always verify out of band, and design the process so no single deceived person can complete a payment redirect. The technical controls, enforcement on your domain, phishing-resistant MFA, mailbox-rule alerting and continuous monitoring, exist to shrink the number of messages that reach that human checkpoint and to stop you becoming the breached vendor in someone else's story.

Start by knowing where your own domain stands. Run it through the DMARC checker to confirm your policy, and if you are still at p=none or have no record at all, the safe path to p=reject without breaking your real mail, plus continuous monitoring with change alerts, is exactly what the done-for-you DMARC service exists to provide.

Vendor email compromise