Why am I getting spam through my contact form?

The tool you installed probably is not blocking anything

Score-based reCAPTCHA is a risk signal, not a gate.

Google's current documentation is explicit about what you are meant to do with it: "Based on the score, you can take an appropriate action in the context of your site." The action is yours to build. Nothing happens by installing the widget.

Its recommended shape surprises people too: "To protect your site better, we recommend that you take the action in the background instead of blocking traffic." So the intended design is quiet handling, not a wall that throws visitors out.

There is also a warm-up period, with a number attached. Google says "reCAPTCHA learns by monitoring real traffic on your site" and warns that "scores in a staging environment and within 7 days of implementation might differ from the long-term production scores." Judging it on day two tells you very little.

And on a quiet site it may tell you nothing at all. One documented response is LOW_CONFIDENCE_SCORE, which Google defines as "Too little traffic was received from this site to generate quality risk analysis." A small brochure site can sit below the volume the model needs.

That combination explains a lot of disappointment. The badge is visible, the score is being generated, and no decision is attached to it.

There is one more thing to wire up. The verification response carries an action name for each request, which Google's field list marks as important to verify. That check is what ties a score to the form it came from. Without it, a score is just a number with no proof of where it was earned.

The score has fewer levels than you think

This is the detail that changes what a sensible threshold looks like, and it is easy to miss.

Google describes the scale: "reCAPTCHA has 11 levels for scores with values ranging from 0.0 to 1.0. The score 1.0 indicates that the interaction poses low risk and is very likely legitimate, whereas 0.0 indicates that the interaction poses high risk and might be fraudulent."

Eleven levels is the full picture. It is not what most sites get. Google states that "only the following four score levels are available before triggering an automatic security review by adding a billing account to your project: 0.1, 0.3, 0.7, and 0.9."

Work through what that means for a threshold, because the arithmetic is the useful part. Without a billing account attached, every score you receive is one of four values. A threshold of 0.4 and a threshold of 0.6 therefore behave identically, since no score ever lands between 0.3 and 0.7. Tuning inside that gap is not fine tuning. It is no change at all.

So the practical decision is coarser and simpler than the advice usually suggests. You are choosing between four buckets, and mostly deciding whether 0.3 belongs with the junk or with the people.

Two different problems wear the same costume

Before treating this as nuisance mail, check which of two things is happening, because OWASP separates them and the second is more serious.

The ordinary case is what OWASP catalogues as spamming: automated content added where content is accepted. Its list of other names includes form spam, comment spam and SEO spam.

The other case is deliberately excluded from that category, and the exclusion tells you why it matters: "The mass abuse of broken form-to-email and form-to-SMS functions, to send messages to unintended recipients, is not included in this threat event, or any other in this ontology, since those are considered to be the exploitation of implementation flaws alone."

Read that plainly. If your form can be made to send messages to people who are not you, that is not spam arriving. That is your form being used to send mail on somebody else's behalf, and OWASP classes it as an implementation flaw rather than a threat you absorb.

The way to tell them apart is simple. Junk enquiries land in your inbox and annoy you. Relay abuse shows up as mail your server sent to strangers, complaints from people you never contacted, or a sudden deliverability problem. The first is a filtering question. The second is a bug, and it needs fixing rather than filtering.

A CAPTCHA is a control, not a wall

Worth calibrating expectations, because the defeat of these tests is itself a catalogued activity with its own number.

OWASP lists CAPTCHA Defeat as OAT-009, and describes how it is done: the process "may utilise tools to perform optical character recognition, or matching against a prepared database of pre-generated images, or using other machine reading, or human farms."

That last phrase is the one to sit with. Some CAPTCHA solving is performed by people, paid to solve them. No image puzzle defeats a human being who is being paid to look at it.

None of that makes the control useless. It means the honest goal is reducing volume and cost, not achieving zero. A defence that removes most automated submissions at no cost to real visitors is a good outcome, and expecting an empty inbox sets you up to keep buying replacements for something that was working.

What to check, in order

Five checks, and the first four are free.

• Confirm something actually acts on the score. Find the rule. If nobody can name what happens at a low score, nothing happens at a low score.
• Give it a week before judging it, since Google warns that scores within 7 days of implementation can differ from long-term ones.
• Check whether your site gets enough traffic for scoring to work, and treat a low confidence response as a fact about volume rather than a fault.
• Establish which problem you have. Junk in your inbox and mail leaving your server for strangers are different failures with different fixes.
• Only then tune a threshold, knowing you are choosing between four values unless billing is attached.

One more habit worth building, because it costs nothing and settles arguments. Run the score without acting on it first. Google suggests exactly this: "you can first run reCAPTCHA without taking action and then decide on thresholds by looking at the traffic."

Then do the arithmetic on your own numbers. Suppose a month brings 120 submissions and 45 are junk. If the junk clusters at 0.1 and 0.3 while genuine enquiries sit at 0.7 and 0.9, the decision is obvious and you can act on it with confidence. If real enquiries also show up at 0.3, then blocking that bucket costs you leads, and the better answer is to route those submissions somewhere for review rather than to reject them. The figures are an illustration. Looking at your own distribution before choosing is the part that matters.

Getting a form set up so the junk stops reaching a person, without quietly dropping real enquiries, is part of what we do on websites.

Sources

• Interpret an assessment for websites (Google Cloud reCAPTCHA)
• OAT-017 Spamming, Automated Threats to Web Applications (OWASP Foundation)
• OAT-009 CAPTCHA Defeat, Automated Threats to Web Applications (OWASP Foundation)

Last reviewed 2026-09-11.