How to Stop Fake Signups: The Complete Guide for SaaS Teams

The Real Cost of Fake Signups

Every SaaS product gets fake signups. The question is how many, and how much they cost you before anyone notices. Most teams underestimate both numbers by a wide margin.

When we analyzed 100,000 fake signups across BigShield customers, the breakdown was striking: 62% used disposable email domains, 24% relied on email pattern manipulation (random strings, leetspeak, keyboard walks at legitimate providers like Gmail), and 14% were credential farming operations using custom domains to create real-looking accounts for resale.

The financial damage is not hypothetical. Based on that same dataset and corroborating surveys of SaaS operators, the average company loses roughly $8,400 per month to fake signup activity. That number includes three cost categories most teams do not fully account for:

• Wasted compute and infrastructure: Fake accounts consume API calls, database rows, background jobs, email sends, and storage. For AI SaaS products, the GPU and token costs alone can run into thousands per month.
• Polluted analytics and bad decisions: When 20 to 30 percent of your signups are fake, your activation rate, retention curves, and conversion funnels are all lying to you. Teams spend weeks optimizing onboarding flows that were never broken, because the denominator was inflated with accounts that were never going to convert.
• Support and engineering overhead: Password resets for abandoned accounts, manual review of flagged users, abuse reports, and the ongoing whack-a-mole of blocking new burner domains. Engineering teams report spending an average of six to seven hours per week on fraud-adjacent cleanup work.

The compound effect is worse than any single line item. Bad data leads to bad decisions about product-market fit, marketing spend, and hiring. One founder we spoke with raised a Series A partly on growth numbers that were 25% fraudulent. They found out six months later. That is an expensive lesson.

Why CAPTCHAs Are Not Enough

CAPTCHAs feel like a solution. They are familiar. Every developer has implemented one at some point. But the economics of CAPTCHA solving have fundamentally changed.

Services like 2Captcha and CapSolver charge between $2 and $3 per 1,000 solves. That is $0.003 per CAPTCHA. Modern AI vision models crack image-based challenges with over 90% accuracy. For a bot operator creating thousands of fake accounts, CAPTCHA solving is not a barrier. It is a rounding error in their operating budget.

Meanwhile, CAPTCHAs actively hurt your conversion rate. Research shows they cause up to a 40% drop in signup completion, and 30% of users abandon the form entirely if a CAPTCHA is too complex or fails on the first try. Mobile users are hit hardest, tapping tiny image tiles on a phone screen with imprecise touch targets.

The fundamental problem is that CAPTCHAs ask the wrong question. They ask "are you a human?" when you need to know "are you a legitimate user?" A bot operator with a disposable email, a residential proxy, and a $0.003 CAPTCHA solve passes the human test every time. CAPTCHAs cannot detect disposable domains, pattern-generated email addresses, datacenter IPs, or velocity abuse. They are a single-point defense against a multi-vector problem. We wrote a detailed breakdown of why CAPTCHAs are dead if you want the full picture.

The better approach is invisible, server-side validation that examines the signals that actually indicate fraud. No friction for real users. No puzzles. No conversion penalty.

The Five Layers of Signup Fraud Prevention

Single-layer defenses plateau at 60 to 70 percent effectiveness. A disposable domain blocklist catches disposable domains and nothing else. IP blocking catches known bad IPs and nothing else. To get above 90%, you need to stack multiple detection layers and combine their signals into a composite risk score.

Here are the five layers, from basic to advanced, that together can stop 95% or more of bot signups.

Layer 1: Email Format and Deliverability

This is table stakes. Before you do anything else, confirm that the email address is structurally valid and can actually receive mail.

• Syntax validation: Goes beyond a basic regex. Checks for RFC 5322 compliance, catches edge cases like consecutive dots, missing TLDs, and invalid characters that slip past simple pattern matching.
• MX record lookup: Verifies the domain has mail exchange records configured. A domain without MX records cannot receive email, period. This catches typo domains like gmial.com and completely fabricated domains.
• SMTP mailbox verification: Connects to the recipient mail server and confirms the specific mailbox exists, without actually sending an email. This catches addresses like randomstring8847@outlook.com where the domain is real but the account is not.

These checks alone eliminate a significant chunk of junk signups. They run in under 100 milliseconds and are essentially free in terms of compute. If you are not doing at least this much, start here.

Layer 2: Disposable and Burner Domain Detection

Disposable email domains accounted for 62% of fake signups in our analysis. That makes this your highest-volume filter.

Effective detection goes beyond a static blocklist, though a good blocklist matters. BigShield tracks 945+ known burner domains, but the real value is in catching new disposable services as they appear. The signals that identify a burner domain include:

• Domain age: Registered in the last 48 hours? That is suspicious.
• MX infrastructure: Does the MX record point to known disposable mail infrastructure?
• Registration velocity: Did 200 accounts sign up from this domain in the past day?
• DNS patterns: Certain DNS configurations are characteristic of throwaway services.

This catches burner domains on day one, not day 30 when they finally land on a public list. The difference matters. A fresh disposable domain can generate thousands of fake signups before any static blocklist catches up.

Layer 3: Email Pattern Analysis

What about xk7qm3vb9@gmail.com? Gmail is not a burner domain. That address might technically deliver. But it is almost certainly not a real person's primary email.

Algorithmically generated email addresses have statistical signatures that are invisible to simple rules but detectable through pattern analysis:

• Entropy scoring: Real email addresses typically have a Shannon entropy between 2.5 and 3.5 bits. Bot-generated addresses cluster between 3.8 and 4.5 bits. The difference reflects the randomness that humans naturally avoid when choosing usernames.
• Keyboard walk detection: Sequences like qwerty123, asdfgh, and zxcvbn that follow physical key layouts. These appear at a much higher rate in bot-generated addresses than in human-chosen ones.
• Leetspeak substitution: Patterns like fr33tr1al or us3rn4me that bots use to evade exact-match filters.
• Random consonant clusters: Strings like xkjvtm or bpqzrl that no human would choose as a username. Character distribution analysis flags these reliably.

The key is that pattern analysis works probabilistically, not as a hard block. A person named Xhevat Krasniqi will not get caught, because the scoring accounts for legitimate name patterns. But xkjvt8839@gmail.com will flag, because its entropy profile and character distribution look nothing like how humans create email addresses.

Layer 4: IP and Network Intelligence

The IP address attached to a signup tells you more than most teams realize. A proper IP intelligence layer evaluates several dimensions:

• Datacenter and hosting detection: Is the IP associated with AWS, DigitalOcean, Hetzner, or another hosting provider? Legitimate users rarely sign up from cloud servers.
• Proxy, VPN, and Tor detection: Traffic routed through anonymization infrastructure is a meaningful risk signal, though not conclusive on its own.
• Geographic anomalies: A Gmail address originating from an IP in a country where Gmail usage is negligible is worth noting. So is an IP location that contradicts the timezone in the browser headers.
• Velocity tracking: 50 signups from the same IP range in an hour is not normal user behavior. Velocity checks across IPs, subnets, and ASNs catch coordinated signup campaigns.

No single IP signal is conclusive. A datacenter IP might belong to someone on a corporate VPN. A VPN user might be a privacy-conscious developer. That is why IP intelligence works best as a weighted input to a composite score, not as a standalone block rule. For more on this, see our deep dive on IP reputation scoring.

Layer 5: Behavioral and Cross-Signal Correlation

This is where prevention gets sophisticated. Layer five looks at patterns across signups, not just individual data points.

• Campaign detection: When an attacker creates 500 accounts over 48 hours, those signups share subtle correlations: similar email naming patterns, overlapping IP ranges, identical user agents, comparable form completion times. Campaign attribution groups these signups and scores them as a coordinated attack, even if each individual signup looks borderline.
• Email tumbling detection: Gmail treats john.smith@gmail.com and j.o.h.n.smith@gmail.com and johnsmith+spam@gmail.com as the same inbox. Attackers exploit this to create many "different" emails that all route to one account. Tumble detection normalizes these variations and catches the pattern.
• Velocity checks across dimensions: Not just IP velocity, but email domain velocity, user agent velocity, referrer velocity, and form-timing velocity. When multiple independent dimensions show unusual spikes simultaneously, the probability of a coordinated attack approaches certainty.
• Threat intelligence feeds: Real-time data from honeypots, spam traps, and abuse reports across the internet. If an email address or IP was involved in abuse elsewhere, that history informs the score.

Each layer catches a different slice of fraud. But the real power is in the composite score. A datacenter IP (moderate risk) plus a new domain (moderate risk) plus a consonant-cluster email (moderate risk) plus a two-second form completion (strong risk) produces a score that is unambiguously fraudulent, even though no single signal alone would be conclusive.

Code Example: Adding Email Validation to a Signup Form

Theory is nice. Code is better. Here is how to add multi-signal email validation to a Next.js signup flow using the BigShield SDK. For a more detailed tutorial with progressive enhancement and client-side feedback, see our full signup form guide.

First, install the SDK:

npm install @bigshield/sdk

Create a server-side API route that validates the email on form submission. Never call the BigShield API from the client, because that would expose your API key.

// app/api/auth/signup/route.ts
import { BigShield } from '@bigshield/sdk';
import { NextRequest, NextResponse } from 'next/server';
import { createUser, flagForReview } from '@/lib/auth';

const bigshield = new BigShield({
  apiKey: process.env.BIGSHIELD_API_KEY!,
});

export async function POST(req: NextRequest) {
  const { email, name, password } = await req.json();

  // Validate email through BigShield (runs 30+ signals)
  const validation = await bigshield.validate({
    email,
    ip: req.headers.get('x-forwarded-for') || undefined,
    userAgent: req.headers.get('user-agent') || undefined,
  });

  // Hard block: score below 30 means almost certainly fraudulent
  if (validation.score < 30) {
    return NextResponse.json(
      { error: 'This email address is not eligible for signup.' },
      { status: 422 }
    );
  }

  // Create the user
  const user = await createUser({ email, name, password });

  // Soft flag: score between 30 and 69 gets queued for review
  if (validation.score < 70) {
    await flagForReview(user.id, {
      score: validation.score,
      signals: validation.signals,
      verdict: validation.verdict,
    });
  }

  // Score 70+: clean signup, no further action needed
  return NextResponse.json({
    user: { id: user.id, email: user.email },
  });
}

This gives you a three-tier decision model: block, review, or allow. The thresholds (30 and 70) are starting points. You will tune them based on your own data, which we will cover in the measuring section below.

For client-side feedback before form submission, add a debounced validation call that checks the email as the user types:

// hooks/use-email-check.ts
import { useState, useEffect, useRef } from 'react';

export function useEmailCheck(email: string, debounceMs = 600) {
  const [status, setStatus] = useState<'idle' | 'checking' | 'valid' | 'invalid'>('idle');
  const abortRef = useRef<AbortController | null>(null);

  useEffect(() => {
    const looksValid = /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
    if (!email || !looksValid) {
      setStatus('idle');
      return;
    }

    setStatus('checking');

    const timeout = setTimeout(async () => {
      abortRef.current?.abort();
      const controller = new AbortController();
      abortRef.current = controller;

      try {
        const res = await fetch('/api/validate-email', {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({ email }),
          signal: controller.signal,
        });

        const data = await res.json();
        setStatus(data.verdict === 'deny' ? 'invalid' : 'valid');
      } catch (err: any) {
        if (err.name !== 'AbortError') setStatus('idle');
      }
    }, debounceMs);

    return () => {
      clearTimeout(timeout);
      abortRef.current?.abort();
    };
  }, [email, debounceMs]);

  return status;
}

The debounce prevents firing an API call on every keystroke. The abort controller cancels in-flight requests when the user keeps typing. And if anything fails, the hook returns to idle rather than blocking the signup. Fail open, not closed. You can always review accounts later. Blocking every signup because your validation layer had a hiccup is far worse than letting a few suspicious ones through.

Custom Rules for Edge Cases

Thirty-plus automated signals catch the vast majority of fraud. But every business has its own quirks, and sometimes you need rules that are specific to your situation.

Custom rules let you override or extend the default scoring for your particular use case. A few examples from real BigShield customers:

A fintech company blocking all .xyz TLDs. After analyzing their fraud data, they found that 94% of signups from .xyz domains were fraudulent. The base scoring system already penalized many of these, but the company wanted a hard block. A custom rule that auto-denies any .xyz email eliminated the remaining 6% that were slipping through with borderline scores.

A SaaS product blocking a competitor's domain. They discovered a competitor was creating trial accounts with corporate email addresses to benchmark features and scrape pricing data. A custom rule flagging signups from that specific domain for manual review solved the problem without affecting legitimate users.

An education platform allowing .edu domains with reduced scrutiny. Their user base was primarily students and faculty. Signups from .edu domains were almost always legitimate, so a custom rule boosted the score for those addresses, reducing false positives and speeding up onboarding for their core audience.

A B2B tool blocking free email providers entirely. They only wanted signups from corporate domains. A custom rule denying Gmail, Yahoo, Outlook, and similar providers enforced this policy at the validation layer rather than requiring extra logic in their signup handler.

Custom rules work as score modifiers layered on top of the standard signals. You can add positive or negative score adjustments, set hard allow/deny overrides, or flag specific patterns for manual review. They are configured through the BigShield dashboard, no code changes required, so your operations team can adjust them without deploying.

Measuring What You Catch

Setting up fraud prevention is only half the job. The other half is monitoring it and tuning it over time. Without visibility into what your validation is doing, you are flying blind.

There are three ratios you should track weekly:

1. Block rate: The percentage of signups that score below your deny threshold. If this number is climbing, it might mean you are under attack, or it might mean your thresholds are too aggressive. Context matters.
2. Review rate: The percentage landing in your review queue. This is your gray zone. If it is too high (above 15 to 20 percent), you either need more signals to resolve ambiguous cases or your thresholds need adjustment. A high review rate with a low conversion-from-review rate suggests your review queue is mostly catching real fraud and your block threshold could move up.
3. Allow rate: The percentage passing cleanly. This should be the large majority. If your allow rate drops below 70%, something is wrong, either with your traffic sources or your scoring configuration.

BigShield's dashboard provides validation logs that show every signup attempt with its score, the individual signals that fired, and the final verdict. This is critical for debugging false positives. When a legitimate user gets blocked, you can trace exactly which signals contributed to the low score and adjust your rules accordingly.

A practical workflow for ongoing tuning:

• Review your denied signups weekly. Look for patterns. Are legitimate users getting caught? Which signals are causing the most false positives?
• Check your review queue conversion rate. Of the signups you manually approved last week, how many turned out to be real users? If 90%+ of your review queue is genuine, your thresholds might be too strict.
• Monitor your allow-rate users for downstream abuse. Are allowed signups behaving normally? If you see a spike in abuse from accounts that scored 75+, a specific attack vector might be evading your current signal set.
• Adjust thresholds gradually. Move your block threshold up or down by five points at a time. Measure the impact over a week before changing again. Big jumps create big blind spots.

The goal is a feedback loop where your validation improves with every batch of data. The first week will require the most tuning. After a month, most teams settle into a configuration that catches 90%+ of fraud with under 1% false positives and needs only occasional adjustment.

Putting It All Together

Fake signups are not a minor nuisance. At $8,400 per month in average losses, they are a material cost that compounds over time through wasted compute, corrupted metrics, and diverted engineering effort. CAPTCHAs do not solve the problem. Single-layer defenses plateau quickly. The only approach that reliably works is multi-signal validation that examines the email, the network, and the behavioral context together.

The good news is that you do not have to build all five layers yourself. That is what BigShield does. Thirty-plus signals, composite scoring, custom rules, and full validation logs, all behind a single API call that returns a result in under 100 milliseconds. The cost of prevention is a fraction of the cost of the fraud itself.

If you want to see what your signup traffic actually looks like, BigShield's free tier gives you 1,500 validations per month. That is enough to audit a few weeks of signups and get a clear picture of how much fraud is getting through your current defenses. Most teams are surprised by the numbers.