Most phishing detection advice is now actively harmful. Teaching users to look for typos and generic greetings made sense when phishing was a spray-and-pray operation running on bad grammar. That era is over.
Here's how modern AI phishing is actually constructed, what signals remain reliable, and how to implement detection logic that accounts for the current threat model.
How an AI Spear Phishing Email Gets Built
The workflow an attacker follows in 2026 is largely automated:
Step 1: Target reconnaissance
# Typical OSINT data sources for a targeted attack
sources = {
"linkedin": "job title, manager name, team structure, tenure",
"company_website": "email format (first.last@company.com), press releases",
"social_media": "recent posts, projects mentioned, travel",
"data_broker": "personal email, phone, home address",
"previous_breaches": "password patterns, security question answers"
}
All of this is publicly available or purchasable. A targeted attack on a finance manager will include their correct name, their CFO's actual name, and may reference a real business event pulled from a press release.
Step 2: Prompt engineering for the attack
The attacker doesn't write the email. They prompt a model:
The output is indistinguishable from a real internal email.
Step 3: Infrastructure
Lookalike domains are registered with realistic names (company-billing.com, companyfinance.io), SSL certificates acquired (free via Let's Encrypt — the padlock means nothing), and emails sent through legitimate SMTP infrastructure to pass basic spam filters.
What Traditional Detection Gets Wrong
The signals security training still teaches:
| Signal | Why It Fails Now |
|---|---|
| Typos / bad grammar | LLMs produce perfect prose |
| Generic greeting | OSINT provides correct names trivially |
| Unknown sender | Lookalike domains pass visual inspection |
| Suspicious links | Links go to legitimate sites that redirect |
| Urgency alone | Legitimate emails also have urgency |
None of these are reliable discriminators in 2026.
What Still Works: Authentication Layer Checks
SPF, DKIM, DMARC — these operate at the email infrastructure level and can't be faked without compromising the legitimate domain.
# Check authentication results for a received email
# Look for these headers in the raw message
# SPF: did the email originate from an authorized server?
Received-SPF: pass (google.com: domain of cfo@company.com designates
198.51.100.1 as permitted sender)
# DKIM: was the email cryptographically signed by the domain?
DKIM-Signature: v=1; a=rsa-sha256; d=company.com; s=selector1;
# DMARC: does the domain's policy require both to pass?
Authentication-Results: mx.google.com;
dkim=pass header.d=company.com;
spf=pass smtp.mailfrom=company.com;
dmarc=pass (p=REJECT)
A legitimate internal email from your CFO should pass all three. Any failure is a hard signal — not a soft one. Most attackers can't pass DMARC on the domain they're spoofing without compromising it directly.
Programmatic header parsing:
// Parse authentication results from email headers
function parseAuthResults(headers) {
const authHeader = headers['authentication-results'] || '';
return {
spf: authHeader.match(/spf=(pass|fail|softfail|neutral)/)?.[1] || 'missing',
dkim: authHeader.match(/dkim=(pass|fail|none)/)?.[1] || 'missing',
dmarc: authHeader.match(/dmarc=(pass|fail|none)/)?.[1] || 'missing',
};
}
function isAuthenticationSuspicious(authResults) {
const { spf, dkim, dmarc } = authResults;
// Any failure on a supposedly internal or financial email = flag
return spf !== 'pass' || dkim !== 'pass' || dmarc !== 'pass';
}
The Signal That Doesn't Depend on Content
Authentication checks require access to headers. The signal that works at the human layer — and that AI cannot defeat — is the request pattern.
Legitimate organizations have consistent behavioral signatures:
const PHISHING_REQUEST_PATTERNS = [
'wire transfer outside normal approval chain',
'request for credentials or MFA codes via email',
'urgency to bypass standard process',
'confidentiality instruction (do not tell X)',
'new payment method or vendor not in system',
'action requested on behalf of unavailable approver',
];
// The key insight: legitimate urgent requests
// arrive through established channels with context.
// Phishing creates the urgency in the email itself.
This pattern holds regardless of how the email is written. AI can generate perfect prose but cannot change the fact that a real CFO initiating a real wire transfer uses the company's actual payment system, not a direct email to a finance manager with a new bank account.
Building a Detection Heuristic
For teams building email security tooling or internal automation:
def phishing_risk_score(email):
score = 0
# Authentication failures (high weight)
if email.spf != 'pass': score += 40
if email.dkim != 'pass': score += 30
if email.dmarc != 'pass': score += 30
# Domain analysis
if is_lookalike_domain(email.sender_domain): score += 50
if email.reply_to != email.from_address: score += 25
# Request pattern signals (content analysis)
content = email.body.lower()
if any(phrase in content for phrase in [
'wire transfer', 'bank account', 'routing number'
]): score += 20
if any(phrase in content for phrase in [
'urgent', 'immediately', 'today only', 'close of business'
]): score += 10
if any(phrase in content for phrase in [
'keep this confidential', "don't mention", 'just between us'
]): score += 30
# High score = route to additional verification, not auto-block
return score
def is_lookalike_domain(domain, legitimate_domains):
from jellyfish import jaro_winkler_similarity
return any(
jaro_winkler_similarity(domain, legit) > 0.85
and domain != legit
for legit in legitimate_domains
)
The key design decision: high-risk emails should trigger an out-of-band verification requirement, not an auto-block. Auto-blocking has false positive costs; requiring phone verification for flagged financial requests has almost none.
The Defense That Defeats All Variants
Out-of-band verification: any email requesting financial action, credential changes, or process exceptions gets verified via phone call to a number already on record.
This rule is architecturally sound because it breaks the attack at the social engineering layer regardless of how convincing the email is. It doesn't matter how good the AI gets at writing emails — it can't intercept a phone call the target initiates to a known number.
The consumer version of this — what non-technical users should watch for — is at lucas8.com/how-to-spot-ai-phishing-email