How to Stop Contact Form Spam

To stop contact form spam, layer several cheap server-side checks instead of trusting one CAPTCHA. Start with a honeypot and rate limiting. Add timing, email, and content signals. Quarantine uncertain submissions, then add server-side CAPTCHA verification only when the lighter controls still let abuse through.

That order minimizes visible friction for ordinary visitors while raising the cost of automated submissions. No setup eliminates every spam submission. Human spammers and sophisticated browser automation can still pass individual checks, so keep uncertain submissions recoverable and tune the layers from observed traffic.

I build Form Plume, a hosted form backend that uses this stack, so I am not a neutral observer. I will use it as the concrete example where implementation details matter, but the order below also works with your own endpoint, a WordPress plugin, or another hosted backend.

If you want the managed version, the spam-protection features put the same layers behind one form endpoint.

First, identify the spam you have

Contact form spam is an unsolicited submission sent through a public form, usually by an automated crawler or a person running the same pitch across many sites. The right control depends on which pattern reached you.

What the submission looks like	Likely source	Best first response
Every field filled, including hidden or irrelevant inputs	Simple form-filling bot	Honeypot
Dozens of requests from one browser or address	Script or retry loop	Rate limiting
Submission arrives almost immediately after page load	Automated client	Signed timing check
Repeated links, SEO pitches, gibberish, or duplicate text	Template campaign	Content scoring and focused blocklists
Plausible message from a disposable address	Low-quality or throwaway lead	Email hygiene
Natural writing that passes browser checks	Human spammer or browser automation	Quarantine, feedback, then CAPTCHA if needed

If you are unsure, paste a representative message into the form spam checker. It estimates which layer might catch the pattern using transparent browser-only heuristics; it cannot predict a production blocking decision.

The request should move through the layers in this order:

request
  ├─ malformed payload or fields over limits > reject before storage
  ├─ honeypot filled ───────────────> ordinary success, discard
  ├─ rate or timing check fails ────> reject before storage
  ├─ CAPTCHA definitely invalid ────> reject before storage
  ├─ email hygiene block fails ─────> reject before storage
  └─ accepted ──────────────────────> store submission
                                         │
                                         v
                         content scoring + flagged email signal
                                 ├─ low risk ─> inbox
                                 └─ uncertain/high risk ─> quarantine

Do not jump straight to a challenge widget. A CAPTCHA can prove something about one browser interaction. It cannot tell you whether the message is a repeated backlink pitch, whether the address uses a disposable domain, or whether the same source has submitted twenty times.

OWASP's bot-management guidance makes the same architectural point: a single control is brittle, so combine edge, application, and business-layer signals.

Validate every request on the server

Browser validation is for usability, not spam protection. Bots can skip your page and post directly to the endpoint, so validate expected field names, types, lengths, and fixed-choice values again on the server. OWASP recommends validating untrusted input as soon as it is received.

Server validation rejects malformed requests, but it will not recognize a plausible backlink pitch by itself. Keep it underneath the honeypot, rate limits, timing, content, and CAPTCHA layers below.

Add a honeypot without trapping people

A honeypot field is a normal form input hidden from people. Basic bots fill every input they find, so a non-empty honeypot is a strong automation signal.

Here is a complete field you can add to a plain HTML form:

<div
  aria-hidden="true"
  style="position:absolute;left:-10000px;width:1px;height:1px;overflow:hidden"
>
  <label for="company-website">Leave this field empty</label>
  <input
    id="company-website"
    name="_gotcha"
    type="text"
    tabindex="-1"
    autocomplete="off"
  >
</div>

Do not use type="hidden" for the trap. Bots can recognize that as a control field and skip it. Keep a text input out of the visual layout and keyboard order, label the wrapper as hidden to assistive technology, and disable autocomplete so a password manager is less likely to populate it.

The server has to enforce the result. On the receiver, check _gotcha before storage or side effects. When it is non-empty, return the same success response as a legitimate submission, then stop without storing the submission or triggering notifications.

Do not send a helpful honeypot_failed error to the attacker.

A honeypot is an excellent first layer, not a complete defense. A headless browser can inspect visibility, skip the field, and submit realistic values.

Rate-limit the endpoint, not the button

Disabling the submit button prevents double-clicks in your UI. It does nothing to a script posting directly to the endpoint.

Apply rate limits on the receiver. Key them narrowly enough to stop one abusive source without blocking everyone behind an office, school, carrier network, or VPN. IP address is useful as a floor, but OWASP recommends applying rate limits at multiple keys, not just IP, because proxy networks make IP-only limits easy to evade.

JavaScript clients should request JSON. On a 429, read Retry-After and wait before re-enabling submission. The Retry-After header can contain delay seconds or an HTTP date, so parse the format your endpoint documents. Form Plume returns delay seconds.

Do not retry immediately in a loop. That creates more abusive traffic and can extend the lockout.

My default is to start with the least aggressive limit that stops the pattern I can actually see, then tighten it from logs. A low-traffic contact form and a public signup endpoint should not share a threshold, and shared networks need a recovery path.

Add a timing signal for bots that skip the trap

A person needs time to read a page and type a message. Many scripts submit as soon as they discover the form.

Do not trust a hidden timestamp that the browser can edit. Issue a short-lived token from the server, sign it, bind it to the form, and validate its age when the submission arrives. A short expiry narrows the replay window.

Form Plume exposes this as a time-trap token:

const response = await fetch(
  "https://api.formplume.com/f/{public_slug}/time-trap"
);
const { field, token } = await response.json();
 
const input = document.createElement("input");
input.type = "hidden";
input.name = field; // _fp_ts
input.value = token;
document.querySelector("form").append(input);

As of August 2026, Form Plume rejects a time-trap token used less than three seconds after issuance or more than one hour later. The token uses HMAC-SHA256, so the client can carry it but cannot mint a different valid time. Form Plume also rejects reuse seen by the same running API process. Replace {public_slug} with the public slug from your Form Plume endpoint.

One gotcha is easy to miss: fetch a new token after every submission attempt and before reusing a reset form. Verification can consume a valid token even when a later check rejects the request, so reusing it may make the next legitimate attempt fail as a replay. The time-trap guide keeps the product contract current.

Score content instead of blocking on one vague word

Content filters catch the spam that looks human enough to pass browser checks. Useful signals include:

Repeated or excessive links
Exact duplicate messages
Known spam phrases
Unusual capitalization or gibberish
Disposable or non-receiving email domains
Patterns learned from messages you marked spam or legitimate

I would never delete a lead because it contains one vague word. Someone can mention “SEO,” “loan,” or “casino” in a legitimate support request. Prefer a narrow phrase such as backlink packages, and combine weaker signals into a score.

Run content checks after storage, away from the request path. A score at or above your threshold can route the entry to quarantine, while feedback on false positives and missed spam improves later decisions.

Quarantine uncertain submissions instead of deleting them. False positives can happen when language-based signals are involved. A recoverable review queue gives you evidence to tune the threshold without losing the one message that mattered.

Check the submitted email address

An address can pass type="email" and still be useless. Browser validation checks shape, not whether the domain receives mail or belongs to a disposable provider.

Email hygiene can add three server-side checks:

Parse and validate the address.
Check whether the domain publishes MX records or has a resolvable A/AAAA host under SMTP's implicit-MX fallback. Treat Null MX as an explicit declaration that the domain accepts no email.
Compare the domain against a maintained disposable-address list and your own blocked domains.

Treat DNS outages carefully. Fail open on transient lookup errors so a resolver incident does not throw away a real inquiry. Depending on the form's risk, either flag a suspicious address for scoring or block it under an explicit policy.

These checks improve lead quality. They do not prove that the submitter owns the mailbox. If ownership matters, send a verification message and require the person to complete it.

Add CAPTCHA only when the invisible stack is not enough

CAPTCHA is a step-up control, not the foundation. OWASP warns that visible challenges are hostile to accessibility and can be outsourced to human solver farms. Use them when targeted automation keeps passing the lighter checks, or when an action has enough value to justify extra friction.

Whichever provider you choose, verify its token on the server. A widget that only runs in the browser is decoration because an attacker can post directly to your endpoint.

Decide what an outage means before you ship. Failing closed blocks spam but also blocks every person when the CAPTCHA provider is down. Failing open preserves the form and makes the other layers carry more risk.

Provider tokens also expire and cannot be replayed indefinitely. Cloudflare says Turnstile tokens are single-use and valid for five minutes. Google says reCAPTCHA response tokens are single-use and expire after two minutes. hCaptcha likewise requires a server call to its siteverify endpoint in its developer guide.

Put the public site key in the page and keep the secret in server settings, never in HTML or a JavaScript bundle.

How I use these layers in Form Plume

Form Plume is the implementation I know best, so here is where the layers land in a real request. As of August 2026, malformed-payload checks, the honeypot, the time trap, rate limits, optional CAPTCHA, and email-hygiene classification run before storage. A blocking hygiene verdict rejects the request, while a flagged verdict is stored as metadata. After storage, the worker combines that flag with content scoring so uncertain messages remain recoverable.

Form Plume accepts arbitrary user field names and enforces payload, key, and size limits instead of a fixed field schema.

The spam protection overview is the canonical setup reference. Its _gotcha honeypot returns an ordinary success and discards the request before storage.

Rate limiting uses two configurable windows per form and a soft submitter fingerprint. The current limiter is in memory, so limits apply per running API process and reset on restart. Within one process, the defaults use sliding-window estimates configured with a limit of one submission over 30 seconds and 20 submissions over 10 minutes.

JSON requests receive 429 with Retry-After; native HTML submissions redirect with fp_error=rate_limited. The rate-limit docs cover both response modes.

Accepted submissions are stored before the worker runs content scoring. Uncertain entries remain recoverable in the spam inbox, and marking an entry legitimate adjusts learned token weights. Email hygiene fails open on transient DNS errors and can either flag or block under the form's configured policy.

When CAPTCHA is enabled, missing or definitively invalid tokens are rejected. Network, HTTP, and response-decoding failures fail open, as does Cloudflare Turnstile's documented retryable internal-error; these accepted submissions are marked CAPTCHA-unverified. When I need a challenge on a new form, I choose Cloudflare Turnstile. hCaptcha is available on Free; Turnstile and reCAPTCHA are Pro options.

Keep the filters observable

A spam control you cannot inspect can hide false positives and missed abuse.

Record the decision and its signals without retaining more personal data than you need. Review quarantined submissions, especially after tightening a threshold or adding a blocklist. Test the public form after every protection change, then verify both sides: obvious spam is caught and a normal inquiry still reaches the inbox.

Use this rollout order:

Add a honeypot and server-side rate limit.
Add a signed timing signal and content scoring.
Turn on email hygiene and focused blocklists where the traffic justifies them.
Add server-verified CAPTCHA only after the invisible layers still miss abuse.

Danilo Vilhena

How to Stop Contact Form Spam: A Layered 2026 Guide