Classical spam and phishing filters work with reputation, RBLs, SPF/DKIM/DMARC checks, and content rules. They are necessary, but against 2026's phishing quality they don't suffice: the mail comes from a compromised, valid domain, is DKIM-signed, has clean SPF, and the text is in flawless German without typos. Exactly here is where LLM-based classifiers step in.
What an LLM Recognizes in a Mail That a Regex Doesn't
- Tone anomalies: "Accounting needs an urgent transfer of €87,500 today to the following IBAN" – semantically aligned with business email compromise (BEC), not catchable via keywords.
- Reply-chain manipulation: a fabricated mail history is flagged by the LLM as "appears artificially constructed".
- Pseudo-branding: "We have detected unusual activity on your account" with Microsoft layout, but subtly off language tone.
- Pressure & urgency patterns: "please immediately", "strictly confidential, do not tell anyone" – psychological triggers awareness training discusses.
- Out-of-context attachments: an attachment in a mail conversation whose history has no relation to the attachment topic.
Why Local LLM (Ollama) Instead of Cloud API
Pushing mails through a cloud LLM API is a GDPR DPIA with a clear answer: no. Not even when the provider offers an EU region. Hence: local LLM via Ollama with an optimized model (Llama 3 or smaller BERT variants):
- Data sovereignty: no mail content leaves the infrastructure.
- Offline-capable: the mail filter stays available even when the internet is down.
- Cost: no per-token pricing.
- Reproducibility: model versions are pinned; a mail verdict today is the same tomorrow (unlike "GPT-4 update kills consistency").
How the Integration into the Mail Pipeline Looks
Inbound mail goes through the usual pipeline (RBL, SPF/DKIM/DMARC, hash reputation, ClamAV, YARA, CAPE sandbox). When the mail is "clean" up to this point but specific heuristic triggers fire (new sender, external sender with internal recipient action, attachment type Office maldoc), the mail runs through the LLM:
- Mail body and subject are sent via Ollama API to the local model.
- Prompt asks: "Classify this mail – legitimate, suspicious, phishing, BEC. Justify in one sentence."
- Output is returned structured (JSON with verdict + confidence + reasoning).
- On verdict ≠ "legitimate" the mail lands in quarantine with the LLM reasoning as the justification display for the operator.
False Positive Tuning
Three mechanisms keep the FP rate manageable:
- Confidence threshold: only verdicts above 75 % confidence count as quarantine triggers; the rest is forwarded with tag "LLM-uncertain".
- Sender reputation: an established sender (over 6 months of mail traffic without complaints) gets a bonus.
- Manual override: operator can permanently whitelist a specific sender/recipient combination.
Performance Reality
Llama 3 8B on an RTX 4090 manages around 5–8 mails per second with 200 ms latency. At a typical mid-market load of 5,000 mails/day (≈ 0.06 mails/sec on average) this is massively over-dimensioned – but fits morning peaks. CPU-only is possible, but latency rises to 2–4 s per mail.
Compliance Mapping
LLM-based classification explicitly covers requirements from:
- NIS-2 Art. 21(2)(b): measures for incident detection.
- BSI IT-Grundschutz APP.5.3: additional filter stages for email security.
- ISO 27001 A.5.7: threat intelligence – detection depth as evidence.
Conclusion
LLM-based phishing classification is the differentiator in 2026 between "spam filter sorted by gut feeling" and "semantic understanding of the mail". Run locally (Ollama) it's GDPR-compliant and reproducible. In the SecTepe.Comm mail pipeline it's an optional extension – those who enable it typically see 30–50 % more phishing detections at marginally higher FP rate.