Spam Score: What the Number Measures and What It Cannot See

A spam score is a numeric value that a spam filter or a testing tool assigns to a message, estimating how likely that message is to be unwanted. The value is compared against a configured threshold, and a message scoring above the threshold is treated as spam by whatever system produced the score. Spam scoring is the process that produces the number: a set of tests, a point value for each, and a total.

One clarification before anything else, because two unrelated things share the name. Spam score also refers to an SEO metric that estimates how likely a WEBSITE is to be penalised by search engines, calculated from signals about that site's links and pages. Nothing on this page concerns that meaning. Everything below is about the number attached to an individual email message. People also say spam rating for how often recipients report a sender's mail. That is a complaint rate, a different measurement with its own benchmarks, and it comes up again further down.

How spam scoring works

Spam scoring runs a message through a library of tests, gives each test that fires a positive or negative point value, adds the points and compares the total with a threshold. In SpamAssassin, the engine most free checkers are built on, the documented default threshold is 5.0, and its own documentation suggests 8.0 or 10.0 for an ISP.

The scoring model most people have met comes from the SpamAssassin tradition, and it is worth understanding in detail because almost every free spam-checking tool is built on it or on something shaped like it.

A message arrives and is run through a large library of individual tests. Each test is narrow and independent: does the subject line contain a particular pattern, is there a valid DKIM signature, does the sending IP appear on a named blocklist, is the ratio of HTML markup to readable text unusual, is the Date header implausibly skewed from the time of receipt. Every test carries a point value. Most add points, some subtract them. The engine runs the whole library, adds the values of the tests that fired, and compares the total against a threshold set by whoever configured the installation.

That last clause carries more weight than it looks. SpamAssassin's configuration documentation says of its own threshold that "5.0 is the default setting, and is quite aggressive", suitable for a single-user setup, and tells an ISP to set something more conservative. The threshold is a configuration value, not a property of the score. The same total means "delivered" at one installation and "quarantined" at another, which is the first reason a number lifted out of one engine and shown to you in a report is difficult to act on.

Two structural details of that design are worth holding onto. First, negative-point tests exist and they matter: a validating signature or a known-good sender characteristic pulls the total down, so a score is a balance rather than a tally of sins. A message can carry several small penalties and still land comfortably under a threshold because one strong positive signal offset them. Second, a meaningful share of the library does not examine the message at all. Blocklist and URI lookups leave the machine, ask a DNS-based service about your sending IP or about a domain in your links, and score the answer. Those tests are the reason the same message can score differently at two moments in the same afternoon, with nothing about the message having changed.

A worked example makes the threshold point concrete. The point values in it are illustrative, since every installation carries its own, and only the two thresholds come from SpamAssassin's documentation. Four tests fire against a message and one counts in its favour, for a total of 6.1. At the default threshold of 5.0 that message is marked as spam. At the 8.0 the same documentation suggests for an ISP, it is delivered, with nothing about the message having changed.

Score report: one message, two installations

+2.4 sending IP found on a DNS blocklist 1

+1.9 image-heavy message with little text

+1.5 link to a domain on a URI blocklist 1

+1.3 Date header skewed from time of receipt

-1.0 valid DKIM signature 2

Total 6.1 3

1. 1Lookups that leave the machine, so the same message can score differently later the same afternoon.
2. 2A negative-point test. A score is a balance, and one strong positive signal offsets several small penalties.
3. 3Marked as spam at a threshold of 5.0. Delivered at a threshold of 8.0.

The point values are less fixed than even that suggests. The same documentation lets a single test carry four different scores, and which one applies depends on whether the installation has its Bayes learning component and its network tests switched on. One rule, one message and one piece of software can therefore produce different points on two machines.

Many installations also carry a learning component that adapts to the mail a particular site receives. That is a feature for a corporate gateway protecting one organisation and a complication for anybody trying to read a score as a universal verdict, because it means the engine has been trained on somebody else's mail and is scoring yours against that history.

The tests themselves group into families.

Content and structure

The message itself

• Phrase and pattern matching in subject and body
• Ratio of markup to readable text
• Obfuscated or invisible text
• Image-heavy messages with little text
• Links checked against URI blocklists

Authentication and identity

Who the message claims to be from

• Whether SPF passes for the sending IP
• Whether a DKIM signature validates
• Whether either aligns with the visible sending domain
• Envelope sender and header sender mismatch

Reputation lookups and headers

External and structural signals

• Sending IP or domain on a DNS-based blocklist
• Malformed or missing Message-ID
• Date header skew
• Received-header chains that do not make sense

A well-formed business message authenticated properly and written in ordinary prose tends to score near zero on an engine like this, and that outcome is genuinely worth having. It means nothing in the message is structurally broken. The failure is in what people then conclude from it.

Where the number comes from is the whole problem

The score a free spam-checker gives you is that tool's model, not the receiving provider's verdict.

The major mailbox providers publish no per-message spam score. They do not expose one to senders, they do not return one in the SMTP conversation, and they do not run the open-source rule engines these testers are built on. Their filtering is proprietary, it draws heavily on signals a tester has no access to, and it produces a placement decision rather than a number.

So a clean score from a testing tool is a genuine piece of evidence, correctly stated: a particular rule engine, examining this message in isolation, had no objection to it. That is useful. What it is not is a prediction. It is silence on the question of whether Gmail or Microsoft will put the message in an inbox, and silence read as agreement is how senders end up confidently optimising something that was never going to move.

Senders optimise the number they can see because it is the only number they can see, which is a completely rational response to an information problem and still produces the wrong work.

The second-order break, and the bigger one

Rule-based content scoring has declined in weight relative to sender reputation and recipient engagement. Filters that once leaned heavily on what a message said now lean heavily on who sent it, how that sender has behaved, and what recipients have done with previous mail from them. The consequence for a spam score is uncomfortable: the number is measuring the part of the decision that matters least, in the most detail.

You can watch that happen in what the providers themselves choose to publish. Google's sender guidelines instruct senders to "Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher", and they say plainly that "Over time, user spam reports can lower your domain's reputation". Both of those are statements about recipient behaviour and domain history. Neither is a statement about message content, and neither is expressed as a score you can test a draft against.

The threshold problem compounds it. Because the cut-off is configuration, a reported score has no fixed meaning across installations, and testing tools rarely tell you which threshold their verdict assumed. A report saying a message "passed" is reporting a comparison against a number the tool picked. Two tools can score the same message identically and disagree about the verdict, or agree on the verdict while scoring it differently, and neither disagreement tells you anything about where the message will land.

There is a sampling problem sitting underneath as well. A tester scores one rendered message. A real campaign renders differently for every recipient, because names, company references and variable phrasing change what is actually sent. Scoring one rendering certifies one rendering. It says nothing about the variant that fires for the fortieth recipient, and any structural defect that only appears in some renderings is invisible to the test by construction.

And the test inbox is not the recipient's inbox. A seed address at a provider has no history with your domain: no prior mail, no replies, no folder moves, no complaints. Relationship history is much of what the real decision uses, so a test account is systematically the least informative recipient available.

What optimising the visible number actually does

Some of it is harmless. Removing genuinely broken structure, fixing authentication, shortening bloated markup: these improve the message on their own merits and would be worth doing with no score attached.

Some of it is actively harmful, and this is where the habit turns expensive. Senders strip the opt-out line to shed a point. They remove links that a recipient needed. They rewrite plain sentences into stilted ones because a phrase matched a rule written for a different era of spam. They pick a lower-scoring subject line over a clearer one. In every case a real property of the message was traded for a number produced by a system that will not be judging the message.

Authentication deserves the top slot for a specific reason. It is the one family of test in the earlier comparison that a real receiver evaluates in essentially the same way a rule engine does. SPF, DKIM and DMARC are protocols with defined outcomes, so a pass is a pass at both surfaces. Everything else on the tester's list is either a proxy for something the receiver measures differently, or a rule the receiver does not run at all. The setup that keeps authentication passing is therefore the highest-yield item on any list a spam-checking tool generates.

Reading the real signals instead

Replace the score with measurements taken from the surfaces that decide placement. Domain reputation and complaint rate come from the provider's own reporting, and how to read every metric in Google Postmaster Tools covers what each field genuinely supports. Complaint rate in particular is the metric with a published threshold attached, which makes it one of the very few numbers in deliverability you can compare against a stated target rather than against a feeling. What complaint rates look like across real campaigns is in cold email spam rate benchmarks.

Reply rate is the underrated one. A message that produces replies is generating the strongest positive engagement signal available, and it happens to be the thing you were trying to achieve anyway. A programme optimising for replies and a programme optimising for placement mostly want the same changes, which is not true of a programme optimising for a tester's score.

When placement is genuinely broken, the diagnostic order matters more than any single reading, and it is laid out in the cold email deliverability guide. If you would rather work through it systematically against your own setup, the fourteen-point deliverability audit is the structured version.

One habit is worth keeping regardless. Volume and repetition are reputation inputs, and they are inputs you control completely. We send one message per campaign, written on one premise and sent once, and a later approach to the same person is a separate campaign with its own premise. The amount of mail a receiving provider sees from a given sending domain is part of how it forms a view of that domain, so a programme that reaches a person once puts a fraction of the load on that judgment compared with one that keeps returning to the same inbox. No content score reflects that, and it is worth more than any of them.

If the underlying problem is that nobody on your team owns this, our pay-per-qualified-meeting outbound is the version where the infrastructure question sits with us and you take the meetings.

Verified as of mid-2026. Verify current terms with the vendor before relying on them.