Why Do Bots Fill Out Forms? The Economics of Form Spam and How to Stop It

If you operate any kind of public form on the open web — a contact form, a newsletter signup, a free trial request, a survey, a comments thread — you have almost certainly noticed the same thing every other operator notices within their first week of running it. Strangers are filling it out at three in the morning. The names are improbable, the email addresses are improbable, and the messages, when there are messages, read like the output of a very confused autocomplete model. These are form bots, and they account for a surprisingly large share of total form traffic on the modern web.

A friend of mine who runs his own consultancy got in touch this week after seeing one of my LinkedIn comments on a Castle.io post about disposable-email abuse. He had set up a basic honeypot on his contact form and was pleased to see the obvious traffic stop, but he still wanted to know what these bots actually wanted. Why bother filling out forms at all? Who funds this work, and why does it keep happening even when there is nothing obvious to gain? The honest answer is that there are several distinct economies operating at once, and most defenders never see more than one of them at a time.

Why Do Bots Fill Out Forms?

Bots fill out forms for five overlapping reasons: to push advertising payloads through your domain's reputation, to enumerate which email addresses already have accounts, to mint free-tier and referral credit at scale, to launder SEO authority through expired domains that backlink to themselves, and to map field validation and error behaviour for a later targeted attack. The first four are profit-driven; the fifth is preparatory.

Free advertising distribution. Your form is a megaphone they don't have to pay for. Any field that ends up in an email — name, message, comments — pushes the payload past the recipient's spam filter, because it now arrives from your domain instead of theirs. This single motive drives the majority of form bot traffic on small and mid-sized sites.

Credential stuffing and account enumeration. Signup, login and password-reset forms all leak which email addresses are already registered. That information feeds account takeover campaigns. A bot will happily burn through ten thousand candidate addresses on your signup form just to find the few hundred that already have accounts somewhere.

Free-tier and referral abuse. Free trial? Referral bonus? Signup credit? Someone is industrialising fake accounts against it. Each one is worth a fraction of a cent — but a million of them clears the cost of a residential proxy with change to spare.

SEO laundering through expired domains. This is the one I mentioned in my reply to Castle's post. Spammers buy expired domains that still carry legitimate backlinks, then spray them across contact forms across the web. The email is bait; the prize is having your site link back to a now-spammy domain and resurrect its old PageRank. Many of the "fake" email domains in your logs are recycled rather than invented, so they look old and established to anything that only checks whether a domain exists.

Reconnaissance. The quiet one. Some bots aren't trying to submit anything — they're mapping. Which fields validate? What does each error message look like? Where does throttling kick in? That data feeds the targeted attack that arrives next week. Honeypots and naive CAPTCHAs miss this category entirely.

Why Basic Defences Stop Working

A honeypot field — an invisible input that humans never fill in but naive bots fill in by default — is genuinely effective against the bottom tier of form-filling bots, and my friend was right to deploy one. The reason it works is that the cheapest form-spam bots in circulation are recycled three-line Python scripts that walk the DOM and fill every input element they find. As soon as the attacker spends any money on tooling, however, the picture changes completely.

Modern form bots are driven by full headless browsers and they parse CSS visibility, ARIA attributes and even computed bounding boxes before deciding whether to fill a field. They will skip a hidden honeypot input cleanly. The next layer down — a simple captcha challenge — is also no longer the wall it once was; the global captcha-solving farm market has driven the cost of solving a reCAPTCHA or hCaptcha below the cost of paying a human three seconds of their time, and headless solvers backed by foundation models now clear most image-based puzzles outright. If your only defence is "tickbox plus hidden field", you are protecting yourself against an attack profile that essentially no longer exists in the wild.

The defences that actually work in 2026 operate at a different layer. They look at the email address, the IP, the device fingerprint, the timing and the network reputation of the submitter — and, crucially, they verify the email domain itself against an externally maintained corpus rather than trying to guess from the address alone.

How Prosopo Blocks Spam Form Signups

When a site's server verifies a Procaptcha token and includes the user's email, the provider runs that email through a series of checks alongside the CAPTCHA result, provided the site has the spam-email filter turned on. The full chain lives in @prosopo/provider and is worth walking through in detail because it is materially different from what most other providers do.

Stage One: The Maintained Disposable-Domain Corpus

The first check is the cheapest and stops the largest share of attacks. Every email's domain is extracted, lowercased and looked up against a continuously refreshed list of known disposable and spam email providers. The list is sourced from a configurable set of upstream URLs — operators add their own feeds via the spamEmailDomainsUrls config field — and merged into a single deduplicated set by a scheduled task that runs as often as the operator chooses. This handles the long tail of tempmail.*, guerrillamail.*, mailinator.*, 10minutemail.* and the thousand other recycled disposable services that dominate signup-spam logs.

spamEmailDomainsUrls: [
  "https://raw.githubusercontent.com/disposable/disposable-email-domains/master/domains.txt",
  "https://example.com/your-own-curated-feed.txt",
]

Stage Two: SSRF-Safe Domain Validation

Before any network call is made, the candidate domain is run through validateDomainForOutboundRequest. This rejects localhost-style names and domains written as literal loopback, private (RFC1918) or link-local IP addresses. The point is to make the next stage — which does perform DNS and HTTPS lookups against the candidate domain — safe to expose to attacker-controlled input. Domains that fail this check are treated as spam rather than retried.

Stage Three: The DNS-and-Redirect Chase

If the domain is not on the blocklist directly, the provider does something most other bot-detection tools do not bother with: it follows the domain through the DNS system to see what it actually points at.

The order of operations is deliberate. First, the provider makes an HTTPS request to the domain to see whether it redirects. A TLS error is logged but deliberately not treated as spam: plenty of small businesses run their email on a modern provider while the website on the same domain sits on an old server with a broken certificate. If the request redirects, the redirect target's domain is extracted and itself looked up against the spam list. Spammers love to register new throwaway domains that simply 301 to a known disposable service, because superficial validators only inspect the address as written.

If there is no redirect, the provider checks the domain's CNAME record, or if it has none, its MX record. A surprisingly large fraction of "novel" disposable services are simply CNAME aliases or MX delegations to a small set of well-known underlying providers; resolving one level deeper exposes the alias and blocks the address. The full implementation lives in packages/provider/src/tasks/spam/checkSpamEmail.ts.

Stage Four: Pattern-Based Evasion Catching

Even legitimate-looking domains can be abused at the local-part level. The Gmail dot trick — where a.l.i.c.e@gmail.com and alice@gmail.com deliver to the same inbox — and the Gmail plus-tag trick let one underlying account generate effectively unlimited apparent addresses. Prosopo's optional spam-filter rules, which each site turns on in the portal, handle these:

• A configurable maximum number of dots in the local part, defaulting to two.
• A set of curated default patterns the site can opt into, including one that flags any address with more than three dots in the local part.
• Detection of randomised plus-tag suffixes on Gmail/Googlemail (e.g. user+vkd38uoukd5@gmail.com).
• Gmail address normalisation, which strips dots and plus-tags from the local part before evaluating any custom regex, so that one operator-supplied pattern catches every variant of the same account.
• A safe, length-capped custom regex blocklist with ReDoS protection — lookaheads, lookbehinds and large repetition quantifiers are rejected at save time so that an operator cannot accidentally lock up their own verification endpoint.

Stage Five: Behavioural and Network Signals

The email layer is one component of a layered defence. Above it sit the frictionless captcha flow, IP reputation scoring, VPN/proxy/Tor/datacenter classification, and device fingerprinting that feed into the same verification call. The signals are combined rather than applied in sequence — an email on the spam list is a hard rejection, but a clean email from a flagged datacenter IP can still be rejected, and so can a clean email from a residential IP that fails on a behavioural signal. The point of the layered model is that defeating any single stage does not get an attacker through.

Trying It Yourself

If you are curious whether the disposable-domain layer would have caught the addresses you are seeing in your own logs, we have a limited-use Check Spam Email tool on the website. Paste in any email address you have received through a public form and the tool will tell you whether its domain is on the Prosopo spam list, or redirects, aliases or delivers mail to a domain that is. It runs the same domain check described in stages one to three above.

The full integration, including the captcha challenge layer that catches the bots which use clean inboxes, is a script tag and a container element on the client, plus one server-side verification call that passes the user's email:

<script src="https://js.prosopo.io/js/procaptcha.bundle.js" async defer></script>
<div class="procaptcha" data-sitekey="YOUR_SITE_KEY"></div>

Conclusion

Bots fill out forms because forms are a free, indirect distribution channel for advertising, a cheap enumeration surface for stolen credentials, a profitable target for free-tier abuse, an SEO laundromat for expired domains, and a reconnaissance ground for larger attacks. A honeypot will stop the worst of the first category and almost none of the rest. Stopping a real form-bot operation in 2026 requires looking at the email address as carefully as you look at the captcha solution, and looking at the underlying DNS as carefully as you look at the address.

Prosopo's spam-email filter does that work in the same verification call as the captcha, with the disposable-domain list refreshed on a schedule. If your contact form has been quietly filling up with @disposable.tld traffic for the last six months and you would rather solve it once than rebuild the same regex every quarter, get in touch.