Vendor Impersonation Email Detection Explained
Vendor impersonation and BEC often pass SPF, DKIM, and DMARC. Learn how to detect fraud when the sender is legitimate.
.png){kind=logo}
Vendor impersonation email detection cannot rely on sender checks alone, because many of these attacks come from real, compromised vendor mailboxes that pass SPF, DKIM, and DMARC. Detection has to evaluate whether the request itself, who is asking, what they're asking for, and who they're asking, makes sense given the actual business relationship.
Key takeaways
- Vendor impersonation and BEC attacks increasingly come from genuine, compromised vendor accounts, not spoofed domains, so authentication checks pass by default.
- The reliable signal is contextual: does the request match who normally handles this vendor, the usual payment pattern, and the stage of the business relationship.
- Common patterns include accounts-payable requests sent to someone who doesn't manage that vendor, and compromised vendor threads padded with real history to borrow trust.
- In 2025, 74% of organizations experienced BEC, up from 63% in 2024, and spoofed emails were the most common type, according to an AFP survey covered by Nacha.
- Out-of-band verification of any payment or bank-detail change is the one control that does not depend on detection.
What makes vendor impersonation different from classic phishing?
Classic phishing relies on a bad link, a bad attachment, or a sender domain that doesn't belong. Vendor impersonation and business email compromise (BEC) often have none of that. There's no payload to sandbox and no obviously wrong domain to flag.
Two variants show up most often:
- Spoofed or lookalike vendor domains. The attacker registers a domain that resembles a real supplier's, sometimes off by a single character, and opens a new thread.
- Compromised vendor accounts (vendor email compromise, or VEC). The attacker has actual access to the supplier's mailbox and replies inside a real, ongoing conversation with accurate invoice numbers and a familiar signature block.
The second pattern is harder to catch, because the message isn't fake in any technical sense. It's a real account doing something it shouldn't.
Why do authentication checks miss these attacks?
SPF, DKIM, and DMARC answer one question: was this message authorized to come from this domain. They say nothing about whether the request inside the message is legitimate. When a vendor's actual mailbox is compromised, every authentication check passes, because the mail genuinely originated from that vendor's infrastructure.
Reputation-based filtering has the same blind spot. A mailbox with months or years of legitimate correspondence has earned trust that a reputation score will not revoke just because one message in that thread is fraudulent.
What does a real vendor impersonation attack look like?
Two patterns stand out in attacks AegisAI has analyzed.
An accounts-payable envelope sent to someone who doesn't pay that vendor. The message is a plausible-looking invoice or payment request, but it's addressed to a person who has no reason to be handling that particular vendor relationship. Headers look fine. The sender may even be real. What's wrong is the context: the request lands with the wrong person for the wrong vendor at the wrong point in the relationship.
A voicemail lure from a compromised vendor, using a genuine business reply chain padded underneath to borrow reputation. The attacker doesn't fabricate history. They attach a real thread, with real prior messages, below a new malicious request. The thread does the convincing; the new ask rides on its back.
In both cases, the giveaway isn't in the headers. It's that the request makes no sense in context: a one-off construction aimed at a named person in a named role, built to exploit exactly who they are and what they're expected to approve.
How should security teams detect vendor impersonation and BEC?
Detection needs to move past "is this sender authorized" and into "does this request fit the relationship." Three questions do most of the work.
Does the request match the business relationship?
Compare the message against what's actually known about this vendor: typical invoice cadence, typical dollar amounts, typical point of contact. A request that's technically plausible but historically unusual, a new approver, a different product line, a vendor the recipient has never corresponded with, is worth a second look.
Has the payment pattern changed?
Bank account changes, new remittance addresses, and requests to switch payment methods are the highest-risk category, regardless of how convincing the surrounding email reads. Capital One's overview of BEC scam types describes the false invoice scheme as a fraudster compromising or spoofing a supplier's account specifically to redirect payment to a new account.
Is the recipient the right person for this request?
If an accounts-payable request lands with someone who has never handled that vendor, that mismatch is itself a signal, independent of anything in the message content or headers.
| Signal type | What it checks | What it misses |
|---|---|---|
| SPF/DKIM/DMARC | Was the sending domain authorized | Whether the request is legitimate |
| Sender reputation | History of the sending address | A compromised account with a clean history |
| Content/link scanning | Malicious attachments or URLs | Payloadless requests with no link or file |
| Contextual review | Who is asking, what, of whom, and whether it fits | Nothing, when applied consistently, but requires relationship data |
An AFP survey reported that 74% of organizations experienced BEC in 2025, up from 63% in 2024, with spoofed emails the most common BEC type at 85% of organizations, according to Nacha's coverage of the AFP Payments Fraud and Control Survey. The same report noted that more than half of respondents received emails from domains nearly identical to legitimate ones, differing by only a letter or two.
Common red flags include an unexpected request to change payment details paired with manufactured urgency, and a mismatch between the From and Reply-To fields. Neither requires technical sophistication to spot, if someone is looking for it.
How does AegisAI approach vendor impersonation detection?
AegisAI treats vendor fraud as a contextual reasoning problem rather than a sender-reputation problem. Instead of asking only "is this sender authorized to send from this domain," the system evaluates who is making a request, what they're asking for, and whether that request is plausible given the recipient's actual role and the known shape of the vendor relationship.
That means weighing:
- Whether this recipient has a documented reason to interact with this vendor at all.
- Whether the request (a new bank account, an urgent payment, a changed point of contact) fits the stage and cadence of the existing relationship.
- Whether a genuine thread has been padded underneath a new, out-of-pattern request, borrowing trust from real history rather than earning it.
This is the same logic used across AegisAI's BEC attack prevention approach and detailed further in how to prevent business email compromise and email security threats: BEC, AiTM, and zero-day phishing. Because flagging every unusual financial request risks burying real work in alerts, the detection model also has to avoid over-triggering on routine accounts-payable traffic, a tension covered in why email security false positives happen.
What can accounts payable teams do right now?
Controls that don't depend on perfect detection tools:
- Verify payment or bank-detail changes out of band. Call a known, independently sourced phone number, not one in the email.
- Apply a cooling-off period before honoring a changed payment instruction, especially for high-value invoices.
- Confirm that the recipient of a request is the right person for that vendor relationship before acting on it.
- Check for Reply-To mismatches and subtle domain differences, even when the display name looks correct.
- Document and refer to a maintained vendor record (bank details, contacts, typical invoice range) outside of email, and treat any email-only deviation as unverified until confirmed.
FAQ
What is the difference between vendor impersonation and vendor email compromise (VEC)?
Vendor impersonation can involve a spoofed or lookalike domain with no actual access to the vendor's systems. VEC specifically means the attacker has compromised the vendor's real mailbox and is operating from inside genuine threads.
Can SPF, DKIM, and DMARC stop vendor impersonation?
They can stop spoofed-domain attacks where the sending infrastructure isn't authorized. They cannot stop attacks from a genuinely compromised vendor mailbox, since that mail passes authentication by design.
What's the most reliable red flag in a fraudulent invoice email?
An unexpected change to payment details, bank account, remittance address, or payment method, especially when paired with urgency or a request to skip normal approval steps.
Why does accounts payable get targeted?
Because AP, procurement, and payroll teams can directly release money or change vendor records.
Should every unusual vendor email be escalated?
Not every anomaly is fraud, but any request involving new payment details, a new approver, or a recipient who doesn't normally handle that vendor warrants out-of-band verification before action.
Get vendor impersonation detection that looks past the headers
Sender authentication alone cannot catch an attack from a real, compromised vendor account. Book a demo with AegisAI to see how contextual detection evaluates the request itself, not just where it came from.
Related posts
More from the AegisAI blog.