EMAIL SECURITY IS NO LONGER JUST AN EMAIL PROBLEM.

For a long time, the email-security architecture was relatively easy to understand. Mail came from the internet. A security layer inspected the sender, domain, links, attachments, reputation, content, and other signals. The message was blocked, quarantined, modified, or allowed through.

For many organizations, that layer became the secure email gateway sitting in front of Microsoft Exchange, Google Workspace, or another email platform. There is a reason that architecture became so common. It works.

Gateways remain useful for stopping spam, known malware, suspicious attachments, spoofing, and large volumes of commodity phishing before they ever reach the employee. The mistake would be assuming the job ends there.

THE TRADITIONAL MODEL WAS BUILT AROUND INSPECTION

Internet → Email Security Gateway → Microsoft 365 / Google Workspace → User

A message arrives. The security platform analyzes sender reputation, attachments, URLs, domain authentication, phishing signals, and policy. Make the decision quickly enough and the threat never reaches the user. That model still has enormous value.

But modern attacks increasingly exploit things that are difficult to judge from a single inspection at one moment in time. Business email compromise is among the most financially damaging forms of online crime because the attacker often appears to be a vendor, executive, customer, title company, or colleague the recipient already knows.^[2]

Microsoft observed approximately 10.7 million BEC attacks during the first quarter of 2026. Its analysis found that roughly 82% to 84% of initial BEC messages were generic outreach rather than explicit fraudulent transaction requests.^[1] A message can be technically clean and still be extremely dangerous.

THE SENDER CAN ALSO BE REAL

Spoofing is one problem. A compromised legitimate account is another. If an attacker takes control of a real employee, supplier, or partner mailbox, many historical trust signals become less useful. The domain can be legitimate, authentication can succeed, the sender may have communicated with the recipient hundreds of times, and the attacker may reply in an existing conversation.

At that point, the attack is no longer merely an email-filtering problem. It is also an identity problem. CISA notes that compromised email accounts can be used for phishing and exploit the trust around a legitimate persona.^[3]

THE PROBLEM OF TIME

Traditional email security can create the mental model that a message is either safe or unsafe when it arrives. Reality is messier. A URL that appears harmless at delivery can become malicious later. New threat intelligence can change the verdict. A previously unknown attack can become understood only after several messages have already entered mailboxes.

This is why post-delivery remediation has become important. Microsoft’s Zero-hour Auto Purge continuously applies updated intelligence to messages already delivered to Exchange Online mailboxes and can move or quarantine messages subsequently identified as phishing, spam, or malware.^[4]

NATIVE EMAIL SECURITY HAS ALSO GOTTEN MUCH BETTER

Microsoft and Google are not standing still. Defender for Office 365 includes anti-phishing, spoof intelligence, impersonation controls, automated investigation, click-time protection, and post-delivery remediation. Google Workspace provides native phishing and malware protections and advanced policy controls in supported editions.^[5][6]

The question should not be which third-party email security company has the longest feature list. It should be: what problem are we still failing to solve with the technology we already own? A security team should articulate the gap before purchasing another layer.

API-BASED SECURITY CHANGED WHERE THE CONTROL CAN LIVE

Cloud email created another architectural option. Rather than requiring every message to pass through a gateway before Microsoft 365 or Google Workspace, security products can connect directly to the cloud environment through APIs. They can examine messages already inside mailboxes, respond to user-reported messages, inspect internal traffic, correlate mailbox activity with account behavior, and remove messages after delivery.

That does not automatically make API-based security better. A pre-delivery control has one enormous advantage: the malicious message never reaches the inbox. A post-delivery control may gain richer context, but has to operate quickly enough that the employee does not interact with the attack before remediation occurs.

The more useful question is not gateway versus API. It is: where should prevention occur, where should detection occur, and where should remediation occur? Some platforms combine those approaches. Check Point’s Email Security documentation, for example, describes API-based inline protection alongside post-delivery modification and removal capabilities.^[8]

AI CHANGES THE ATTACK, BUT ALSO THE THING BEING ATTACKED

AI makes it easier to generate convincing language, personalize communications, translate attacks, automate infrastructure, and iterate against defensive controls. But AI assistants are now beginning to read email themselves. Malicious content can potentially manipulate the AI processing the email, not only the human recipient.

Microsoft has introduced prompt-injection protections in Defender for Office 365 for malicious instructions hidden in inbound email, while Google documents protections for malicious content and prompt injection when Gemini in Workspace interacts with content.^[5][7]

PHISHING IS ALSO MOVING AROUND THE CONTROLS

Attackers are not obligated to use the path our tools were designed to detect. Microsoft’s 2026 threat research documented increases in credential phishing, QR-code phishing, and CAPTCHA-gated campaigns. It also observed adversary-in-the-middle techniques intended to steal authentication sessions, not merely passwords.^[1]

Email security may detect the lure. Identity security has to protect the authentication. Browser and endpoint controls can affect what happens next. Financial controls can determine whether a convincing BEC request succeeds. The attack crosses domains. The defense increasingly has to as well.

SO WHAT ARE WE ACTUALLY BUYING?

Do not start with “Do we need to replace Proofpoint?” or “Should we buy an API email-security platform?” Start with where attacks are getting through: commodity phishing, impersonation, vendor compromise, internal account compromise, QR-code phishing, malicious attachments, credential theft, AiTM, post-delivery weaponization, user-reported campaigns, or data exposure after account takeover.

Different problems can justify different architectures. Then look at the operating model: how long does it take to investigate a reported phish, remove similar messages, recognize compromised accounts, understand internal communication, see vendor behavior, remediate automatically, and operate without adding another console?

What caught our attention is not that Material claims to catch phishing that other products miss. Every email-security company says some version of that. The more interesting point is where Material draws the boundary around the problem.

Material connects to Microsoft 365 and Google Workspace and treats the mailbox as part of a broader cloud workspace containing identities, sensitive information, files, authentication artifacts, and historical communications. Its public positioning combines inbound email detection and remediation with account-takeover controls and protection for information stored in mailboxes.^[9]

The mailbox is no longer just where the attack arrives. It is part of what the attacker wants to control. Other companies approach portions of this problem differently. That is why we would not assume there is one universally correct architecture.

WHAT WE WOULD VALIDATE BEFORE CHANGING EMAIL SECURITY

These are not reasons not to buy. They are questions worth answering before you do.