Layered email security controls still leave phishing and BEC gaps

At a glance

What this is: A global technology company found that layered email gateways still left phishing and BEC gaps, while also creating SPF, DMARC, and operational problems.

Why it matters: For IAM and security teams, this matters because email defence increasingly intersects with identity abuse, impersonation, and compromised internal accounts rather than simple spam filtering.

👉 Read Proofpoint's analysis of layered email security and BEC control gaps

Context

Email security often fails when organisations try to compensate for a weak primary control with a second gateway and a growing set of manual exceptions. In practice, that approach can create alignment problems, policy drift, and more work for the SOC rather than less. The primary issue here is not spam volume alone, but the gap between message filtering, identity signals, and operational ownership.

That gap matters to identity practitioners because business email compromise, impersonation, and compromised internal accounts are identity problems as much as mail problems. When SPF and DMARC alignment break, or when internal traffic behaves differently from external traffic, defenders lose the consistency they need to trust authentication and enforcement signals.

Key questions

Q: What breaks when organisations add a second email gateway behind an existing mail filter?

A: A second gateway can break authentication alignment, duplicate policies, and create conflicting trust signals across external and internal mail. That often means SPF and DMARC no longer reflect the real delivery path, while analysts spend more time reconciling systems than stopping attacks. The practical failure is not just complexity, but loss of control clarity.

Q: Why do business email compromise attacks succeed even in well-run organisations?

A: They succeed because many organisations still treat routine communication as proof of authority. Attackers exploit that assumption by mimicking vendors, replaying familiar threads, or inserting themselves into approval chains. The weakness is usually the business workflow, not the mailbox itself.

Q: How do organisations know if email security is actually working?

A: Look for fewer fraudulent requests reaching approval stages, faster triage of suspicious mail, and reduced analyst time spent on low-value noise. Effective email security improves decision quality, not just blocking rates, because the real test is whether risky identity-linked messages are stopped before business action occurs.

Q: Who is accountable when email impersonation leads to account takeover?

A: Accountability sits with the organisation that owns the sender domain, the security team operating mail authentication, and the business owners responsible for customer communication. If brand trust is weak, those functions have to coordinate the controls and maintain them over time.

Technical breakdown

Why layered email gateways create authentication drift

Running two email security gateways in series changes the path mail takes through the environment, which can break assumptions embedded in SPF and DMARC. SPF evaluates whether the sending IP is authorised, while DMARC checks alignment between the visible From domain and the authenticated domain. If the first gateway rewrites or relays mail before the second gateway sees it, the trust chain can become inconsistent. That is why teams often end up troubleshooting the transport path instead of the threat itself. The architecture may appear defensive, but the control plane becomes harder to reason about as mail moves across vendors and policies.

Practical implication: validate authentication alignment end to end before adding another mail control layer.

Why custom rule estates become an operational control risk

Legacy email gateways often depend on hand-built rules for impersonation patterns, lookalike domains, and sender exceptions. Over time, those rules accumulate into a policy estate that is fragile, hard to test, and expensive to maintain. Each exception can reduce false positives, but it can also create blind spots and inconsistent enforcement between internal and external traffic. In email security, a large rule library is not automatically maturity. It can also be a sign that the organisation is encoding threat response into local fixes rather than into a maintainable control model.

Practical implication: inventory rule dependencies and retire controls that exist only to compensate for platform gaps.

How identity-focused email defence changes the threat model

Email attacks increasingly target identity signals rather than malware alone. Impersonation, fraudulent invoices, and compromised internal accounts all depend on convincing the recipient that the sender is legitimate. Identity Management Defense style controls try to detect account takeover patterns, abnormal sending behaviour, and internal abuse that a perimeter mail filter may miss. That does not replace gateway security, but it changes the centre of gravity from content inspection alone to identity and behavioural verification across the mail flow. In a modern environment, the question is whether the control stack can recognise when a trusted identity has become the attack path.

Practical implication: treat identity telemetry as part of email defence, not as a separate SOC problem.

Threat narrative

Attacker objective: The attacker aims to use trusted email identities and delivery paths to obtain fraudulent payment, manipulate recipients, or sustain access without immediate detection.

1. Entry occurs through phishing, spam, impersonation, or a fraudulent invoice delivered into the mail stream.
2. Escalation follows when a compromised internal account or trusted sender identity is used to widen reach or bypass user suspicion.
3. Impact emerges as business email compromise, payment fraud, or inbox disruption that consumes security team capacity.

NHI Mgmt Group analysis

Email security has become an identity governance problem, not just a filtering problem. When impersonation and compromised internal accounts are the real attack paths, the control question shifts from message volume to trust in sender identity. That is why email defence increasingly overlaps with IAM, PAM, and account monitoring, especially where executives and finance teams are targeted. Practitioners should govern sender trust as an identity signal, not a mail-only setting.

Layered gateways can hide control failure behind operational complexity. The article shows a familiar pattern: teams add another perimeter control, but the new stack introduces SPF and DMARC alignment headaches, duplicated policy logic, and more manual intervention. That can make the environment feel safer while actually increasing drift. The broader lesson is that compensating controls must be measured against maintainability, not just coverage. Practitioners should reduce control layers that consume more human effort than they remove risk.

Custom rule sprawl creates a hidden governance debt. A large estate of bespoke exceptions is often evidence that the platform is being asked to do too much local decision-making. That debt shows up as false-positive reviews, overtime, and fragile migrations. In governance terms, it is a control model that depends on tacit tribal knowledge rather than repeatable policy. Practitioners should treat rule rationalisation as a security control, not only as an operational cleanup task.

Identity-focused email defence is where modern BEC control is heading. Fraudulent invoices and account takeover are no longer separate email problems. They are manifestations of sender trust, user trust, and account trust collapsing at different points in the workflow. That puts identity verification, behavioural analytics, and mailbox monitoring closer to the centre of email security strategy. Practitioners should expect email security programmes to converge more tightly with identity monitoring and response.

Named concept: mail flow trust drift. This is the state where each added gateway, relay, and exception subtly weakens the organisation's ability to reason about who sent what, from where, and under which policy. The article illustrates that the drift is both technical and governance-related. When trust drift accumulates, defenders spend time reconciling control behaviour instead of stopping attacks. Practitioners should measure and reduce trust drift before it becomes an incident multiplier.

What this signals

Mail security programmes are drifting toward identity-aware control models. The practical signal here is that organisations can no longer rely on gateway depth alone. As impersonation and account compromise become more common than obvious malware, teams should align email telemetry with identity monitoring, mailbox abuse detection, and response workflows that cross security and IAM boundaries.

The governance signal is equally clear. When a team spends hours every day maintaining a policy stack, the environment has crossed from defence into administration-heavy compensation. That is the point at which control rationalisation, ownership clarity, and measurable overhead reduction become security objectives in their own right.

Mail flow trust drift is a useful way to frame the risk for practitioners. The more gateways, relays, and exceptions an organisation adds, the harder it becomes to prove which control made a decision and why. Teams should watch for any mail path where trust signals no longer map cleanly to policy enforcement.

For practitioners

• Reconcile SPF and DMARC paths across all relays Map how inbound and internal mail is rewritten, relayed, and authenticated at each hop. Then test whether SPF and DMARC still align after every gateway, not only at the edge.
• Rationalise custom mail rules into fewer policy layers Identify rules that only exist because a prior gateway could not block the threat natively. Retire overlapping exceptions and document which controls are compensating for platform limitations.
• Add identity signals to email abuse detection Correlate inbox behaviour, sender reputation, and account takeover indicators so finance, executive, and internal-user impersonation can be detected as an identity event as well as a content event.
• Measure operational overhead as a security metric Track analyst time spent on false positives, manual triage, and rule maintenance alongside detection rates. If overhead rises while coverage stays flat, the control model is failing.

Key takeaways

• Layered email filters can still leave phishing and BEC exposure if authentication alignment and identity signals drift.
• Operational overhead is a security outcome, and in this case the team reclaimed two hours per person by simplifying the control stack.
• Modern email defence has to reduce trust drift, not just increase the number of tools in the path.

Key terms

• Business email compromise: A form of social engineering where an attacker impersonates a trusted person or domain to manipulate payment, change banking details, or extract sensitive information. It often succeeds without malware because the attacker targets process trust and human judgement instead of technical controls.
• DMARC: DMARC is an email authentication policy mechanism that uses DNS-published records to tell receiving mail systems how to handle messages that fail alignment checks. It helps reduce impersonation risk, but it only works when the published policy is accurate, current, and governed as part of the domain's security state.
• Mail Flow Trust Drift: Mail flow trust drift is the gradual loss of clarity about which system authenticated, transformed, or approved a message as it moved through multiple gateways and exceptions. It usually appears when layered controls create conflicting policy paths and ambiguous ownership.
• Identity-Focused Email Defence: Identity-focused email defence is an approach that treats sender identity, account behaviour, and impersonation patterns as core security signals. It complements content filtering by detecting when a trusted person, mailbox, or workflow is being abused as the attack path.

What's in the full article

Proofpoint's full article covers the operational detail this post intentionally leaves for the source:

• The month-long proof-of-concept setup that split inbound mail flow across two stacks for side-by-side comparison.
• The specific operational changes that removed the need for many bespoke Cisco ESA rules.
• The Identity Management Defense response to a compromised internal account and the follow-on behaviour it aimed to stop.
• The day-to-day migration support steps that helped the team move from manual tuning to a simplified mail security model.

👉 The full Proofpoint article covers the proof of concept, migration experience, and identity-focused response details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build governance models that scale across modern control environments.