How AI helps detect phishing emails
Learn how email security combines authentication, behavioral analysis, machine learning, link inspection, and campaign data to explain suspicious messages.
You are triaging an email from a new sender who claims that a shared document is waiting for review. SPF, DKIM, and DMARC pass. The message contains no malware, and its first link points to a legitimate cloud service.
A few redirects later, the recipient reaches a fake Microsoft 365 sign-in page. No signal proved phishing on its own. The risk became clear only when the sender, request, relationship, infrastructure, and final destination were viewed together.
That is the value of AI-assisted phishing detection. It helps connect weak signals and explain why a message differs from normal email. It does not replace authentication, scanning, policy, or analyst judgment.
Start with the whole detection pipeline
Phishing detection is not one model reading an email and deciding whether it looks suspicious. A mature system combines several types of analysis:
- Deterministic checks parse headers and evaluate SPF, DKIM, DMARC, and policy.
- Threat enrichment expands links, checks reputation, and analyzes files and pages.
- Behavioral models compare senders, recipients, infrastructure, and past activity.
- Language and vision models examine requests, attachments, images, and QR codes.
- Correlation and policy combine the evidence into a verdict and response.
Each layer answers a different question. Authentication can expose unauthorized spoofing, while reputation can identify known infrastructure. Sandboxes inspect files, and machine-learning models can find patterns across relationships and campaigns.
Microsoft Defender for Office 365 documents one example of this layered approach. Its protections include spoof intelligence, impersonation protection, mailbox intelligence, adjustable phishing thresholds, and campaign analysis. AI connects evidence; it does not replace the controls that produce it.
How the signals combine
When you review an AI-assisted verdict, look for evidence from each relevant layer. A score without supporting telemetry gives you little to investigate.
Sender identity
Compare the display name, From, Reply-To, Return-Path, authentication
domains, and sending infrastructure. Then check whether those identities tell
the same story.
A message claiming to come from Microsoft support may pass authentication. The authenticated domain may still belong to an unrelated organization controlled by the attacker. Authentication proves control of a domain, not the identity suggested by the display name.
Communication history
Compare the sender with previous conversations involving the recipient and your organization. Useful questions include:
- Has this sender contacted the recipient before?
- Is this domain associated with the company named in the message?
- Does the sender normally contact this team?
- Does this sender usually make this type of request?
- Is the message arriving through familiar infrastructure?
Relationship data can expose impersonation that authentication alone misses. Microsoft Defender for Office 365, for example, uses mailbox intelligence as part of its impersonation protection.
Requested action
Language models and other classifiers can examine what the sender wants the recipient to do. Keywords such as "password," "invoice," and "urgent" are weak signals because legitimate messages use them every day.
Focus on the complete request. A phishing message may ask the recipient to:
- Sign in through an unfamiliar page.
- Open or enable content in a document.
- Approve an OAuth application.
- Scan a QR code.
- Send sensitive information.
- Bypass an established verification process.
- Move the conversation to another address or messaging service.
Links, files, and visual content
The visible URL is only the start of the investigation. Inspect the registered domain, redirect chain, final page, hosting provider, downloadable files, and relationship between the sender and destination.
Attachments need the same treatment. A PDF may contain a link, an image may contain a QR code, and an HTML attachment may recreate a sign-in page without placing an obvious phishing URL in the original message.
Safe Links in Microsoft Defender for Office 365 illustrates this layered approach. It scans URLs during mail flow and can check them again when a recipient clicks.
Campaign activity
One message may contain only a few suspicious signals. Similar messages can reveal repeated subjects, templates, infrastructure, redirect patterns, attachments, target roles, and delivery timing.
This wider view can connect a low-confidence message to a coordinated campaign. It also gives you scope: who received the messages, who interacted with them, and which infrastructure needs containment.
How a verdict comes together
Consider an email with the following characteristics. The details appear ordinary until you compare them:
Display name: Microsoft 365 Support
Sender: notifications@account-review.example
Subject: Shared document requires verification
Authentication: SPF pass, DKIM pass, DMARC pass
Link text: Review document
Initial destination: Legitimate cloud-hosting service
Final destination: Microsoft 365 credential page on an unrelated domain
Authentication passes because the attacker controls and has correctly configured the sending domain. The cloud-hosting service is legitimate, but the URL redirects the recipient elsewhere. The message itself contains no malware.
No item proves phishing by itself. Together, the signals tell a consistent story:
- The sender has no established relationship with the recipient.
- The display name claims an identity that the domain does not support.
- The message requests authentication through an unexpected workflow.
- The final destination does not match the claimed organization.
- The same infrastructure appears in messages sent to other employees.
AI can help correlate these signals, but the result must remain explainable. An analyst should see the headers, relationship history, redirect chain, and campaign evidence behind the verdict rather than receiving only a "phishing" label.
Why a clean verdict can change after delivery
The delivery verdict is a snapshot based on the evidence available at that time. An attacker can weaponize a destination later, activate a redirect after delivery, or reuse infrastructure that had no malicious reputation during the first scan.
New campaign evidence can also change the assessment after related messages reach other recipients. Post-delivery detection should rescan, reclassify, and contain messages when that evidence appears.
Microsoft's zero-hour auto purge documentation describes how the service retroactively detects and neutralizes phishing, spam, and malware in cloud mailboxes. Its email search covers the previous 48 hours, which makes the response window clear rather than leaving it vague.
What AI cannot decide on its own
An AI score is evidence, not proof. Models can miss new techniques or overvalue a weak signal, and their accuracy can drift as sender behavior and attacks evolve.
Your detection process should account for these limits before it automates a response. Use the following checks:
- Confidence is not certainty. Define which actions require analyst review.
- Explanations need evidence. Tie every reason to headers, content, telemetry, or relationship data rather than accepting generated prose.
- Performance needs local testing. Measure false positives and false negatives against reviewed messages from your own environment.
- Models need monitoring. Track changes in verdict quality, sender patterns, and analyst overrides over time.
- High-impact actions need policy. Let deterministic rules control quarantine, account response, and other sensitive actions.
These checks make AI useful without making it the final authority. They also give security engineers measurable requirements and give analysts a clear path to challenge an incorrect verdict.
What analysts should investigate
When a system flags possible phishing, review the evidence rather than trusting the score alone. Start with these questions:
- Do the visible sender,
Reply-To,Return-Path, and authenticated domains align? - Does your organization have a real communication history with the sender?
- What is the complete redirect chain behind every link?
- Does the final page request credentials, consent, payment, or sensitive data?
- Is text hidden in HTML, images, attachments, or alternative MIME parts?
- Were similar messages delivered to other recipients?
- Did anyone click, sign in, approve an application, or download a file?
- Did the sender's behavior change from previous conversations?
No single signal proves phishing. A new sender can be legitimate, failed authentication can have an operational cause, and an unusual request may be genuine. Base the verdict on how the signals support or contradict one another.
Connect the signals and show the evidence
Effective phishing detection combines identity, relationship, intent, destination, campaign, and post-delivery evidence. AI and machine learning can connect signals across messages, but only when the rest of the detection pipeline collects them.
The goal is not to replace your judgment with a model. It is to show you what is different, why it matters, and where to act before the recipient becomes the final detection layer.
