A secure email gateway (SEG) is a security layer deployed in front of an email platform, via MX-record rerouting or an appliance, that filters inbound and outbound mail for spam, malware and known threats before delivery. For two decades it was the default email security architecture; the cloud era has changed its role.
Key facts
- SEGs excel at volume threats: spam, known malware, reputation-based blocking.
- Architecture is the limitation: a perimeter position cannot see internal mail, mailbox behavior or the OAuth app layer, and signature-based detection cannot see attacks with no signature.
- Native cloud filtering now overlaps much of the SEG''s traditional job, which drives the SEG-replacement trend toward ICES-style API security.
What a SEG does well, and where it goes blind
The gateway''s strengths are real: mature policy engines, encryption and DLP features, and effective bulk filtering. Its blind spots are structural. Payload-free BEC contains nothing a signature matches. AI-written spear phishing is unique per message. Internal phishing after account takeover never crosses the perimeter. OAuth consent phishing happens entirely outside mail flow the gateway inspects. None of these are tuning problems; they are consequences of where the box sits and how it decides.
SEG, native filtering or ICES?
Many organizations run native filtering plus an ICES layer and retire the gateway, keeping one less hop, one less vendor and full internal visibility. The right order of evaluation: what does your platform already catch, what actually reaches inboxes today, and which architecture sees those attacks. Related reading: email spoofing and zero-day attacks.
Where Sentaro fits
Sentaro is an ICES-category platform: it deploys via API in minutes on Microsoft 365 and Google Workspace and runs behind native filtering, catching the targeted attacks a SEG cannot see.