Integrated cloud email security (ICES) is a type of email protection that connects to a cloud mail platform, such as Microsoft 365 or Google Workspace, through the platform’s application programming interface (API) instead of sitting in the path that mail travels. Because it is connected to the mailboxes themselves, it can read messages, learn normal communication patterns and remove threats, including ones found after delivery. The common thread across ICES products is that API-based integration; detection methods and extra features differ from vendor to vendor.
At a glance
- ICES connects to cloud mailboxes through the mail platform’s API, usually with no change to MX records.
- It typically works as an extra layer on top of the platform’s built-in filtering.
- Many products focus on threats that slip past traditional filters, such as impersonation, business email compromise (BEC) and account takeover.
- Most can pull a malicious message out of every mailbox that received it, often automatically.
- Coverage of chat and file-sharing apps in the same suite varies by product.
What problem it solves
Cloud mail platforms already filter spam and known malware, yet targeted phishing and fraud still get through. The emails that cause the most damage often have no malicious link or attachment at all: a message that looks like it comes from the CFO asking for a wire, or a supplier “updating” bank details. Rules that look for known-bad content struggle with these.
A traditional secure email gateway (SEG) sits in front of the mail service, which means rerouting mail flow, and on its own it typically inspects a message once, on the way in. When something bad is discovered later, a gateway alone often can’t reach into mailboxes to remove it. ICES was designed for cloud mail: it sees internal messages as well as external ones, works with the data already in the platform, and can remove a message from mailboxes after the fact.
How it works
Connection. An administrator grants the ICES product permission to the mail platform through its API. Setup is often measured in minutes or hours rather than a mail-flow migration project, though the permissions granted are broad and deserve review.
Learning normal behavior. Many products build a picture of who usually emails whom, writing style, typical senders and usual login patterns. Messages that break the pattern, such as a first-time sender using a lookalike domain and asking for payment, are flagged even without a known-bad indicator.
Detection. Products combine that behavioral analysis with link and attachment scanning, sender checks based on email authentication results, and threat intelligence. Methods and accuracy vary by vendor.
Action. Depending on the product and its settings, suspicious mail is moved to quarantine, labeled with a warning banner, or removed from every mailbox that received it. Some products scan just after delivery; others hook in so the message is checked before the user sees it.
Reporting and user input. Many tools let users report suspicious messages with one click, feed those reports into detection, and give administrators a single view of incidents. Some tie this into security awareness training.
When it matters for buyers
- When phishing keeps getting through native filtering. ICES is a common next layer for organizations already on Microsoft 365 or Google Workspace. See our secure email gateway overview for the wider set of email security options.
- When BEC or payment fraud is the main worry. Behavioral detection is aimed at exactly these messages.
- When a gateway contract is up for renewal. It is a natural moment to decide whether to keep the gateway, replace it, or add ICES alongside.
- When the team is small. Automated removal across all mailboxes saves time compared with manual searches.
- When cyber insurers ask about email controls. Email is a frequent question on applications.
Questions to ask vendors
- Which mail platforms and which license tiers do you support?
- What API permissions do you need, and can we review exactly what data you access and store?
- Do you scan before the user sees the message, or after delivery, and how long is the window?
- What do you do with internal email between our own users?
- How do you detect impersonation and payment fraud that has no link or attachment?
- Which of the mail platform’s native features do you expect us to keep enabled?
- Do you cover chat or file-sharing apps in the same suite, and is that included in the price?
- How are false positives handled, and who can release a quarantined message?
How it differs from a secure email gateway
A secure email gateway sits in the mail flow: your MX records point to it, it inspects each message before passing it to the mail service, and it can apply routing, encryption and data-loss rules on the way out. ICES sits beside the mail platform and works through its API, without rerouting mail, and can act on messages that are already in mailboxes. Gateways have the advantage of inspecting before delivery; ICES has the advantage of seeing internal mail and cleaning up after the fact. Some organizations run both, some replace the gateway with native filtering plus ICES, and the right answer depends on which gateway features you actually use.