The IT manager of a logistics company came to us with a single question: "We deployed our new email security solution, but customers say 'your emails are delayed,' and last week someone in accounting had their account taken over and phishing went out from it to all our customers — why didn't our solution see it?" Both complaints had a single common root: architecture.
Before the "which product" question in email security comes a frequently skipped one: "what architecture does this product use?" Because architecture directly determines delivery speed, whether internal phishing is visible, deployment risk, and time-to-live.
In this article we place the two core architectures side by side — the traditional Secure Email Gateway (SEG) and the modern API-based (ICES) approach — and clearly explain what each does in which scenario.
1. Two Architectures, Two Different Philosophies
Secure Email Gateway (SEG) — "Change the Route"
A traditional SEG changes the delivery route of email. Your domain's MX record is set so that email is routed to an external gateway first. It's scanned there, and if clean, delivered to Microsoft 365 or Google Workspace. In other words, the gateway is a guard standing in front of your mailbox.
API-Based / ICES — "Connect Alongside"
ICES (Integrated Cloud Email Security) never changes the MX record. Instead, it connects to your mail platform from the inside via the Microsoft Graph API or Google API. It analyzes email as it arrives in the mailbox (and, where needed, before it arrives). So it doesn't stand in the middle of the route like a gateway; it embeds inside the platform.
2. Side-by-Side Comparison
| Criterion | SEG (Gateway) | API / ICES |
|---|---|---|
| MX record change | Required | Not required |
| Delivery latency | Yes (seconds) | None (minimal even in inline mode) |
| Internal phishing (post account takeover) | Can't see it — email never passes the gateway | Sees it — all inbound and outbound email is scanned |
| Deployment time | Days/weeks (MX, connectors, rule migration) | Minutes (API connection) |
| Reversibility (false positives) | Email gets stuck at the gateway | Monitor mode never intervenes; detect & remediate pulls it back |
| Relationship to existing Microsoft/Google protection | Usually replaces it | Adds alongside (layered) |
| Collaboration platforms (Teams, SharePoint, OneDrive, Slack) | Out of scope | Covered by the same integration |
3. The Real Differentiator: Who Can See Internal Phishing?
This is the SEG architecture's most critical blind spot. When a user's account is taken over, the attacker sends phishing from that user's inbox to internal colleagues or customers. Because this email originates inside your domain, from an authenticated account, it never visits the gateway at the MX — the gateway only sees mail coming from outside.
That's exactly what the logistics company in the intro experienced: the SEG scanned inbound threats but never saw the phishing going from the compromised internal account to customers. An API-based solution catches this scenario because it sees all inbound and outbound traffic from inside the platform.
4. Delivery Speed and MX Risk
Because SEG deployment changes the MX record, it creates two side effects:
- Latency: Since every email is scanned at the external gateway and then relayed, delivery can lag by a few seconds. In busy environments this difference is noticeable.
- Single-point risk and configuration complexity: MX, connectors, the SPF include chain, and settings like MTA-STS must all be re-architected around the gateway. A misconfiguration can halt the email flow entirely.
In the API-based approach, none of these risks exist because the MX is untouched. Email reaches Microsoft/Google directly as always; the security layer runs in parallel.
5. Where SEG Still Makes Sense
To be fair, SEG isn't a dead technology. It can still be preferred when:
- You run an on-premise Exchange server and haven't moved to the cloud.
- Very specific compliance scenarios restrict API access by corporate policy.
- A multi-layered approach calls for an additional external filter alongside an API solution.
But for the vast majority of cloud-based organizations using Microsoft 365 or Google Workspace, the API-based (ICES) approach is today's default choice due to lower risk, faster deployment, and internal-phishing visibility. Industry analysts (including Gartner) point to the weight in email security shifting toward ICES.
6. Where Does Check Point Harmony Email Stand?
Check Point Harmony Email & Collaboration runs in exactly this API-based (ICES) architecture:
- Connects via Microsoft Graph / Google API — the MX doesn't change.
- Scans inbound + outbound + internal email, plus Teams, SharePoint, OneDrive, Slack, and Dropbox content, with a single integration.
- Offers a gradual path from zero risk to production via Monitor / Detect & Remediate / Inline modes.
- Powered by ThreatCloud AI's 50+ engines; positioned as a Leader in the 2025 Gartner Magic Quadrant for Email Security.
To see what architecture means in practice, read our why Microsoft 365's built-in email security falls short and BEC / CEO fraud articles together.
Frequently Asked Questions
Does the API-based solution scan after the email reaches the mailbox? Isn't that late?
There are two options. In Detect & Remediate mode the email reaches the user and, if malicious, is pulled back within seconds. In Inline mode the malicious email is blocked before it ever reaches the inbox. It's chosen to your needs; most organizations follow the monitor → detect → inline order.
Is changing the MX record really that risky?
If it weren't risky, MX changes wouldn't be planned in overnight maintenance windows. A wrong connector or SPF chain can halt the email flow. The API approach eliminates this risk entirely because the delivery route never changes.
Can I use both architectures together?
Yes, some organizations use both for a layered approach. But in most Microsoft 365/Google Workspace environments, adding an API layer alongside the existing platform protection is both simpler and more effective for internal-phishing visibility.
Do I have to throw out my existing Secure Email Gateway?
No, not mandatory. But once you deploy an API solution, most organizations find the SEG no longer adds value and can be removed to reduce both cost and delivery latency. We make this decision together with the 14-day trial data.
What Should You Do Now?
Let's evaluate together the architecture and internal-phishing visibility of your current email security solution.
- Field Audit: We report your current architecture (SEG, API, or none) and your visibility gaps.
- 14-Day Check Point Trial (monitor mode): Without touching your MX, running alongside your existing protection, we measure internal and external threats.
About this article: Kinetik Bilişim is the Türkiye partner of Check Point Software Technologies at the Advanced Partner 2026 level and holds the Email Solution Specialization accreditation. Field examples are shared in anonymized form. Architecture definitions (SEG, ICES) align with industry standards.
