The Size of the Problem

Fake signups are the tax most SaaS products silently pay without knowing the full bill. Nobody has a trustworthy industry-wide number for what share of trial signups are fraudulent — the percentages that circulate in vendor marketing don't trace to published methodology, so we won't repeat them — but the incentive structure explains why the problem is universal: anywhere a free signup yields something resellable (trial compute, email sending, a referral bonus, a new-customer discount), someone will script the signup. Promotional campaigns concentrate the incentive, which is why a discount launch so often arrives together with a registration spike that converts to nothing.

The attack side is thoroughly industrialised: algorithmically generated names and addresses, throwaway email domains registered to look like new providers, automated CAPTCHA solving, and distributed residential proxies to spread the source IPs. None of this is exotic — it's off-the-shelf tooling.

If your signup form is open to the public and not actively defended, you are being hit. Most product teams only notice when a downstream metric collapses: trial-to-paid conversion plummets for no apparent reason, email deliverability drops because you're blasting the world's spamtrap inventory, or support tickets start piling up about fake accounts associated with real customers' email addresses.

This post is a layered playbook for actually stopping this, ordered from cheapest to most invasive, with the tradeoffs of each layer.

Layer 1 — Validate the Email Address (Cheapest, Do It First)

The single biggest quick win. Most fake signups use either:

• Disposable email domains (mailinator, yopmail, temp-mail, guerrillamail, and thousands of clones)
• Made-up domains that don't resolve to an actual mail server
• Free webmail addresses with suspicious patterns (random character sequences at gmail.com, many dots in the local part to create "unique" addresses from a single base account)

Validation runs in three phases:

1. Syntactic: does the address parse as a valid email format? Free.
2. DNS/MX: does the domain have a valid MX record? ~10ms DNS lookup.
3. SMTP handshake: does the domain's MX actually accept mail for that local part? 200–1000ms, rate-limited by receiving servers.

You don't need to run phase 3 yourself — services like NeverBounce, ZeroBounce, and Kickbox do it at scale. More importantly, a maintained list of disposable email domains catches most fake signups before you even make an SMTP call. Drop-in libraries exist for every language and the lists are typically refreshed weekly.

Email validation catches the lazy majority — the operators who reach for mailinator-class domains because they're free and disposable by design. Predax ships this layer built in: both the WordPress and WooCommerce plugins screen against a list of thousands of disposable domains, sending only the domain half of the address — never the mailbox — with role-account and gibberish heuristics running locally on your own server.

The catch: sophisticated operators use real email addresses they control, and those pass every email check by definition. You need more layers.

Layer 2 — IP Intelligence (Catches What Email Checks Can't)

The same signal that catches credential stuffing catches fake signups. Look at the source IP of the registration request and apply the same logic:

• Datacenter IP → very unusual for a legitimate home signup. Challenge or block.
• Tor exit node → usually fraudulent for signup. Block with a helpful message.
• Commercial VPN → mixed. A lot of privacy-conscious users start their account on a VPN. Use as a soft signal, not a hard block.
• Known residential proxy pool → challenge with CAPTCHA or email OTP.
• Community block count > 0 → this IP has already been reported for abuse elsewhere. Block.
• Recent high velocity from the same /24 → someone is running a scripted signup run. Rate-limit the whole subnet.

The single API call is cheap — repeat IPs are served from cache — and slots in as middleware before your signup handler touches the database. Example in Node:

async function signupHandler(req, res) {
  // Layer 1: email validation
  if (isDisposableEmail(req.body.email)) {
    return res.status(400).json({ error: 'Please use a real email address.' });
  }

  // Layer 2: IP intelligence
  const ipData = await fetch('https://predax.io/api/v1/check/ip', {
    method: 'POST',
    headers: {
      'X-API-Key': process.env.PREDAX_API_KEY,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ ip: req.ip }),
  }).then(r => r.json());

  const c = ipData.classification || {};
  if (c.is_tor || (c.is_datacenter && c.risk_score >= 50)) {
    return res.status(403).json({ error: 'Signup is not supported from this network.' });
  }
  if (c.risk_score >= 60 || (c.flags || []).length > 0) {
    req.requireCaptcha = true;
  }

  // ... continue to user creation
}

Email validation and IP intelligence catch different attacker profiles — the first stops throwaway identities, the second stops throwaway networks — so combined they leave only the operator willing to pay for both real inboxes and residential proxy bandwidth. That survivor is expensive to be, which is usually all the defence you need: the goal isn't a perfect filter, it's making your signup form cost more to abuse than the next site's.

Layer 3 — Behavioural Signals on the Form Itself

Even after network-level filtering, you can catch more bots by watching how the form is submitted:

• Time-to-submit. A real user spends 10–60 seconds filling out a signup form. Bots commonly submit in under 1 second. If submission time is under 2 seconds, flag or reject.
• Honeypot fields. Add a visually hidden field called website or address2 with CSS display: none. Real users never fill it in; dumb bots fill every field by default. Any non-empty honeypot = guaranteed bot.
• Proof of browser. Submit a client-computed token (a lightweight JS challenge that runs a cryptographic operation in-browser). Headless bots that don't execute JavaScript fail. Puppeteer and Playwright-based bots pass but cost meaningfully more per signup — raising the attacker's cost.
• Field fill order. Real users fill fields top-to-bottom with small random delays. Bots fill all at once. Track the sequence and timing on the client, submit it with the form, check server-side.

None of these are unbreakable, but each adds friction for the attacker and none of them annoy legitimate users. Stack them and you catch a significant chunk of the bots that make it past Layers 1 and 2.

Layer 4 — Post-Signup Friction

Some fraud you cannot catch at the signup moment because there is no visible signal yet. Two common patterns work at the next step:

Email verification with a short-lived token. The user signs up, receives a confirmation email, and has to click the link within 5–15 minutes to activate the account. Real users check email within minutes; automated bots either burn through inbox capacity or can't receive the email at all (made-up addresses). Trial benefits should only unlock after verification so the attacker gets nothing for creating unverified accounts.

Delayed payment collection. Don't capture a card up front. Ask for it at the end of the free trial, once the user has actually used the product. This converts "create 10,000 fake accounts" from a free action into a task that provides zero attacker value.

Gradual feature unlock. Brand new accounts cannot invite teammates, send emails from their domain, make API calls above a low threshold, or access high-abuse features until they have existed for N days and completed some basic activity. This limits the damage a fake account can do before it gets caught.

Layer 5 — Detection After the Fact

No defence is 100%. Run daily or weekly reports on your new signups looking for clustering:

• Multiple accounts from the same IP — especially across /24 or /16 subnets
• Multiple accounts with the same email base (gmail.com + dot trick, same name + numeric suffix)
• Accounts with zero activity after N days that were created during a short window
• Similar user-agent strings across many accounts created near-simultaneously

When you find a cluster, bulk-delete them and feed the source IPs back into your real-time blocklist. This closes the loop: an attack detected at T+24h becomes a block at T+24h+1 second for every future attempt from the same source.

Metrics to Watch

Three metrics tell you whether your signup defence is working:

1. Fake signup rate. Percentage of new signups you flag or delete within 7 days. A number you should track week over week. If it's climbing, you're losing ground.
2. Trial-to-paid conversion rate. If this is stable, your real users are not being annoyed by your defences. If it drops sharply, you just added friction that broke real signups.
3. False-positive rate. Users who got blocked and then emailed support saying "I tried to sign up and it said my network wasn't allowed." Aim for under 0.5%. If it's higher, your thresholds are too tight.

Typical Attack Cost vs Defence Cost

The economics matter. An attacker running a fake signup operation spends roughly:

• Residential proxy: \$5–\$15 per GB of bandwidth
• CAPTCHA solver: \$1–\$3 per 1,000 solves
• Email address: \$0.001–\$0.01 per address (temp domains) or \$0.10–\$1.00 (verified inbox)
• Automation stack: Amortised developer time

Rough cost per successful fake signup against a well-defended site: \$0.20–\$2.00. Against a poorly defended site: \$0.001. Your job as a defender is to move your cost per signup attempted from the low end toward the high end. At \$1+ per successful attack, most attackers move on.

Summary

Fake signups are not solvable by a single technique. They are manageable by stacking cheap, layered defences that each catch a different attacker profile. Email validation catches the lazy operators. IP intelligence catches the datacenter and Tor traffic. Behavioural signals catch the mid-tier bots. Post-signup friction catches the sophisticated survivors. Detection-after-the-fact cleans up whatever slips through.

None of these layers is expensive to deploy. Together, they move the attacker's cost per successful fake account from near-zero to high enough that they target your competitor instead. That is what winning looks like in this space.

Related guides

• Form spam in 2026 — the other half of the registration-abuse problem.
• Credential stuffing: the complete guide — fake signups often feed directly into stuffing campaigns days later.
• Account takeover prevention — fake accounts are step one; ATO is step two.
• How IP risk scoring works — the score behind the registration-block rules in this guide.

See pricing to wire signup protection into your registration endpoint.