Detection Layers

Brand Protection detects impersonation attacks that generic filters miss. Working from a brand list you curate, it covers the full range of impersonation tactics — from look-alike domains to display-name and subject-line spoofing — including CJK/Japanese native-script variants that Western-centric tools overlook.

The display-name and subject-line brand abuse that dominates real phishing gets caught. On live traffic, From-display-name spoofing alone out-volumes all domain-squatting techniques combined by ~40×.

Who's impersonating our brands? Are display-name attacks hitting us? What's the volume of CJK brand abuse?

Brand Protection answers these questions with a purpose-built detector that understands the tricks attackers use — and the language-specific variations that Western-centric tools miss.

Traditional brand protection watches domain registrars. Real phishing happens in the From display name and subject line — 'Support' as the display name with a random freemail domain, or 'Invoice: ACME Corp' in the subject with no brand reference in the sender.

These techniques out-volume domain squatting by 40×. Brand Protection catches them.

The brand a BEC crew spoofs most is the recipient's own. Brand Protection derives every recipient's company identity from their domain on the fly — no list to maintain — and flags senders who claim that identity without being it: latin spellings, digit-stripped forms, katakana transliterations, and unicode look-alike dressing included.

Precision comes from an exception tree, not optimism: mail from the organisation's own domain, its DMARC-aligned senders, operator-listed personal addresses and confirmed in-thread replies are all exempt — and the symbols score as a nudge that combines with other signals, so a real employee writing from a personal mailbox doesn't get nuked.

With the Vision module, a brand shown only in a message's images — a logo where no text filter can see it — reaches the same decision logic as text-based claims, with exactly the same exception tree. It scores as one combinable signal, not a model verdict.

A courier naming the retailer it delivers for is doing its job, not phishing — but whether a courier may speak for a retailer is a fact about the world, not about a message. An operator can mark a domain as authorised to name other brands; the permission only applies to mail that proves it came from that domain, and the suppression is never silent — the message records what would otherwise have been flagged.

At scale the console asks instead of assuming: when a sender names a brand not its own, the pair is put independently to two AI models from different vendors, and the sender is cleared only when both agree it has standing. A disagreement, a refusal or a failed call leaves the warning in place and puts the pair in front of a person — both answers side by side, in the models' own words. This was measured before it was built: on test sets from two different markets, the two models swapped places exactly, each vouching for fabricated relationships in the market the other knew — and the wrong answers carried the same confidence scores as the right ones. That is why no single model is trusted, why self-reported confidence decides nothing, and why bulk-mail platforms that send for anyone get no standing at all.

Your own vouch-or-refuse decisions outrank the models permanently and are recorded with who and why. A deployment that has been running for a year owns a brand-relationship list built from its own mail, in its own market — the thing nobody could have shipped to it.

Rspamd's built-in neural classifier, upgraded into a production-grade detector. It reads each message in context — combining the message text with a rich set of structural and behavioural signals — to make far sharper spam/ham calls than a text-only model.

ROC AUC 0.998; false positives cut ~20× vs. Bayes and ~11× vs. the OSS text model at the same recall; ~4 ms/message; fully local; CPU-only; no data off-box. Trains online on the customer's own traffic. Multilingual (en/ru/CJK).

Those figures come from a held-out benchmark corpus. Your own numbers will differ: the Neural panel reports the live model's test AUC for the traffic it was actually trained on.

Can I do better than Bayes? What's the cost of this upgrade? Is it worth deploying?

The benchmark answers: at a fixed aggressive spam-catch rate, Premium neural lets through ~1 false positive for every 20 a Bayes-only setup would. For a busy system that's the difference between 'users trust the filter' and 'users check quarantine by hand.'

Generic ML classifiers see only message text. Premium neural reads the message in full context, combining content with a broad set of structural and behavioural signals. That added context is what separates good-enough accuracy from production-grade.

Spam increasingly hides its payload where text analysis cannot see it: the whole pitch is an image, a QR code, or a banner sliced into tiles. While a borderline message waits out its greylist window, the Vision worker extracts its images, decodes QR codes locally, and has a multimodal model describe what the images actually say — all off the scan path, inside the delay the sender already pays.

When the sender retries, the message is re-scanned with that description injected as synthetic text parts and URLs, so Bayes, URL rules and language detection finally 'read' the image — and a set of VISION_* symbols joins the verdict. Everything ships in shadow: the symbols start at weight zero and are promoted once their agreement looks right on your own traffic.

A composition trick — a banner sliced into tiles, a background image with text overlaid, a fake login box drawn in pure HTML with no image part at all — only reads assembled. For such messages the worker composes the mail the way a client would render it and screenshots the result, and that screenshot becomes the primary image the model analyses.

Rendering happens in an isolated sandbox: scripts never run, and remote content is never fetched by default — so a tracking pixel cannot tell a spammer their mail is being analysed. Renders cost local CPU, not model tokens.

Analysis is cached per unique image set for two weeks, so a blast of thousands of copies costs one model call, and a daily spend budget caps the rest. The deterministic signals — QR decoding, slicing detection — keep working even with the budget exhausted.

The module page shows the gate funnel (messages with images, passed the gates, analysed), spend against budget, and recent analyses with thumbnails — click one to see the full image the model received. All of it follows the console-wide time picker.

A dashboard over YARA rule scanning of message content and attachments, tiered by what a rule is looking for: malware, exploit, phishing, generically suspicious, and an allowlist tier that suppresses known-good matches.

Each tier reports hits and the percentage of those hits that ended in a reject, so you can see at a glance which tiers are earning their scan time.

A published YARA ruleset is mostly dead weight — a handful of rules do nearly all the work. The 'where it fires' table ranks rules on your live traffic by hits, rejects and reject rate, and names the source file each rule came from.

Every tier links through to Symbol Introspect, so a suspicious rule is one click away from its full operational profile.

An operator ruleset editor sits on the same page, appended to the rules shipped with the deployment. Unsupported YARA constructs are skipped rather than fatal, and an Audit pass tells you exactly which rules were skipped before you publish anything.

A test-scan panel compiles the shipped and draft rules together and scans a sample, so you can confirm a rule matches what you think it matches.

Operator-defined clustering rules group messages by shared characteristics: ASN, from-domain, header fingerprint, header order, or other lua_selectors. Clusters flag coordinated or botnet-like fanout with symbols CLUSTER_FANOUT, CLUSTER_REPUTATION, and CLUSTER_ANOMALY.

One-click actions let you block a cluster, capture it for analysis, or train fuzzy across all cluster members. Clusters drive Selector Grid rules — turn a cluster observation into a deployed scoring rule in one click.

Is this a coordinated attack? Which messages share this fingerprint? What's the scope of this campaign?

Clusters reveal patterns that span individual messages: a botnet sending from the same ASN across hundreds of domains, or a phishing kit with a distinctive header order.

The workflow flows from observation to action: Clusters detects a pattern, you verify it's abuse, click to build a Selector Grid rule from the cluster's selector, and ship it. Minutes from pattern detection to deployed rule.

Track reputation for senders and domains based on your traffic patterns. See which senders are problematic, which domains are legitimate, and identify emerging threats before they hit your filters.

The reputation panel shows a ranked list of senders and domains with key metrics: average score, spam/ham counts, spam percentage, and message volume. Sort by any column to find the worst offenders.

Every row carries Block and Allow buttons, split by target: on a domain row you can act on the URL domain or the envelope-from independently; IP rows block or allow the address. Each action appends one validated line to the matching operator map, idempotently — no duplicate entries, and the change is live on the next map poll.

Cold sales outreach is correctly signed, personally addressed, and mechanically identical to a receipt or a bank statement — reading the message harder does not separate them. One question does: have we ever dealt with this sender? The Correspondents tab keeps that answer: for every sender, when they first wrote, how often, over how many distinct days, and how their mail was treated — and, separately, which domains this installation has written to. A lookup box states the relationship in plain sentences.

A sender is identified by what they can prove, not what they write in a From line: a validated DKIM identity, an SPF-passing envelope and an unproven claim are three different identities whose histories are never mixed — so an impersonator cannot inherit the reputation of the brand it imitates. The same record read the other way is a warning: an unauthenticated message claiming a domain you actually correspond with is the exact shape of vendor impersonation and invoice fraud, and it is flagged as such.

A one-click backfill seeds the history from the scan records already in your analytics database, and can be re-run safely — it merges with what has been learned live. Relationship history never blocks or releases mail by itself: it is evidence for review, presented to the AI reviewer as stated facts, and it never overrules blocklists, antivirus or signatures.

Who your people talk to is the most sensitive data in the product, and it never leaves your node: it is not shared with the knowledge-sharing hub, it leaves in no report, and the AI reviewer receives derived statements ('known correspondent, 214 messages over 180 days'), never the graph itself. On multi-tenant deployments each tenant has its own graph, separated in the storage layout rather than by a filter that could be forgotten.

The Bayes Classifier panel shows the health of your Bayes statistical classifiers: hit rates, score distribution, and training balance.

Monitor classifier drift, verify learning is working, and ensure your spam/ham training data stays balanced.

Is Bayes firing? What's the score distribution? Is our training balanced?

Bayes health checks ensure your statistical classifier is contributing to verdicts rather than sitting dormant.

A Bayes classifier that never fires or always scores zero isn't learning. The panel surfaces these issues so you can fix the underlying problem: missing learn tokens, imbalanced training, or misconfigured thresholds.

A dashboard per subscription — Spamhaus DQS, Abusix Mail Intelligence, SURBL and Fuzzy — each breaking the feed down by sub-service rather than reporting one hit count. See which parts of a feed you are paying for and which parts fire.

Fuzzy compares premium and bulk sources with an overlap view and a premium-accuracy card, so the question 'is the premium tier adding anything?' has an answer.

Which sub-services of this subscription actually contribute? Are two feeds telling us the same thing?

Pair these with Detection Impact: a feed with wide coverage but no decisive contribution is a renewal you can reconsider.

The URLs & Domains panel provides URL and domain analytics: most-seen domains, TLD distribution, and URL blocklist hit rates.

See which domains are appearing in your traffic, which TLDs are overrepresented in spam, and how your URL blocklists are performing.

Which domains appear most in our mail? What's the top TLD for spam? Are our URL blocklists firing?

URL and domain analytics help you identify abuse patterns and evaluate the effectiveness of your URL-based detection layers.

See hit rates for SURBL, Spamhaus DQS, and other URL blocklists. Identify which lists are contributing and which are redundant with your existing rules.

The Content & Attachments panel analyses MIME structure, content-type distribution, and attachment patterns across your traffic. See which file types are being sent, which content rules are firing, and how attachment patterns correlate with spam.

Track attachment volume by type, document format trends, and content-rule hit rates.

What attachment types are most common? Are PDFs correlated with spam? Which content rules are firing?

Content analytics help you understand the makeup of your email stream and tune content-based detection rules.

See which attachment types are overrepresented in spam: executables, archives, office documents with macros. Use this data to tune attachment-based scoring rules.