Filtering and DMARC reduce spoofing, but they do not stop attacks that use compromised accounts, thread hijacking, or messages that fit the normal conversation context. In practice, BEC breaks the assumption that malicious email always looks malicious. Defences must therefore validate identity, relationship history, and workflow legitimacy, not just message content.
Why email filtering and DMARC are necessary but insufficient for BEC
email filtering and DMARC are strong first-line controls because they reduce spoofing, lookalike domains, and a large share of commodity phishing. The problem is that BEC is often not a spoofing problem at all. Once an attacker uses a compromised mailbox, a hijacked thread, or a message that fits the normal business context, the email can pass technical checks and still be malicious.
The control gap is that these defences inspect message authenticity and content signals, but BEC also exploits trust, relationship history, and workflow assumptions. If the recipient believes the sender is legitimate, the attack can succeed without any obvious sign of fraudulent formatting or a failed authentication result.
That is why BEC is best understood as a trust abuse problem as much as an email security problem. The attack succeeds when the organisation treats “passes email controls” as equivalent to “safe to act on.”
What email controls do not prove in a BEC scenario
Filtering and DMARC do not prove that the person or system behind the message is entitled to request a payment, change banking details, or redirect sensitive work. They also do not verify whether the message fits the real business process for that request, or whether the conversation has been quietly taken over.
This is where thread hijacking becomes especially dangerous. A reply inside an existing conversation can inherit context, tone, and trust, which means the message may look normal even when the account, the intent, or the workflow has been compromised. The same is true when an attacker sends from a real mailbox after stealing credentials or abusing a session.
Email Identity and BEC Guide is useful here because it connects spoofing controls with mailbox takeover, OAuth mail permissions, and payment verification. For a deeper look at credential abuse as a BEC path, TruffleNet stolen AWS keys campaign 2025 shows how a compromised account can be used to send a convincing invoice without any spoofed domain at all.
What must be validated beyond the message itself
The practical answer is to validate three things the email layer cannot reliably confirm: identity, relationship history, and workflow legitimacy. Identity means confirming the requestor is really who they claim to be. Relationship history means checking whether the request fits prior communication patterns, known contacts, and normal timing. Workflow legitimacy means confirming the action is approved through the correct business path, not merely requested in a believable email.
That changes how organisations handle high-risk requests. Payment changes, bank-detail updates, vendor onboarding, payroll changes, and gift-card or urgent transfer requests should be treated as workflow events, not just mail events. If the approval path lives only in the inbox, the control is already too weak.
Strong email security still matters, but it should be one signal in a broader decision process. The control objective is not “block all bad email,” it is “prevent a convincing email from becoming an authorised business action.”
Risk and Threat Considerations
BEC becomes high impact when organisations rely on content filters and domain authentication as if they were business-approval controls. That creates a false sense of safety, especially when attackers use compromised accounts, hijacked threads, or familiar language to bypass suspicion.
Failure mechanism: The defender trusts email authenticity signals more than the request path, so a malicious message that looks operationally normal is allowed to drive payment, data disclosure, or account-change decisions.
Impact: The result can be fraudulent transfer, vendor impersonation, silent mailbox takeover persistence, or manipulation of business workflows without tripping the technical email defences that were supposed to stop it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | BEC often follows account or session abuse that email filtering cannot see. |
| AC-6 — Least Privilege | Limits the blast radius when a mailbox or workflow account is abused. | |
| Recommendation — Rotate and protect authenticators that could let attackers send trusted internal email. Restrict mailbox and workflow permissions to the minimum needed for business action. | ||
| CIS Controls v8 | CIS-5 — Account Management | BEC scenarios frequently depend on compromised or misused accounts. |
| Recommendation — Tighten account lifecycle controls and remove stale access that can be abused in BEC. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Compromised mail or service identities can bypass spoofing defenses entirely. |
| NHI-05 — Overprivileged NHI | Excess mailbox or workflow privilege makes trusted abuse more damaging. | |
| Recommendation — Harden authentication for accounts that can send trusted business email. Reduce mailbox and automation privileges that can approve or trigger business actions. | ||
| MITRE ATT&CK | T1114 — Email Collection | BEC abuse often uses mailbox access and conversation context. |
| T1586 — Compromise Accounts | Account compromise is a common way BEC bypasses DMARC and filtering. | |
| Recommendation — Monitor for mailbox access and message-hijack patterns that support BEC. Hunt for signs that trusted accounts are being used to send fraudulent requests. | ||
Practitioner Guidance
What to verify: For any money movement, bank-change, or urgent exception request, verify the request through an independent channel tied to the existing relationship, not the same mailbox or thread. If the verification step can be completed inside the compromised conversation, it is not a real control.
Decision rule: If the message asks for a high-impact business action, treat DMARC pass and clean filtering results as necessary but not sufficient evidence. Require a second approval path when the request alters payment, identity, or access state.
What good looks like: High-risk workflows have explicit verification points, clear owners, and documented exceptions, so staff can distinguish a legitimate business request from a convincing email that merely appears routine.
Practitioner takeaway: BEC control fails when email security is treated as the control boundary; the boundary has to move to the business action itself.
Related resources from NHI Mgmt Group
- What breaks when email fraud controls rely only on technical filtering?
- What breaks when security teams rely too heavily on email gateway filtering?
- What breaks when tax fraud controls rely on email or certificate checks alone?
- What breaks when organisations rely only on inbound email security controls?