- Rule-based filters catch known-bad senders and domains; AI models catch never-seen-before lures, look-alike domains and business email compromise text that carries no link or attachment.
- Two integration models exist: an inline secure email gateway that scans before delivery, and an API-based layer that scans continuously inside Microsoft 365 or Google Workspace after delivery and can retract a message post-click.
- Expect a tuning period of several weeks before quarantine decisions can be trusted, because the model has to learn what normal traffic looks like inside that specific tenant.
- Assessors check SPF, DKIM and DMARC enforcement, phishing simulation click and report rates, and the reporting-to-tuning feedback loop before they care which AI engine is running.
What the AI layer actually adds
A phishing email that has never been seen before will not appear on any reputation list. That is the gap AI-based detection is built to close, through a handful of distinct techniques stacked together rather than one model doing everything:
- Natural language classifiers score the text of a message for urgency, authority and financial-request patterns that show up in business email compromise, even when there is no malicious link or attachment to sandbox.
- Computer vision models render embedded images and linked landing pages, then compare them against known brand assets to catch logo and login-page impersonation that text analysis alone would miss.
- Sender-recipient graph analysis builds a relationship history for every mailbox and flags a first-time sender claiming to be the CFO, or a reply-chain that suddenly changes the reply-to address.
- URL and attachment detonation opens links and files in an isolated environment to observe behaviour before a user ever gets the chance to click.
Gateway scanning versus API-based scanning
This decision shapes everything else about a deployment, and it is usually made by the mail platform already in use rather than by choice.
A secure email gateway sits inline on the MX record and scans mail before it reaches a mailbox. It can block a message outright, which is the strongest control, but it adds a hop to mail flow, becomes a single point of failure if misconfigured, and struggles with anything encrypted in transit or delivered through a platform-native channel like Microsoft Teams.
An API-based layer, built on the Microsoft Graph API or the Google Workspace API, does not sit in the mail flow at all. It reads mail as it lands and continuously afterward, which means detection is near-real-time rather than pre-delivery, but it can retract a message from every mailbox it reached, including forwarded copies, once it is confirmed malicious. It also requires granting a third-party vendor read and write access to every mailbox in the tenant, which is a permissions decision worth reviewing on its own terms before signing.
Platforms native to the mailbox, such as Microsoft Defender for Office 365, run inline and post-delivery detection from inside the same tenant with no MX change required. Third-party overlays like Mimecast and Proofpoint can run either model and typically add cross-tenant threat intelligence and brand-impersonation detection built from traffic across many customers, which a single-tenant native tool cannot match by design.
Generative AI has changed what the model has to look for
Grammar and tone used to be reliable phishing signals. A generative model can now draft a personalised, error-free email in seconds, referencing real names and real project details pulled from a LinkedIn profile or a leaked contact list. That removes the cues NLP classifiers were originally trained on.
Detection has shifted in response, weighting infrastructure and behavioural signals more heavily than text: domain registration age, SPF and DKIM alignment, whether the sending IP has ever contacted this organisation before, and whether the relationship graph between sender and recipient matches history. Two other patterns are worth naming specifically because they sit outside what most email-focused tooling was built to catch:
- QR-code phishing (often called quishing) embeds the malicious URL inside an image rather than as text, which requires OCR extraction before a URL scanner has anything to check.
- Voice-based follow-up to a text lure, sometimes using a cloned voice, moves the attack out of the email channel entirely once the initial message has established trust, which no email security control can see.
What decides whether a deployment actually performs
- Platform fit. A Microsoft 365 tenant already generates most of the signal a native tool needs; a mixed-platform environment or heavy inbound volume from third parties is where an overlay's cross-tenant intelligence earns its cost.
- DMARC posture first. AI detection improves sharply once authentication is enforced, because look-alike domains and compromised-account fraud become the primary remaining problem instead of one signal among many.
- The tuning window. A newly deployed model needs weeks of exposure to an organisation's actual vendor relationships, recurring newsletters and internal jargon before its quarantine decisions can be trusted without review.
- Licensing tier. Capabilities like attack simulation training, priority account protection and time-of-click link rewriting frequently sit in a higher tier than the base licence an organisation already holds, which is where budget conversations actually happen.
Where deployments go wrong
- False positive fatigue. An aggressively tuned model quarantines legitimate vendor invoices and newsletters often enough that users start ignoring warnings altogether, which defeats the control.
- Treating AI as the whole answer. The fastest detection loop in most organisations is still a trained employee reporting a suspicious email, with that report feeding back into the model. A tool with no user reporting workflow behind it is working with one hand tied.
- No retraction workflow. Catching a phishing email after delivery only helps if there is an automated process to pull it from every inbox it reached, including anything already forwarded internally.
- Assuming coverage that does not exist. SMS phishing, WhatsApp-based social engineering and voice phishing sit outside almost all email-focused AI tooling entirely, and a security programme that only measures email metrics will miss them.
What assessors and auditors actually check
An assessor does not ask whether an organisation owns an AI phishing tool. They ask for SPF, DKIM and DMARC configured and at enforcement first, because that is the control that stops the largest share of spoofed-domain attacks before AI is ever relevant. Beyond that they expect a documented phishing simulation programme with tracked click and report rates over time, a defined incident workflow for reported phishing, and evidence that lessons from real incidents get folded back into detection rules or training content rather than filed and forgotten. Simulation and awareness metrics from a programme like KnowBe4 sit alongside the detection layer in that evidence set. Neither one substitutes for the other.
The decision rule
An organisation already on Microsoft 365 with Defender for Office 365 Plan 2 or E5 licensing should extend what is native before buying an overlay; the signal and the licence are both already there. An organisation running mixed platforms, or absorbing heavy inbound volume from third parties and partners, gets more from an overlay's cross-tenant detonation and brand-impersonation detection than a single-tenant tool can offer. Either way, fix DMARC enforcement and connect phishing reporting into a feedback loop before spending time comparing which AI engine claims the higher detection rate. The engine matters less than whether the organisation acts on what it flags.
