TL;DR: DexKo Global says replacing its legacy SEG with a Microsoft plus Abnormal API-based architecture across 7,000 employees and a partner-heavy supply chain freed budget and bandwidth while improving protection and automation, according to Abnormal AI. The real shift is that email security is moving toward API-level control and operational efficiency, not just filter tuning.
At a glance
What this is: Abnormal AI describes how DexKo Global moved from a legacy SEG to an API-based email security architecture to support a large employee base and a partner-heavy supply chain.
Why it matters: For IAM and security teams, this matters because email controls are increasingly tied to identity context, operational scale, and integration depth rather than stand-alone gateway filtering.
Context
Email security is shifting from a perimeter gateway model to an architecture that can inspect and act on identity, message, and tenant signals through API-level integration. In this case, the operational problem is not just stopping malicious mail, but reducing the maintenance burden and blind spots that come with legacy SEG-centric designs.
DexKo Global is presented as a representative environment for that transition: 7,000 employees, dozens of locations, frequent acquisitions, and a supply chain that includes hundreds of partners and contractors. That mix makes email governance as much about integration and scale as it is about filtering messages.
Key questions
Q: How should security teams decide whether a legacy SEG still fits their environment?
A: They should test the SEG against today’s operating model, not last year’s mail flow. If users work across cloud tenants, acquisitions, contractors, and partner-heavy collaboration, the control should be judged on visibility, automation, and integration depth. A gateway that needs constant tuning and still leaves blind spots is usually a sign the architecture has outlived its design assumptions.
Q: Why do partner-heavy email environments push teams away from gateway-only security?
A: Because the attack surface is no longer confined to internal mailboxes. External suppliers, contractors, and acquired entities expand the trust graph, so the useful control is one that can use tenant telemetry, sender identity, and behavioural context together. Gateway-only thinking struggles when the real boundary is the collaboration ecosystem, not the network edge.
Q: What are the signs that email security is still too dependent on legacy controls?
A: Common signals include high manual tuning effort, repeated investigation of the same mail patterns, limited visibility into cloud email context, and security work that stays stuck in maintenance mode. If the team cannot spend time on response and programme improvement, the control stack is probably consuming more capacity than it creates.
A: They should evaluate whether the email architecture can scale across multiple locations, inherited environments, and external trust relationships without adding disproportionate operational burden. In those cases, the right model is the one that supports platform integration and consistent governance across all mail paths, not the one that simply filters messages at the edge.
Background and context
Why API-based email security displaces the legacy SEG model
Legacy secure email gateways sit in the traffic path and rely heavily on filtering, policy tuning, and mail-flow inspection. API-based email security instead connects to the email platform and inspects content, sender patterns, and tenant telemetry after delivery decisions are available, which improves visibility into cloud mail environments and reduces dependence on inline controls. The architectural shift matters because modern collaboration happens across distributed tenants, partner domains, and identity-rich workflows that a gateway alone does not govern well.
Practical implication: teams should assess whether gateway-centric controls still match their email and identity architecture.
Why supply-chain complexity changes the email security design
A large partner ecosystem expands the number of external identities, domains, and trust relationships that can reach users by email. The issue is not only phishing volume, but the governance burden created when contractors, suppliers, and acquired entities all interact with the same workforce. In that environment, the control model has to scale across multiple trust boundaries, not just enterprise-owned mailboxes.
Practical implication: map partner and contractor email exposure before deciding whether SEG-era controls are still sufficient.
How automation and productivity become security design requirements
When an email security stack consumes less operational time, it can free analysts to spend effort on investigation, response, and programme improvement. That is an identity and governance issue as much as a security one, because the control should reduce toil without reducing assurance. The real test is whether automation improves both detection coverage and operational throughput, not merely whether it changes the tool count.
Practical implication: measure email security by the operational work it removes as well as the threats it blocks.
NHI Mgmt Group analysis
Email security is moving from gateway control to identity-aware control. A legacy SEG assumes the mail boundary is the primary enforcement point, but modern collaboration is already distributed across cloud tenants, acquisitions, and partner ecosystems. That makes message security inseparable from identity context and platform integration. Practitioners should treat email security as part of the broader identity plane, not as a standalone filter stack.
Legacy SEG retirement is usually an architectural decision, not a feature preference. The driver is often operational drag: tuning burden, limited automation, and poor fit for cloud-first email workflows. In practice, that means teams should evaluate whether the current control still matches how users, partners, and acquired entities actually exchange mail. The programme question is whether the architecture can keep pace with enterprise change.
Partner-heavy environments expose the weakness of mailbox-centric thinking. When hundreds of external suppliers and contractors interact with users, the useful control is the one that can reason across sender identity, tenant telemetry, and behavioural context. A gateway can still play a role, but it no longer defines the security boundary. Practitioners should align email controls to the trust graph, not just the mailbox.
Operational efficiency is now a security outcome, not a side effect. Freed budget and bandwidth matter because they determine whether security teams can reinvest in investigation, response, and broader identity governance. That is why legacy-control retirement should be assessed against measurable programme capacity, not only against threat-blocking claims. The right question is whether the architecture expands security headroom.
API-based email security reflects a broader identity re-architecture across enterprise security. The same pattern appears wherever cloud platforms expose richer telemetry and faster control points than legacy perimeter tools. Email is simply one of the clearest examples because it sits at the intersection of identity, collaboration, and social engineering risk. Practitioners should expect the control plane to keep moving closer to the platform itself.
What this signals
API-based mail control changes the governance question. The decisive issue is no longer whether a gateway can filter enough messages, but whether the email stack can align with cloud identity and collaboration workflows. That shifts ownership toward architecture, integration, and operational resilience rather than mailbox inspection alone.
Segmentation of trust relationships becomes the real design problem. Once a company operates across acquisitions, locations, and external partners, email security has to follow the trust graph. Teams should expect future control decisions to favour platform-level visibility over perimeter-only enforcement.
For practitioners
- Reassess the email security control plane Compare your current SEG architecture against the way mail now moves through cloud platforms, acquired businesses, and external partners. If the gateway is still the main enforcement point, document where visibility, automation, and response depth are constrained.
- Map partner and contractor exposure Inventory which suppliers, contractors, and acquired entities can reach users through email and how those trust relationships are governed. Use that map to decide whether message controls need tenant-level or identity-aware integration.
- Measure operational drag, not just detection coverage Track analyst time spent on tuning, false positive handling, and manual investigation before and after architecture changes. The goal is to see whether the control frees bandwidth for higher-value security work.
- Test automation against real workflows Validate whether automation improves both containment and productivity in environments with multiple locations and heavy external collaboration. A control that blocks mail but cannot scale across the organisation’s workflow is not aligned to the operating model.
Key takeaways
- Legacy SEG retirement in this case reflects a broader move away from gateway-centric email security toward platform-integrated control.
- The article ties the change to 7,000 employees, dozens of locations, and a supply chain of hundreds of partners and contractors, which creates a harder governance problem.
- Security teams should test email architectures for integration depth, operational drag, and trust-graph visibility before treating legacy SEG controls as sufficient.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Email control is increasingly tied to identity-aware authorisation across cloud collaboration. |
| Recommendation — Align email security governance to PR.AA-05 so message controls reflect current entitlements and trust boundaries. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Policy Engine and Enforcement Point | API-based email security shifts enforcement closer to cloud platform telemetry and decision points. |
| Recommendation — Place enforcement where cloud identity and message telemetry can be evaluated together. | ||
| CIS Controls v8 | CIS-5 — Account Management | Partner-heavy email environments depend on disciplined external account governance. |
| Recommendation — Review external account paths alongside email controls so contractors and partners are governed consistently. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | API-based email security depends on correctly configured platform integrations and access. |
| Recommendation — Audit API-connected email integrations for misconfiguration and overbroad access. | ||
Key terms
- API-Based Email Security: API-based email security integrates with the mail platform through application interfaces rather than sitting in front of traffic. This lets security teams inspect delivered messages, automate remediation, and connect email actions to mailbox and identity context in cloud-native environments.
- Secure Email Gateway: A secure email gateway is a control layer that inspects email before it reaches users and can also inspect outbound mail. It filters malicious content, enforces policy, and reduces exposure to phishing, malware, and data leakage, but it does not replace identity governance or account monitoring.
- Trust graph: The map of how identities connect to each other and to the systems they can reach. A trust graph helps teams see inherited access, hidden pivots, and the points where a compromised credential could unlock far more than its original purpose implied.
- Operational drag: Operational drag is the delay and effort created when routine business changes require manual coordination, tickets, or engineering intervention. In identity and access programmes, it shows up when governance processes cannot keep pace with the decisions they are meant to support.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 27, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org