Most email security purchases are decided on detection claims that cannot be compared, while the costly attacks arrive with no link or attachment for any filter to catch. Business email compromise alone accounted for 24,768 complaints and $3,046,598,558 in reported losses in the FBI's IC3 2025 Internet Crime Report. Buyers now choose between three architectures, a secure email gateway (SEG) in the mail path, an API-based integrated cloud email security (ICES) product connected to the mailbox platform, or the platform's own native protection, and often combine them. This vendor-neutral buyer's guide is for security, messaging and procurement teams writing requirements, running an RFP or replacing a gateway. It covers what to define first, the criteria to score, the questions and red flags that separate products, and a proof of concept with measurable results. For the underlying controls, see the Email Security Guide.
Key takeaways
- Pick the architecture before the product. Gateway, API-based and native protection act at different points in the mail flow, see different mail and fail in different ways.
- Test for attacks without payloads. BEC, vendor impersonation and callback lures carry no malicious link or file, so judge detection of behaviour and context, not only URL and attachment verdicts.
- Remediation after delivery is part of detection. Ask how fast a product finds and pulls a message from every mailbox once one user reports it or a verdict changes.
- The API connection is a privileged non-human identity. Most API-based products need application permission to read and write mail in all mailboxes; score how that access is scoped, held and monitored.
- Measure in your own tenant. Run a proof of concept on live mail and your own reported phish, and decide pass criteria before the first demo.
Define requirements
Write these down internally before speaking to vendors:
- Mail platform and routing: cloud, hybrid or on-premises mailboxes; number of accepted domains; current MX records, connectors, journaling and archiving; any outbound smart host.
- Threat profile: where your losses and near misses came from: credential phishing including adversary-in-the-middle session theft, payment fraud through supplier impersonation, malware attachments or QR code lures. See the Phishing Guide, the AiTM Phishing Guide and the Email Identity and BEC Guide.
- Channels beyond email: whether Teams, Slack or file-sharing links must be covered by the same policy and console.
- Outbound needs: DLP for regulated data, message encryption for external recipients, enforced TLS with named partners.
- Operations: who triages reported messages, SIEM and SOAR integration, and the staff time available for tuning.
- Data constraints: where message content is processed and stored, retention, and sub-processors.
| Question | Secure email gateway | API-based (ICES) | Native platform protection |
|---|---|---|---|
| Where it sits | In front of the mailbox platform; MX points to it | After the platform's filtering; Microsoft describes ICES as acting "as a secondary filter" | Inside Microsoft 365 or Google Workspace |
| MX change | Yes, plus connector lock-down | No; connected by API with admin consent | No |
| Internal (east-west) mail | Usually not seen | Seen, which matters for compromised internal accounts | Seen |
| Main risk | Direct delivery to the tenant bypassing it; broken DKIM if it rewrites messages | Gap between delivery and removal; broad mailbox permissions | Defaults and allow lists left untuned |
| Outbound strength | Strong: DLP, encryption, partner TLS, routing control | Often limited | Platform DLP and encryption |
| Ease of exit | DNS and connector changes | Revoke the app; quick | Not applicable |
A small or mid-sized organisation with cloud-only mail usually starts with native protection on its strict preset and adds an API-based layer if reported phishing and BEC losses justify it. Large, hybrid or heavily regulated organisations often keep a gateway for routing, outbound encryption and archiving, with native and API layers behind it. Two inline filters in series mostly add latency and false positives.
Evaluation criteria
Weight these to your requirements. An illustrative split is 35% detection, 20% remediation and reporting, 15% integration and identity, 15% outbound and authentication, 15% operations and data; adjust it rather than copying it.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| BEC and impersonation without links | Models normal sender, supplier and conversation behaviour; flags new bank details, look-alike domains, display name spoofs and compromised supplier accounts | Detection depends on URL or file reputation; only a keyword list for "invoice" or "urgent" |
| QR codes and image lures | Extracts URLs from QR images in the body and in attachments, then analyses them like any link | Images ignored; QR "support" only for the message body |
| Attachment sandboxing | Detonates documents, archives, HTML and disk images; handles password-protected files; clear verdict time | Static scanning only; long delivery delays with no policy choice |
| URL rewriting and time-of-click | Rescans at click time, covers links that change after delivery, handles links already wrapped by another layer | Delivery-time scan only; no answer on double wrapping |
| Post-delivery remediation | Pulls a message from all mailboxes within minutes, including after a verdict change or a user report; full audit trail | Manual search and purge; removal limited to a short window |
| User reporting integration | One report button; reports clustered with similar messages; feedback to the reporter; simulation reports separated | A second button; reports land in a shared mailbox with no triage |
| DMARC management | Parses aggregate reports, inventories legitimate senders, supports the RFC 9989 test mode and np tags | A dashboard that shows reports but offers no path to p=reject |
| Outbound DLP and encryption | Content inspection for regulated data, policy-based encryption, enforced TLS and MTA-STS support | Outbound treated as out of scope |
| Integrations | Alerts and remediation actions via API to SIEM and SOAR; identity signals such as risky sign-ins | Email-only console; exports by CSV |
| Platform security and data | Named processing regions, retention you control, SSO with enforced MFA, tenant audit log, independent assurance | Shared admin accounts; unclear sub-processors |
Mail flow and MX implications
A gateway in front of Microsoft 365 needs work that many deployments skip. Microsoft says to "Lock down your Exchange Online organization to only accept mail from your third-party service" using a Partner inbound connector with TlsSenderCertificateName (preferred) and RestrictDomainsToCertificate set to $True, and to use Enhanced Filtering for Connectors rather than a rule that bypasses spam filtering, because shared gateway IP addresses "might allow spoofed and phishing messages". A gateway that modifies messages without ARC sealing will invalidate DKIM signatures. If MX points elsewhere and a mail flow rule bypasses spam filtering, zero-hour auto purge (ZAP) does not act on high confidence phishing, and ZAP only searches "the last 48 hours of delivered email". Link wrapping by a gateway "might prevent Safe Links from processing links". Ask every vendor to show how its product coexists with your platform's own controls.
API permissions are a privileged non-human identity
An API-based product connects as an application, not a user. In Microsoft 365, the Exchange role Application Mail.ReadWrite "Allows the app to create, read, update, and delete email in all mailboxes without a signed-in user." In Google Workspace, domain-wide delegation means "the app has access to the data belonging to all of your users." That is mailbox-wide read and write consent held by a third party, the same kind of access abused in the Microsoft Midnight Blizzard breach and the Malwarebytes breach. Score how the vendor holds its credentials (certificates or federation rather than shared secrets), whether it requests send permissions it does not need, and whether its access can be scoped during a pilot. Exchange Online's RBAC for Applications can limit an app to a management scope or administrative unit, but an unscoped Entra grant alongside it "results in no effective resource scoping". See the SaaS and OAuth App Governance Guide.
Questions to ask vendors
- List every permission and scope your product requests, which are application permissions, and why each is needed. Do you need Mail.Send or equivalent, and can we run without it?
- How is your credential to our tenant stored, rotated and protected, and what would an attacker who compromised your platform be able to do in our mailboxes?
- Show detection of a vendor impersonation message with no link or attachment, from a real supplier domain that has been compromised.
- How do you extract and analyse URLs from QR codes in images and in PDF or Office attachments?
- What is your median time to remove a message from all mailboxes after a user report or a verdict change, and how far back can you search?
- How do you coexist with the platform's link rewriting, ZAP and user report button without double wrapping or duplicate reports?
- For a gateway: how do you prevent direct-to-tenant delivery, and do you ARC-seal modified messages?
- What outbound DLP and encryption do you provide, and how do external recipients open encrypted mail?
- Where is message content processed and stored, for how long, and is it used to train shared models?
- How is pricing counted (mailboxes, users, modules, outbound volume), and what does exit involve?
Red flags
- Detection rates quoted from the vendor's own test set with no way to reproduce them in your tenant.
- A requirement for Global Administrator or full mailbox send rights with no explanation.
- No coverage of internal mail or of messages already delivered.
- Removal that relies on a manual search by your administrators.
- A gateway deployment guide that skips connector lock-down or recommends bypassing platform spam filtering.
- DMARC "management" that never moves domains to enforcement.
- Vague answers on data residency, model training on customer mail or the vendor's own incident history.
Proof of concept
- Agree pass criteria first: detection and false positive targets, remediation time, admin effort per week. Weight them before any demo.
- Connect with least privilege: record every permission granted; in Microsoft 365, scope an API product to a pilot group with RBAC for Applications if the vendor supports it; in Google Workspace, domain-wide delegation reaches all users, so keep the trial short; name an internal owner and an expiry date for the connection.
- Run in monitor mode on live mail: two to four weeks, covering finance, executives, HR and a sample of general users, with the platform's own protection unchanged.
- Replay what got through: feed the last three months of user-reported and incident messages, including BEC, QR and attachment lures, through the product.
- Test remediation: report a delivered test message from one mailbox and time removal from all others; change a verdict and confirm retroactive action.
- Check mail flow and authentication: for a gateway, verify direct-delivery rejection, DKIM pass rates and ARC results after the change.
- Exercise operations: send alerts to the SIEM, run one automated response, and measure analyst time per reported message.
- Test the exit and roll back: revoke the app or restore MX, confirm access stops immediately, and obtain written confirmation of data deletion.
Score the trial on a few numbers you can keep tracking: malicious messages caught that existing controls missed, false positive rate per 10,000 messages, median time from first user report to removal from all mailboxes, share of reports resolved automatically, BEC attempts detected without a link or attachment, and percentage of your sending domains at DMARC p=reject.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Email Security Guide · Phishing Guide · AiTM Phishing Guide · Data Loss Prevention (DLP) Guide · SaaS and OAuth App Governance Guide