AegisAI Perspectives · 066
Shortlist AI-native email security vendors by approach, ask each the same questions on access and removal, then test the final two on your own live mail.
Shortlist AI-native email security vendors in three passes: sort the long list by approach, put the same questions to each, then test the last two on your own mail, since no stack reaches 100 percent protection7. AegisAI reads each message for what it is trying to do; this guide judges any vendor, ours included, by the same criteria, and names no other vendor.
Write down what your platform already does. In Microsoft 365, a 90-day trial of Defender for Office 365 Plan 2 is available, so the baseline itself costs nothing to test3.
Sort the long list by approach: API-based, gateway, built-in platform controls, or managed service.
Send every vendor the same written questions from the sections below. Drop any vendor that answers with a demo instead of a document.
Check access before features. Graph API integration typically requires granting the service full access to mailboxes10, so security and legal read the permission list first.
Run the last two vendors in monitoring mode on the same live mail for 30 days.
Score the trial on three numbers: missed attacks caught, false positives per 1,000 legitimate messages, and hours from delivery to removal.
Some services authenticate and use the Microsoft Graph API to scan messages after they are delivered to mailboxes9. Others sit in the mail path: when the MX record points to a third-party filter, Microsoft strongly recommends Enhanced Filtering for Connectors12.
For what each method does to MX records and mail flow, read how to evaluate API based email security.
With application permissions, a Microsoft Graph app can access the mail of any user in a tenant13. On Google Workspace, Google advises admins to know and approve which third-party apps can access core services such as Gmail and Drive18.
Ask for the permission list in writing. A tool that only reports needs read access; a tool that removes mail needs write access, and you should know who grants it.
Zero-hour auto purge in Microsoft 365 acts on mail already delivered and searches only the last 48 hours of delivered email1.
Ask what happens to the forwarded copies and the replies.
In the Microsoft 365 Tenant Allow/Block List, block entries take precedence over allow entries6. A new allow or block entry starts working within 5 minutes. Block entries expire after 30 days by default and can be set to up to 90 days.
Ask each vendor for its precedence rule, its time to apply an override, and its default expiry.
Microsoft 365 already weighs evidence: a composite authentication failure does not directly cause a message to be blocked15.
Ask the vendor to show one real verdict where no single rule fired. Then ask what the user and the admin each see.
Microsoft lists a higher rate of false positives as a trade-off of adding more email security products8. With in-and-out mail routing, messages are counted twice in most Microsoft reporting tools, which hides the true volume.
Ask each vendor for its false positive rate with the denominator written next to it.
| Criterion | API-based | Gateway | Built-in platform controls | Managed service |
|---|---|---|---|---|
| Mail path | Reads mail through the platform API after delivery | MX record points to the filter | Inside the platform | Set by the tools the provider runs |
| Access granted | Mailbox permissions through the platform API | Mail passes through it in transit | Already part of the tenant | The access you grant the provider |
| Action after delivery | Removes mail from mailboxes with write access | Acts in the mail path before delivery | Auto purge on recent delivered mail | Depends on the provider's tools |
| Admin override | Vendor's own rule; ask for it in writing | Vendor's own rule; ask for it in writing | Tenant Allow/Block List | Provider's ticket or console |
| Reporting | Vendor console plus platform reports | Messages counted twice with in-and-out routing | Platform reports | Provider reports |
| Trial cost | Monitoring mode on live mail | MX change for the trial domain | Platform trial | Provider's onboarding |
Illustrative example, figures are fictional. A 1,500 mailbox company on Microsoft 365 starts with eleven vendors. Vendor A catches 31 of 38 attacks the current stack delivered and holds 60 legitimate messages out of 410,000. Vendor B catches 24 and holds 22.
AegisAI investigates every email for what it is trying to do, and removes the ones that fail from every mailbox they reached19. It reads mail through the Microsoft 365 or Google Workspace API after delivery, with no change to mail routing. It starts read-only and runs in monitoring mode first, and removal needs write access that the admin grants and can revoke. Every verdict comes with its reason in plain language, so the team can check it and share it.
Evaluate on your own mail, not on the vendor's samples.
Run the finalists side by side for 30 days. The Defender email security reports show 90 days of aggregate data and 30 days of detail data16, so export the baseline before the detail view rolls over. For a full buying framework, read how to evaluate email security vendors.
Ask for the mechanism and one verdict as proof.
Request one quarantined message from your trial with the signals that decided it. For how models read message intent, see how AI-powered email security works.
A tool is AI-native when its verdict comes from reading the whole message and its context, not from one rule firing. Microsoft 365 already weighs authentication as evidence rather than as a block.
Ask whether the vendor writes rules for each new attack.
Teams on Microsoft 365 or Google Workspace with no spare analyst time gain most. An API-based tool needs no MX change, and a gateway needs mail routed through it.
Teams with a working gateway can add an API-based layer beside it rather than replace it.
Measure what got through, not what got blocked.
Count the attacks users reported that the tool delivered. Then count the legitimate messages it held. Track the hours from delivery to removal for each confirmed attack.
Track three numbers each week of the trial, each from a named place.
On Google Workspace, pre-delivery scanning setting changes can take up to 24 hours to apply17, so start the clock a day after setup. To run the same three numbers against our own tool, see the demo page.
Sort the long list by approach, send every vendor the same written questions on access, removal, overrides and false positives, drop any that cannot answer in writing, then run the last two in monitoring mode on live mail for 30 days. Decide on missed attacks caught, false positives per 1,000 messages and hours to removal.
A demo runs on attacks the vendor picked, in a tenant the vendor built. A monitoring mode trial on your own mail answers those questions.
Each domain needs its own SPF record, because subdomains do not inherit the parent record. An AI-native layer reads what authentication cannot: the request inside a message from a sender that passes.
An API-based tool reads mail after delivery and can remove it with write access. Ask how far back it reaches. The Microsoft 365 baseline searches the last 48 hours of delivered email.
Run it for 30 days on live mail. That matches the 30 days of detail data in the Defender email security reports, so both tools are measured over the same window.
Start read-only and turn on removal only after the trial. Name the person who grants write access and the person who reviews removals. Write down how access is revoked. Overrides follow a precedence rule, and in Microsoft 365 block entries win over allow entries.
