ICES vs Secure Email Gateway: Choosing Inline or Post-Delivery Email Protection

Choosing between an integrated cloud email security (ICES) tool and a secure email gateway (SEG) is really a choice about where in the mail path you accept risk: before delivery, after delivery, or both. A gateway sits on the MX record and decides inline; an ICES tool connects to the mailbox platform by API and pulls threats back after they land. Each architecture sees different traffic, fails in different ways and needs a different kind of trust. This guide goes beyond the overview in the Email Security Guide: it covers the threat model per option, the retraction gap, internal account takeover, overlap with native Google Workspace and Microsoft 365 controls, layered patterns and a worked decision.

Key takeaways

• The architecture decides the coverage. An MX gateway sees inbound and outbound internet mail but usually not internal mail; an API tool sees every mailbox, including internal messages from compromised accounts, but acts after delivery.
• Post-delivery means an exposure window. Every API remediation starts after the message is in the inbox, so measure time to retract, not just detection rate.
• The API tool is itself a high-privilege identity. Graph or Gmail API access to all mailboxes is a non-human identity to scope, monitor and offboard like any other.
• Native protection is the baseline, not the competitor. Decide what a third-party layer adds over the platform's own filtering, post-delivery purge and impersonation settings before buying either.
• Layering works only with clean trust between hops. Gateway in front plus API behind is supportable; badly chained filters double link wrapping, break authentication and raise false positives.

The short answer

If your mail is cloud-hosted and your main losses come from credential phishing, business email compromise (BEC) and compromised supplier or internal accounts, an API-based layer on top of well-tuned native protection usually fits better than a gateway. If you have hybrid or on-premises mail, many domains, heavy outbound requirements (encryption, enforced partner TLS, outbound DLP, archiving hooks) or regulatory reasons to filter before mail touches the tenant, a gateway still earns its place. Many large organisations run both, each with a defined job. The FBI's Internet Crime Complaint Center recorded 305,033 BEC incidents and $55,499,915,582 in exposed losses worldwide between October 2013 and December 2023, which is why the deciding question is usually how each option handles BEC, not commodity spam.

How each architecture works

Secure email gateway: inline on the MX path

The domain's MX record points at the gateway. It accepts the SMTP session, applies connection, reputation, authentication and content checks, rewrites links or detonates attachments, and relays clean mail to the mailbox platform over a connector. Outbound mail is usually smart-hosted back through it. Because it terminates the original SMTP session, it sees the true connecting IP and can reject before acceptance, which no post-delivery tool can do.

The cost is that the mailbox platform now receives mail from the gateway, not the sender. Microsoft documents that the message "adopts the source IP of the last hop", so the platform's own SPF, DMARC and spoof checks degrade unless you enable Enhanced Filtering for Connectors (skip listing) or trust the gateway as an ARC sealer. The tenant also keeps its own public endpoint, so the gateway is only a control if direct delivery is locked down.

ICES: API-connected, post-delivery

The ICES tool is granted application access to the mail platform (Microsoft Graph for Microsoft 365, the Gmail API with domain-wide delegation or an approved OAuth app for Google Workspace). MX stays pointed at the platform. The tool reads new messages as they arrive, scores them using mailbox history, relationships and conversation context, and moves, banners or deletes them through the API. Some products also offer an inline or pre-delivery mode through platform hooks; judge the mode you deploy, not the category name.

Microsoft's integration guidance is explicit about the trust involved: post-delivery scanning "typically requires granting the non-Microsoft service full access to mailboxes", and it advises understanding the vendor's security and support practices before granting it.

Side by side

Threat model: what each catches and misses

The pattern is consistent: a gateway is strongest against what can be judged from the message alone at the moment of arrival, and an API tool is strongest where judgement needs history, relationships or a second look later. Neither replaces Phishing-Resistant MFA or a finance process that verifies payment changes out of band, which the IC3 also recommends.

The retraction gap

Post-delivery remediation has three timers: time for the tool to see the message (event or polling latency), time to decide, and time for the API call to move or delete it across every recipient. During that window a user can open the message, click, reply or forward. Microsoft's own post-delivery feature, zero-hour auto purge (ZAP), shows the shape of the problem: its search "is limited to the last 48 hours of delivered email", users are not notified when a message is moved, spam is purged only if unread, and allow lists or mail flow rules can override it.

Questions to put to any API product, and to test in a proof of concept:

• Median and 95th percentile time to remediate: measured from platform delivery timestamp to removal, across a campaign hitting hundreds of mailboxes, not a single test message.
• Behaviour under throttling: what happens when the platform rate-limits the application during a large campaign, and whether the tool queues, retries and reports incomplete remediation.
• Read, replied and forwarded copies: whether it finds forwarded copies and replies, and whether it can tell you which users interacted before removal.
• Outage mode: if the vendor service is down, mail still flows (good for availability) but nothing is retracted; confirm alerting on lag.

Gateways have their own late-verdict problem: a link that was clean on arrival and malicious an hour later is caught only if the gateway rewrites links for time-of-click checks or can trigger a post-delivery purge through its own API integration.

BEC and internal account takeover

Once an attacker controls a real mailbox, mail from it is authenticated, sent from your tenant and often never crosses the MX gateway. Typical activity is internal spearphishing to finance or HR, replies inserted into live invoice threads, and inbox rules that hide replies or forward copies outside. An API tool sees this because it reads every mailbox, and some products correlate it with sign-in risk. A gateway sees only what is relayed through it outbound.

Three practical points follow. First, internal coverage is the single strongest argument for an API layer in cloud mail, and the reason to test it with a realistic internal BEC simulation. Second, detection is only half: removal must be paired with identity response (revoke sessions and tokens, reset credentials, remove rules), covered in the Business Email Compromise Response Playbook. Third, mailbox rule abuse is better caught from audit logs than from message content; see MITRE ATT&CK T1564.008 Hide Artifacts and MITRE ATT&CK T1534 Internal Spearphishing.

Overlap with native platform controls

Platforms are listed alphabetically. Both include pre-delivery filtering and admin tooling that partly overlap with each third-party category, so establish what the native baseline already does before adding a layer.

Google Workspace

Gmail's advanced phishing and malware protection groups settings under Attachments, Links and external images and Spoofing and authentication (domain spoofing, employee-name spoofing, mail claiming to be from your domain, unauthenticated mail). Each setting takes one of three actions: Warning (delivered with a banner), Move email to spam or Quarantine (admin quarantine, user sees nothing). By default Gmail shows warnings and moves untrustworthy mail to spam, and allow list settings do not override the Quarantine action. For post-delivery removal, Workspace admins can use the security investigation tool to delete matching messages from users' inboxes (Enterprise Plus, Frontline Plus and Education editions). An API-based layer for Google Workspace typically relies on domain-wide delegation or an OAuth app with Gmail scopes, which should be reviewed as described in the Google Workspace Domain-Wide Delegation Security Guide.

Microsoft 365

Exchange Online Protection and Defender for Office 365 provide pre-delivery filtering, Safe Links and Safe Attachments, and ZAP for post-delivery purge (malware and high confidence phishing quarantined whether read or not). Microsoft documents three integration patterns for third-party services: MX to the third party with Enhanced Filtering for Connectors, which it "fully supports"; Graph API post-delivery scanning; and in-and-out routing after Microsoft 365, which it "strongly" recommends avoiding because messages are counted twice and treated as new on return. Where a third party also rewrites links, Microsoft recommends disabling that link wrapping to avoid double wrapping with Safe Links. Defender for Office 365 accepts submissions from non-Microsoft reporting tools, which keeps one user reporting button. Configuration detail is in the Microsoft Defender for Office 365 Configuration Guide.

Layered architecture patterns

For pattern C, lock the tenant so it only accepts mail from the gateway, otherwise attackers deliver straight to the platform endpoint; the Email Security Guide covers the connector settings. Microsoft also warns that the false positive rate rises as more products are added and that no number of layers reaches 100 percent protection, so every extra layer needs a named job.

Where identity fits

An ICES deployment creates one of the most powerful non-human identities in the tenant: an application that can read and change every mailbox without a signed-in user. Govern it accordingly.

• Scope it: in Exchange Online, RBAC for Applications can assign roles such as Application Mail.ReadWrite (create, read, update and delete, without send) to a service principal with a management scope or administrative unit. Entra consent and RBAC grants are additive, so an unscoped Entra Mail.ReadWrite grant cancels the scoping; remove it. Verify with Test-ServicePrincipalAuthorization, and allow 30 minutes to 2 hours for changes to apply.
• Monitor it: alert on new credentials added to the application, consent changes and unusual API volumes; see Microsoft 365 Application Access Policies and RBAC for Applications Guide.
• Offboard it: on exit, remove consent, service principal and any spoof override or allow entries added for the product.

The gateway has its own identity surface: admin consoles, connector certificates and any smart-host credentials. See Securing the email security gateway itself.

Decision criteria

1. Where does mail live? On-premises or hybrid servers favour a gateway; fully cloud-hosted mail makes an API layer viable.
2. What do your incidents show? If losses come from BEC, supplier compromise and internal phishing, weight internal visibility and behavioural context. If they come from malware and mass phishing, weight inline blocking.
3. Do you need outbound enforcement? Per-partner enforced TLS, outbound encryption and outbound DLP at scale still point to a gateway or the platform's native outbound features.
4. Can you accept a retraction window? If policy requires that certain content never reaches a mailbox, only pre-delivery controls meet it.
5. Can you govern a tenant-wide application? If not, fix app governance first or choose a product that supports scoped permissions.
6. Who will tune it? Small teams get more from tuned native presets plus one well-run layer than from three layers nobody owns.

Worked scenario: a 4,000-user professional services firm

The firm runs Microsoft 365, has a gateway on MX that renews next quarter, and had two incidents last year: a partner's account compromised by an adversary-in-the-middle phishing kit, followed by internal invoice fraud from that mailbox. The gateway saw neither the internal mail nor the inbox rule that hid replies.

1. Baseline: the team applies the Strict preset to finance and partners, enforces DMARC p=reject on all domains, and confirms the tenant only accepts inbound mail from the gateway.
2. Proof of concept: an API layer runs in detect-only mode for 30 days with scoped Application Mail.ReadWrite. The team measures internal threats found that the gateway and native filtering missed, false positives per 1,000 users, and remediation time during a simulated campaign.
3. Decision: internal BEC detections and a 95th percentile remediation time within the agreed target justify the API layer. Outbound partner TLS and encryption are still needed, so the gateway is kept but its link rewriting is turned off in favour of Safe Links, leaving a single wrapping layer.
4. Identity response: the API tool's internal BEC alerts are wired to session revocation and rule removal in the identity platform, and finance adopts call-back verification for bank detail changes.

How to implement

1. Inventory the path: MX records, connectors, smart hosts, every system that rewrites links or adds banners, and every bypass rule.
2. Tune native first: preset policies, impersonation protection for executives and finance, DMARC enforcement, a single user report button.
3. Pilot in monitor mode: API tools in detect-only on a pilot group; gateways with a test domain or a subset of recipients before MX cutover.
4. Fix trust between hops: skip listing or trusted ARC sealers for a front gateway, remove SCL -1 bypass rules, and keep one link-rewriting layer.
5. Enable remediation in rings: automatic removal for high confidence verdicts first, banners for lower confidence, then widen.
6. Roll back cleanly: for a gateway, keep the previous MX and connector settings documented with low DNS TTLs during cutover; for an API tool, disable remediation, then revoke consent and remove the service principal and any overrides.

Detection and measurement

• Time to remediate: median and 95th percentile from delivery to removal for API actions, and ZAP actions where Microsoft reports them in Threat Explorer's Additional action column.
• Clicks before removal: users who opened or clicked a message later remediated, per campaign.
• Internal threats found: confirmed internal or supplier-account phishing caught per month, the metric that justifies an API layer.
• False positives per 1,000 users: tracked per layer, since every added product raises the rate.
• Bypass attempts: messages that reached the tenant without passing the gateway, from message trace.
• Application health: API errors, throttling and remediation backlog for the ICES application.

Message trace queries for these measures are covered in the Email Gateway and Message Trace Detection Guide.

Common failure patterns

• Gateway with an open back door: MX points at the gateway but the tenant accepts direct delivery, so attackers skip it.
• Bypass rules instead of skip listing: spam filtering bypass for gateway IPs, which Microsoft notes also stops ZAP acting on high confidence phishing in that set-up.
• Double link wrapping: two products rewriting URLs, breaking time-of-click analysis and confusing users and investigations.
• Unscoped API consent left after a trial: a tenant-wide mail application from a proof of concept nobody removed.
• Detection without identity response: internal BEC messages removed while the compromised session and forwarding rule remain.
• Stale overrides after exit: spoof allow entries and connector exceptions added for a product that has gone.

Framework mapping

Practitioner checklist

• Map every hop in the inbound and outbound mail path, including systems that modify messages.
• Lock the tenant to accept inbound mail only from the gateway if one is on MX.
• Use skip listing or trusted ARC sealers, never spam filtering bypass rules, for a front gateway.
• Keep exactly one link-rewriting layer.
• Scope the ICES application's mailbox permissions and remove unscoped tenant-wide consent.
• Measure median and 95th percentile time to remediate during a realistic campaign test.
• Test internal BEC detection with a simulated compromised account before buying.
• Wire internal compromise alerts to session revocation and mailbox rule removal.
• Keep one user report button and route submissions to every layer that needs them.
• Document rollback, including overrides to remove when a product leaves.

Standards and references

• Microsoft Learn: Integrate non-Microsoft email security services with Defender for Office 365
• Microsoft Learn: Zero-hour auto purge in Defender for Office 365
• Microsoft Learn: Enhanced Filtering for Connectors in Exchange Online
• Microsoft Learn: Configure trusted ARC sealers
• Microsoft Learn: Role Based Access Control for Applications in Exchange Online
• Google Workspace Admin Help: Advanced phishing and malware protection
• Google Workspace Admin Help: Investigate reports of malicious emails
• FBI IC3: Business Email Compromise public service announcement
• NCSC: Email security and anti-spoofing

Related NHI Mgmt Group resources: Email Security Guide, Business Email Compromise Response Playbook, Microsoft Defender for Office 365 Configuration Guide, Google Workspace Security Guide, Email security gateway health check.