How to Prevent Fake Signups and Bot Registrations

To prevent fake signups, stack several cheap defenses instead of relying on one big one. Check the email address at entry. Rate-limit the signup endpoint. Add an invisible bot challenge and a honeypot field. Keep new accounts locked until the email is confirmed. Then respond to suspicious signups with gradually more friction rather than hard blocks. No single control stops every bot, but together they make bulk fake registration expensive enough that most attackers move on.

What fake signups cost you

Fake registrations come in a few kinds. Each costs you something different:

• Bot account creation. Scripts that register accounts in bulk. OWASP catalogs this as OAT-019 Account Creation: creating many accounts through your normal signup flow, then using them for spam, laundering money or goods, spreading malware, or skewing reviews and surveys.
• Trial and promo abuse. Real people creating many accounts to keep getting free credits.
• Form spam and list bombing. Bots stuffing other people’s addresses into your newsletter or contact forms. Your confirmation emails then go to people who never asked, which generates complaints.
• Junk data. Fake leads in your CRM that waste sales time and distort reporting.

The costs add up: compute for free tiers, email sends that bounce, support tickets, fraud losses, and a sender reputation damaged by bounces and complaints.

A layered approach to preventing fake signups

OWASP’s Bot Management and Anti-Automation Cheat Sheet recommends layered controls at the network edge, in the application, and in business logic, rather than any single gate. For signup endpoints specifically, it names email or phone verification plus velocity limits as the first control.

Here’s how those layers map to a typical signup form:

Layer	Control	Stops	Friction for real users
Form	Honeypot field	Simple form-filling bots	None
Form	Email syntax + typo suggestion	Garbage input, honest mistakes	Very low
Server	Disposable-domain check	Throwaway-inbox abuse	Low
Server	Domain/MX check	Made-up domains	None
Server	Rate limits (IP, network, device)	Bulk scripted signups	None unless abusive
Server	Invisible bot challenge / risk score	Most automated traffic	Usually none
Account	Email confirmation before access	Fake and mistyped addresses, list bombing	One click
Business	Review queue / trial gating	Determined humans, fraud rings	Only for flagged accounts

Step-by-step: hardening your signup flow

Step 1: Add a honeypot field

Add a form field hidden from humans with CSS (not type="hidden", which many bots skip), labeled something plausible like “website.” Real users leave it empty. Many bots fill every field. OWASP’s cheat sheet suggests rejecting or tarpitting submissions that fill it in.

<div class="hp" aria-hidden="true">
  <label for="website">Website</label>
  <input type="text" id="website" name="website" tabindex="-1" autocomplete="off">
</div>
<style>.hp{position:absolute;left:-9999px;}</style>

On the server: if website has a value, return the same success page a real user would see, but don’t create the account. Giving bots no signal is better than giving them an error.

Step 2: Validate the email address

Run these checks on the server:

1. Syntax. Reject clearly malformed input.
2. Domain and MX. The domain must exist and accept mail.
3. Disposable domains. Compare against a maintained list. See how to block disposable emails at signup.
4. Typo suggestions. Offer gmail.com when someone types gmial.com.

Our free email verifier does all four for a single address, and also flags role-based addresses (info@, sales@) and free providers. It’s handy for testing your rules before you write code. It doesn’t contact the recipient’s mail server, so it can’t confirm a mailbox exists. That’s what the confirmation email in Step 5 is for.

Step 3: Rate-limit the signup endpoint

Bots need volume, and rate limits take it away. OWASP’s cheat sheet suggests velocity limits per IP, per network (ASN), and per device fingerprint, gives a limit of three signups per hour as an example, and recommends sliding-window or token-bucket algorithms over fixed windows. When a limit trips, return a generic 429 without revealing the exact threshold or retry timing.

Tune the numbers to your traffic. A university campus or a corporate office can legitimately send many signups from one IP, so prefer stepping up friction (a visible challenge) over a hard block when a limit trips.

Step 4: Add an invisible bot challenge

Modern challenges run in the background and only bother users who look suspicious:

• Google reCAPTCHA v3 returns a score from 0.0 (very likely a bot) to 1.0 (very likely a good interaction), and Google suggests starting with a threshold of 0.5 and adjusting based on your traffic (Google reCAPTCHA docs). Verify the token and action on your server.
• Cloudflare Turnstile offers managed, non-interactive, and invisible widget modes. The page gets a token that your server checks with Cloudflare’s Siteverify API (Cloudflare Turnstile docs).

OWASP’s guidance treats visible puzzle CAPTCHAs as a last-resort step-up, not the main defense. They’re hard for people with disabilities, and solving services can get past them. It also says to keep rate limits in place after a challenge is passed.

Step 5: Gate access behind email confirmation

Create the account in an unverified state and send a confirmation link. Don’t unlock trial credits, posting rights, API keys, or outbound features until the link is clicked. OWASP’s cheat sheet specifically recommends gating features behind email verification, not just sending a confirmation while the account already works.

This step does a lot:

• Fake and mistyped addresses never become active accounts.
• List-bombing victims get one confirmation email, not a stream of marketing.
• Bots that use real inboxes have to do extra work to click links at scale.

For newsletter and marketing forms, the same principle is called confirmed opt-in. See double opt-in vs single opt-in.

Step 6: Use graduated responses, not instant bans

OWASP recommends scaling the response to your confidence that something is abusive:

1. Low confidence: let it through, flag and log it.
2. Medium: step up with a visible challenge or extra verification.
3. High: slow responses down (tarpit) or limit what the account can do.
4. Very high: block specific actions.
5. Confirmed abuse: hold the account for manual review.

Hard-blocking on the first signal gives attackers instant feedback to tweak their scripts against. It also catches privacy-focused real users whose browsers look unusual, so OWASP suggests challenging them rather than blocking.

Step 7: Monitor and adjust

Log each decision with the signals that drove it (risk score, rule triggered, network, email checks), masking personal data. Watch:

• Signups per hour, by source and network
• Share of signups that never confirm
• Share of new accounts flagged or held
• Bounce rate on welcome and confirmation emails

A sudden jump in unconfirmed signups or welcome-email bounces is usually the first sign of a bot wave.

Email-specific signals worth scoring

Beyond the basic checks, some patterns in the address itself are worth weighing in a risk score: long random-looking local parts, newly registered domains, many signups that differ only by a +tag or dots, and bursts of the same domain. We cover these in detail in email signals for detecting signup fraud.

A cautionary example: PyPI, which already blocked disposable domains, found that one large bot campaign used Outlook and Hotmail addresses exclusively, and it responded by stopping new registrations with those domains (PyPI blog). Determined attackers will use mainstream free providers once throwaway domains are blocked. That’s why the confirmation and rate-limit layers matter more than any domain list.

Don’t punish legitimate users

Each defense has a cost. Keep it proportionate:

• Allow privacy aliases such as Apple Hide My Email. They forward to a real, reachable inbox.
• Allow plus addresses, but normalize them when enforcing “one trial per person.”
• Give accessible alternatives to any visible challenge, such as an audio option or a support contact. OWASP calls this out explicitly.
• Write clear error messages. “Please use a permanent email address so you can receive your login link” beats “Signup failed.”

For SaaS-specific onboarding patterns, see email verification for SaaS signups. For webinar and event forms, which get a lot of junk, see email verification for event registrations.

FAQ

What is the most effective way to prevent fake signups?

Requiring email confirmation before an account can do anything useful, combined with rate limits on the signup endpoint. Confirmation stops fake and mistyped addresses, and rate limits stop bulk automation. Add an invisible bot challenge and disposable-domain checks on top.

Do I still need a CAPTCHA?

An invisible risk-scoring challenge is worth having on most public signup forms. Visible puzzle CAPTCHAs work best as a step-up for suspicious traffic, not something every user has to solve, because they add friction and accessibility problems and can be solved by paid services.

How do I stop bots from signing up other people’s email addresses?

Use confirmed opt-in so the victim gets only one confirmation email and nothing more unless they click. Add a honeypot field, rate limits per IP and per target address, and an invisible bot challenge on the form.

Will blocking disposable emails stop bot signups?

It stops some of them, mostly low-effort abuse. Determined attackers move to free webmail or freshly registered domains. Treat disposable-domain blocking as one layer among several, not the main defense.

How can I tell if my signups are fake?

Look for signups that never confirm, welcome emails that bounce, bursts from the same network or domain, random-looking local parts, and accounts that do nothing after creation. A rising share of any of these usually means bot traffic.