AI Spam Filter, in Practice: What Actually Triggers It

AI Spam Filter, in Practice: What Actually Triggers It

Every email security vendor now describes its product as AI. Check Point's Harmony page promises that "our advanced AI ensures your company is protected from targeted threats". SpamTitan's enterprise page describes filtering where "Bayesian Analysis uses statistical techniques and Machine Learning to identify unusual word patterns or spellings". The category has renamed itself, thoroughly and in the space of a couple of years.

Meanwhile the receiving provider that handles more B2B mail than any security vendor publishes a list of requirements for senders, and that list mentions authentication, TLS, spam rates, unsubscribe handling and message format. It says nothing about AI at all.

Both of those observations are true, and holding them together is what makes this topic tractable.

One naming note before anything else, because the two forms are used interchangeably and neither is more correct. An AI spam filter and an artificial intelligence spam filter are the same category described with the acronym expanded, and vendors switch between the two wordings inside a single page. Nothing below distinguishes them.

What is genuinely new, and what has been there for twenty years

Statistical classification of email is old. Bayesian filtering, which scores a message on the words it contains against a corpus of what a user has previously called junk, dates to the early 2000s and is what the phrase "spam filter" has meant to most practitioners ever since. SpamTitan naming Bayesian analysis and machine learning in one sentence is an accurate description of a technique that has been running for two decades.

What has changed is the addition of models that read a message rather than tokenising it. A system that understands the intent of a sentence can recognise an unsubscribe request phrased in a way no rule anticipated, spot an impersonation attempt that uses none of the expected words, and identify a commercial ask written to avoid every term a keyword list would catch.

Rule and score basedStill running underneath

• Named tests, each adding or subtracting points
• A configurable threshold set locally
• Deterministic and inspectable
• Genuinely gameable by editing wording

Statistical and learnedTwo decades old

• Word and pattern distributions learned from labelled mail
• Adapts as recipients mark messages
• Per-organisation and per-user learning
• Vocabulary tricks decay as the model retrains

Language model basedThe new part

• Reads meaning rather than counting tokens
• Recognises intent regardless of phrasing
• Sees impersonation without matching a string
• Vocabulary tricks stop working entirely

The practical implication of that third column is narrow and worth being precise about. It does not mean the message matters more. It means the specific trick of rewording to dodge a keyword list has stopped paying, because the thing on the other side is no longer reading for keywords.

What still decides the outcome

Google's sender guidelines are the most useful document in this topic precisely because they are unglamorous. They ask senders to authenticate, to use TLS, to format messages to the standard, to handle unsubscribe requests, and to "Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher."

Nothing there is about what your model-based adversary thinks of your prose. All of it is about whether you are a legitimate sender behaving legitimately, and all of it is measurable in advance.

That gap between the marketing and the requirements is the most useful thing in this article. The vendors have upgraded their classifiers. The inputs a sender controls are the same inputs as before.

1. Step 1Identity, proven

   SPF, DKIM and DMARC resolving at the published DNS. A model that reads intent perfectly still reads a failed authentication result first.

2. Step 2Reputation, accumulated

   The record of how mail from this domain has been received. Built over time, damaged quickly, and consulted by every system regardless of its architecture.

3. Step 3Recipient response, recorded

   Complaints, deletions without reading, and replies. This is the label the learning is trained on, so it is the input with compounding effect.

4. Step 4The message itself, understood

   Read for what it is asking rather than for which words it uses. Relevance became the variable at exactly the point that vocabulary stopped being one.

Where the newer filtering actually bites a cold sender

Three specific places, all of them consequences of comprehension rather than of scoring.

Unsubscribe intent is recognised however it is phrased. A recipient replying with a sentence asking not to be contacted again is now understood as such, without needing to click anything. Treat any such reply as a suppression instruction, immediately and permanently, because the receiving side is already treating it as one.

Near-identical mail is recognised as near-identical. Variation produced by swapping synonyms does not produce a different message to a system reading meaning. Spun copy that reads as a hundred variants to a rule-based scorer reads as one message sent a hundred times to a model, which is worth knowing before building a programme on that assumption.

Impersonation is caught without a string match. A from-name implying an existing relationship, or copy suggesting a prior conversation that never happened, is exactly the pattern these products are sold to detect. This is where a lot of otherwise-legitimate cold email gets itself into trouble, and it is entirely avoidable.

What survives comprehension-based filtering

• ✓Yes: Authentication resolving correctly at the published DNS records
• ✓Yes: A verified list, so complaints and bounces stay low
• ✓Yes: An honest from-name that claims no relationship you do not have
• ✓Yes: A message a stranger would find relevant enough not to report
• ✕No: Rewording to dodge a list of supposed trigger words
• ✕No: Synonym spinning treated as producing genuinely distinct messages
• ✕No: Copy implying a prior conversation that did not happen

Why the marketing outran the change

It is worth understanding why every vendor page says AI at once, because the answer affects how much weight to give any individual claim.

Two things happened together. Genuine capability arrived, in the form of models that can read a message, and a marketing term arrived that buyers had started asking for. A product whose page does not say AI now looks dated next to one that does, whatever either product does underneath. So the phrase spread across pages describing techniques that predate it by twenty years, and across pages describing genuinely new capability, with no way for a reader to tell which is which.

The practical consequence for a sender is that vendor pages are poor evidence about what a specific recipient's filtering will do. They are good evidence about what a vendor sells, which is a different question. What survives that uncertainty is the set of inputs that every generation of this technology has read: who you are, whether you can prove it, what your record looks like, and what recipients do when your mail arrives. Building on those is the only strategy that does not need re-planning each time the category renames itself.

There is a second reason to be cautious about the label. A product that reads messages with a model is a product whose behaviour changes when the model is updated, without any announcement to senders and without any change on your side. A campaign that performed well at a set of recipients and stopped, with no change to your infrastructure, may be observing exactly that. It is not diagnosable from outside, and the correct response is the same as it would be for any unexplained change: verify your own side is unchanged, compare against sibling campaigns, and treat the recipient population as the variable.

If you came here to build one

A large share of the public material about AI spam filtering is written for people building a classifier rather than for people sending mail into one, and the two questions have almost nothing in common. Building one is a text classification problem with well-documented approaches and a large body of tutorials behind it.

Sending into one is the subject of this page, and the distinction worth carrying across from the building side is what a classifier is trained on. It learns from labelled examples, and in production the labels come from recipients pressing a junk button. That single fact explains why complaint rate outweighs every other input, and why the spam complaint rate is the metric to watch rather than any score a testing tool returns.

The measurement problem this creates

One consequence deserves stating plainly, because it changes what testing is worth.

Rule-based scoring produces a number you can inspect and reproduce, which is what a spam score is and why testing tools report one. A model that reads intent produces a judgement that is not decomposable into named tests, is not stable across organisations, and cannot be reproduced by any tool you can run. So the scores that testing products return describe the older layer, which is still present and still worth passing, and they are silent about the newer one.

The evidence that does reflect the newer layer is first-party and behavioural. Google Postmaster Tools reports what Google itself recorded about your domain. Reply rate split by receiving provider tells you where humans actually read the message. Benchmarks for what normal looks like are in cold email spam rate benchmarks, useful for shape and not as targets. The two-layer picture underneath all of this is in what a spam filter is, and the end-to-end diagnostic sequence is in running your own deliverability audit.

One structural note, because it interacts with a system that learns from behaviour. We send one message per campaign, sent once, and any later approach to the same person is a separate campaign built on a different premise. Repeated unanswered arrivals from an unfamiliar sender is a pattern any learning system picks up quickly, and it is learned per sender. Sending once keeps it out of the training data.

The short version

Every vendor in the category now says AI, and statistical filtering has in fact been running since the early 2000s. What is genuinely new is filtering that reads meaning rather than counting words, which retires vocabulary tricks and synonym spinning and catches impersonation without a string match. What has not changed is the list of things a sender controls: authentication, reputation, list quality, complaint rate and relevance, which is exactly what Google's own sender requirements ask for while never mentioning AI. Test tools still score the older layer, so read your own first-party evidence for the newer one. The full diagnostic order is in the cold email deliverability guide.

Every input on that list is a targeting and hygiene decision rather than a copywriting one, which is where RevenueFlow puts the work: B2B cold email and LinkedIn outreach, one message per campaign, with the list and the sending record treated as the product. See how the campaigns work.

Vendor descriptions and platform requirements verified against the vendors' and Google's own published pages as of August 2026. Verify current terms with the source before relying on them.