Contact Form Spam: What Works in 2026 Beyond CAPTCHA

A client called us on a Monday in March because their sales inbox had 1,400 unread messages. Not leads. Russian-language crypto pitches, SEO outreach templates with the placeholder tokens still in them, and about 200 copies of the same message offering to buy a domain they didn’t own. The site had reCAPTCHA v2 installed. It had been installed for three years. It did nothing.

That’s the thing nobody says plainly: a checkbox widget is not contact form spam protection, it’s a tax on your legitimate users. Captcha solving is a commodity service now, priced somewhere around a dollar or two per thousand solves, and the bots hitting your Bootstrap contact form are not the ones paying for it anyway. Most of them never render your page.

What actually works in 2026 is boring, layered, and mostly invisible. Here’s the stack we deploy, in the order we deploy it, with the failure modes we’ve hit.

Why the CAPTCHA box stopped being the answer

Three separate things broke it.

First, solving got cheap and reliable. Human solving farms have existed for a decade, but vision models pushed the automated solve rate on image grids high enough that the economics flipped completely. A bot operator sending 50,000 submissions a month treats captcha as a rounding error.

Second, most spam never loads your JavaScript. A huge share of what hits a public form is a script POSTing directly to your action URL, scraped from the HTML once, months ago. If your captcha validation happens client-side, or if your endpoint accepts a POST without a server-side token check, the widget is decoration. We’ve audited forms where removing the reCAPTCHA script entirely changed nothing, because the server never verified the response token.

Third, the user cost is real and measurable. Every added friction step on a contact form loses you some percentage of genuine enquiries. The people most likely to bounce are the ones on a flaky mobile connection or using a screen reader. If you’re already thinking about labels, errors and focus management, bolting an image grid onto the end of that form undoes a chunk of the work.

Know what’s actually hitting you

You can’t pick defences until you’ve read 50 of the messages. Do that first. Spam on contact forms falls into four buckets, and they need different answers.

• Dumb scripted POSTs. No browser, no JS, direct to the endpoint. Often every field filled with the same string. This is the bulk of it, and honeypots alone handle it.
• Headless browser spam. Playwright or Puppeteer driving a real Chromium, executing your JS, filling fields that are visible. Timing checks and behavioural signals catch most of these.
• Human-driven outreach spam. An actual person in a low-cost labour market pasting an SEO agency pitch into your form. No technical signal distinguishes them from a lead. Only content heuristics help.
• Form abuse as a relay. The attacker doesn’t care about you. They’re injecting content into your auto-reply email, or stuffing the name field with a URL so it lands in someone else’s inbox from your trusted domain. This one is a security issue, not a nuisance.

That last bucket is why you should never echo unescaped user input into an auto-responder, and why your mail headers should never be built from form fields. We have seen a WordPress site get its sending domain blacklisted in under 48 hours because a plugin put the submitter’s name into the From header.

The honeypot form field, built so it doesn’t break

Everyone knows the trick. Almost nobody implements it correctly. A honeypot form field is an input a human will never fill, because they can’t see it, but a naive bot fills every input it finds.

Four rules decide whether it works:

1. Don’t use type="hidden". Half the bots skip hidden inputs deliberately. Use a visible text input moved off-screen with CSS.
2. Don’t use display: none on the input alone. It’s the first thing a half-decent scraper checks. Position the wrapper off-screen instead.
3. Hide it from assistive tech explicitly. aria-hidden="true" on the wrapper, tabindex="-1" on the input. Otherwise a screen reader user hears an unlabelled field and fills it, and you’ve just blocked the exact person you were trying to serve.
4. Pick a name that won’t trigger autofill. Call it url, website, company or phone2 and some password managers will helpfully populate it. Set autocomplete="off" and use a name only your backend knows.

<div class="hp-field" aria-hidden="true">
  <label for="contact_reference">Leave this field empty</label>
  <input type="text" id="contactreference" name="contactreference"
         tabindex="-1" autocomplete="off">
</div>

<!-- rendered by JS on page load, so non-JS bots post a missing/stale value -->
<input type="hidden" name="formrenderedat" id="formrenderedat" value="">

.hp-field {
  position: absolute;
  left: -9999px;
  top: auto;
  width: 1px;
  height: 1px;
  overflow: hidden;
}

// Stamp the render time client-side. A direct POST will never set this.
document.getElementById('formrenderedat').value = Date.now();

On the server, reject if the honeypot has any value at all, and reject if the submission arrived faster than a human could type. We use three seconds as the floor. Below that, nobody has read a label, let alone written a message.

<?php
$honeypot  = $POST['contactreference'] ?? '';
$rendered  = (int) ($POST['formrendered_at'] ?? 0); // ms since epoch
$elapsedMs = (int) round(microtime(true) * 1000) - $rendered;

if ($honeypot !== '') {
    quarantine($POST, 'honeypotfilled');
    respond_success(); // Tell the bot it worked. Never reveal the rule.
}

// No timestamp at all, or submitted in under 3s, or sat open over 6 hours.
if ($rendered === 0 || $elapsedMs < 3000 || $elapsedMs > 21600000) {
    quarantine($_POST, 'timing:' . $elapsedMs);
    respond_success();
}

Note the respond_success() on both branches. If you return an error, the operator learns the rule and adapts. Return the same 200 and the same thank-you page you’d give a human, then route the submission to a quarantine table instead of your inbox.

The upper time bound matters more than people expect. A tab left open for a week then submitted is usually either a resumed real session or a replayed capture. Six hours is a reasonable cut for a marketing form. For a long application form, raise it.

Signed tokens and the endpoint nobody guards

The honeypot handles bots that fetch your page. It does nothing against a script that memorised your POST URL and never visits again. For that you need a token that proves the submission came from a page you served recently.

In WordPress, that’s wpnoncefield() plus checkadminreferer() or wpverifynonce() on the handler. On a static site, issue a short-lived HMAC from your form endpoint:

<?php
// Issued when the page renders
$issued = time();
$token  = $issued . '.' . hashhmac('sha256', $issued . '|' . $formId, FORMSECRET);

// Verified on submit
[$ts, $sig] = explode('.', $POST['formtoken'] ?? '.', 2);
$expected = hashhmac('sha256', $ts . '|' . $formId, FORMSECRET);

if (!hash_equals($expected, $sig) || (time() - (int) $ts) > 7200) {
    quarantine($POST, 'badtoken');
    respond_success();
}

If your site is fully static and you’d rather not run any PHP at all, this is the part a hosted endpoint earns its keep on. WebForms handles token issuance, spam scoring and delivery to email, Slack or a webhook without you deploying a backend. That’s the same reason you’d use a hosted processor when you’re taking payments from a static site: the secret never lives in the repo.

If you need a challenge, use Turnstile

Sometimes layers one and two aren’t enough: high-value forms, forms that have been specifically targeted, forms behind a signup bonus. Then add an invisible challenge.

Cloudflare Turnstile is the one we deploy. It’s free at any realistic volume, most users never see an interaction, and it doesn’t feed a behavioural ad profile the way reCAPTCHA does. That matters if you have EU clients and a privacy policy you actually intend to honour. hCaptcha is the reasonable alternative if you need the enterprise accessibility cookie option.

<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>
<div class="cf-turnstile" data-sitekey="YOURSITEKEY" data-theme="auto"></div>

<?php
$verify = wpremotepost('https://challenges.cloudflare.com/turnstile/v0/siteverify', [
    'body' => [
        'secret'   => TURNSTILE_SECRET,
        'response' => $_POST['cf-turnstile-response'] ?? '',
        'remoteip' => $SERVER['REMOTEADDR'],
    ],
]);

$result = jsondecode(wpremoteretrievebody($verify), true);
if (empty($result['success'])) {
    quarantine($POST, 'turnstilefailed');
    respond_success();
}

Two caveats from production. Turnstile occasionally hard-fails for users on aggressive VPNs or locked-down corporate proxies, so give it a visible fallback message rather than a dead submit button. The token is also single-use with a 300 second lifetime, so if your form does client-side validation that takes a user three minutes to fix, call turnstile.reset() before resubmitting.

Server-side scoring for the spam a human typed

None of the above stops a person in an outreach farm pasting a guest post pitch. For that, score the content. We run a simple additive score and quarantine anything over a threshold rather than hard-blocking, because every heuristic here has false positives.

Signals that have actually earned their place on client sites:

• Link count in the message body. Two or more URLs in a contact form message is a strong spam signal. Real enquiries rarely include even one.
• MX record check on the email domain. checkdnsrr($domain, 'MX') in PHP. If the domain can’t receive mail, the submission is worthless even if it’s genuine.
• Disposable domain list. Cheap to check, updated lists are freely available, low false positive rate for B2B forms.
• Per-IP and per-email rate limits. Three submissions per IP per hour is generous for a contact page.
• Language mismatch. If your site is English-only and the message is pure Cyrillic, that’s a signal. Weight it, don’t block on it, and skip this entirely on multilingual sites.
• Phrase matching on the current wave. “I came across your website and noticed”, “white hat link building”, “SEO audit”. Keep this list short and review it quarterly, because it goes stale fast.

<?php
function spam_score(array $f): int {
    $score = 0;
    $msg   = (string) ($f['message'] ?? '');

    $score += 3 * max(0, pregmatchall('~https?://~i', $msg) - 1);
    $score += (strlen($msg) < 25) ? 2 : 0;

    $domain = substr(strrchr((string) ($f['email'] ?? ''), '@'), 1);
    if (!$domain || !checkdnsrr($domain, 'MX')) {
        $score += 5; // undeliverable address, nothing to lose
    }
    if (preg_match('~\b(link building|guest post|seo audit)\b~i', $msg)) {
        $score += 4;
    }
    return $score;
}
// >= 6 quarantine, >= 10 discard after 30 days

Akismet is worth the licence on WordPress sites with real volume, covering content patterns you’d never maintain yourself. On a brochure site with four enquiries a week, it’s overkill. Honeypot plus timing plus MX check gets you to near zero noise.

Quarantine, don’t delete, and measure the thing

The single most expensive mistake in this whole area is a silent drop. You add a filter, your inbox goes quiet, you congratulate yourself, and six weeks later you find out a prospect filled the form twice and gave up.

Store every rejected submission with the rule that caught it and a timestamp. Set up a weekly digest listing quarantined items, or a Slack channel if you prefer. We had to tune the timing floor upward on a client site after discovering their sales team was testing the form with autofill and tripping the three second rule. That only surfaced because the rejections were logged with a reason string.

Track two numbers: quarantined per week by rule, and false positives found on review. If a rule has caught 400 things and produced two false positives, keep it. If it’s produced four false positives out of twelve catches, it’s costing you money. Delete it.

One more operational note. Rate limit at the edge as well as in your application. A Cloudflare rate limiting rule on the POST path costs nothing and stops the flood before it ever reaches PHP. That matters because a 20,000 request spam burst against a WordPress endpoint will take the site down long before the spam filter gets a say.