SpamAssassin Score for B2B Teams: What Actually Triggers It

A free spam checker returns 3.8 and a green tick, the campaign goes out, and the replies never come. The number was accurate. It was also a measurement of a machine in a data centre somewhere running a configuration that has nothing to do with the servers your prospects sit behind.

SpamAssassin is an open-source mail filter from the Apache Software Foundation, and its scoring model is the one behind most of the free tools that grade a message before you send it. Understanding what the number is made of, and what it is a property of, is worth more than any amount of tuning against it.

How the score is assembled

A message arriving at a SpamAssassin installation is run through a large library of individual tests. Each test is narrow: does the subject match a pattern, is there a valid DKIM signature, is the sending IP listed on a public blocklist, does the HTML contain a particular construction. Each test that fires contributes a score, positive or negative, and the scores are summed.

That sum is compared against a configured threshold. Above it, the message is spam as far as that installation is concerned.

The scores themselves are configurable per test. Apache's own configuration documentation describes the mechanism: a score can be assigned to any named test, scores can be positive or negative, and each test has a symbolic name such as FROM_ENDS_IN_NUMS (Apache SpamAssassin configuration reference). An administrator who dislikes a particular test can zero it. One who has been burned by a pattern can weight it heavily.

The threshold is not 5, it is whatever the receiver set

Almost every article about SpamAssassin says a score under 5 is safe. Here is what Apache's own documentation says, in full, about the setting called required_score:

Set the score required before a mail is considered spam. n.nn can be an integer or a real number. 5.0 is the default setting, and is quite aggressive; it would be suitable for a single-user setup, but if you're an ISP installing SpamAssassin, you should probably set the default to be more conservative, like 8.0 or 10.0.

Two things fall out of that. The project describes its own default as aggressive and recommends larger operators raise it, which means a well-run receiver is very likely not on 5. And the value is per-installation, so the same score means different things at different destinations. A 4.6 clears a threshold of 5 by a margin thinner than a single test hit, and sails past a threshold of 8 with room to spare.

The number on your test report is therefore an input, not a verdict. Nobody can tell you what it means without knowing the receiving configuration, and you do not know the receiving configuration.

The same message scores differently on different installations

There is a second layer of variance, and it is less well known than the threshold one.

SpamAssassin's configuration reference documents four score sets rather than one. If four scores are listed for a test, which one applies depends on how SpamAssassin is being used: one score when both Bayesian and network tests are disabled, another when Bayes is disabled but network tests are enabled, and further sets when Bayes is enabled. Network tests query external services, and Bayesian filtering learns from what that installation's own users have marked.

So the identical message, unchanged, produces a different total on an installation with network tests off than on one with them on, and a different total again on an installation whose Bayesian database has been trained on a different mail stream. The score is a property of a message evaluated by a specific installation on a specific day, not a property of a message.

What it reliably catchesTrust the number here

• Missing or broken DKIM signature
• Sending IP or domain on a public blocklist the installation queries
• Malformed headers, missing Message-ID, date skew
• HTML defects: unbalanced tags, hidden text, image-only bodies
• Envelope and header From mismatches

What it cannot seeDo not read the number as placement

• The threshold the actual receiver has configured
• Whether the receiver runs SpamAssassin at all
• A security gateway sitting in front of the mailbox
• Microsoft bulk complaint scoring, which is a separate system
• Your engagement history with that recipient organisation
• Recipient complaint history against your sending domain

The arithmetic, worked through

An illustrative sum makes the threshold point concrete. Take a message that fires four tests: a blocklist hit at 2.5, a DKIM verification failure at 1.1, an HTML construction rule at 0.8, and a subject-line pattern at 0.4. The total is 4.8.

At the default threshold of 5.0, that message is delivered, and it is delivered by 0.2 points. Remove the subject-line rule by rewriting the subject and the total is 4.4, which feels like progress and is worth almost nothing, because the blocklist hit alone is more than six times the size of the thing you fixed. Resolve the blocklist listing instead and the total drops to 2.3, clearing the threshold by a margin no copy change could produce.

Now move the same message to an installation on the conservative setting Apache recommends for larger operators. At 8.0, all four versions of the message are delivered and the entire exercise was moot. Move it instead to an installation whose administrator weighted the blocklist rule at 5.0 because they were tired of a particular network, and the original message scores 7.3 and is spam at any threshold below that.

Three receivers, one message, three different answers, and none of the differences came from the message. The numbers above are made up to show the shape of the arithmetic, which is the only thing that generalises.

1. Step 1Tests run

   A library of narrow tests is applied to the headers and body. Which tests exist depends on the installation and its rule updates.

2. Step 2Scores assigned

   Each firing test contributes a configurable positive or negative value. Four score sets exist, chosen by whether Bayes and network tests are enabled.

3. Step 3Total compared

   The sum is compared against required_score, which defaults to 5.0 and which Apache advises larger operators to raise.

4. Step 4Verdict written

   The total, the threshold used and the firing rule names are stamped into the message headers.

5. Step 5Action taken

   What happens to a message above threshold is a separate local decision: junk, quarantine, tag, or reject.

Where you see a real score, as opposed to a test one

An installation that runs SpamAssassin normally writes its findings into the message as headers, and those headers are the only version of the score that describes something that actually happened to your mail. They carry the total, the threshold that installation used, and the names of the individual tests that fired.

Getting hold of one works the same way as any header retrieval. A recipient who forwards your message as an attachment preserves them. A mailbox you control on a host that runs SpamAssassin, which includes a great many small business and hosting-provider mail servers, receives your campaign and keeps the evidence. A bounce sometimes quotes the score in the rejection text.

The test-tool version is still useful, with its scope understood. It is a linting pass. It finds the mechanical defects in the left column above, cheaply, before anyone receives anything. Treat a high score as a signal to go looking, and a low score as evidence of nothing beyond the absence of mechanical defects.

Using a SpamAssassin score honestly

• ✓Yes: Read the individual rule names that fired, not just the total
• ✓Yes: Fix authentication and blocklist hits first, since they carry the largest weights and are infrastructure rather than copy
• ✓Yes: Record which installation produced the score and what threshold it used
• ✓Yes: Treat a score from a free checker as a linting result on your message construction
• ✕No: Rewriting subject lines to shave tenths off a total
• ✕No: Reporting a test-tool score to a client as an inbox placement figure
• ✕No: Assuming a score under 5 means the message will be delivered to the inbox

The rules with the largest weights are not about your writing

Look at what a real header lists after a poor score and the pattern is consistent: authentication failures, blocklist hits, IP reputation, and header malformation carry weight. Word-level content rules exist and mostly carry small fractions.

This matters because the instinct on seeing a bad score is to rewrite the copy. The copy is rarely where the points are. A missing DKIM signature or a listed IP will outweigh every word choice in the message, and no amount of rephrasing recovers it. Our deliverability audit checklist works through the infrastructure layer in the order the points actually sit, and checking your domain and IP against the public blocklists closes out the single heaviest category in a few minutes.

The corollary is a caution about writing to the tool. Optimising a message until a rule engine likes it produces mail shaped by a rule engine. The subject lines that survive that process tend to be bland, and blandness is not a scored attribute anywhere while being a serious problem for reply rates. If you want a picture of what normal looks like before you start changing things, our cold email spam rate benchmarks and deliverability benchmarks are the reference points.

How it sits alongside everything else

A spam score is one rule engine's estimate. The major mailbox providers publish no equivalent number, which is the honest reason a clean score cannot be a placement result. Microsoft scores bulk mail on its own scale in its own headers, Google publishes nothing comparable, and a spam filter at a B2B recipient is frequently a security gateway making connection-level decisions before any content scoring happens at all.

The things that move inbox placement at scale are upstream of scoring: DKIM and the rest of the authentication set passing and aligned, a sending domain with its own history, a sender reputation that has not been damaged by invalid addresses, and a list clean enough not to contain a spam trap. Get those right and the scores follow. Chase the scores and the underlying position does not change.

RevenueFlow runs cold email and LinkedIn outreach for B2B companies, and infrastructure work of this kind is part of the campaign rather than a separate line item. If you would rather have it handled than audited, prepay a single qualified meeting and see the setup done properly, or read what a cold email agency should be accountable for.

SpamAssassin configuration behaviour verified against the Apache SpamAssassin documentation as of August 2026. Verify current defaults with the project before relying on them.