How to stop fake signups

What it costs you

• trending_downYour sender reputation, which is the expensive one. Fake addresses bounce, spam traps get hit, and your deliverability falls for every real customer too.
• trending_downEvery metric you make decisions with: signup conversion, activation, retention cohorts, and the CAC you report to whoever funds you.
• trending_downInfrastructure you are paying for on behalf of nobody, plus any per-seat or per-user cost your own vendors charge you.
• trending_downSupport and moderation time, which scales with account count rather than revenue.
• trending_downYour database as an asset, because once real and fake are mixed you cannot cleanly separate them later without guessing.

How the attack runs

1. 01

   Find a form with no meaningful cost

   Bulk registration is only worth automating when an account is free, instant, and useful the moment it exists. Anything that delays usefulness (email confirmation that actually gates access, manual approval, a payment step) changes the arithmetic before any detection does.

2. 02

   Automate the submission

   At the cheap end this is a script posting directly to your registration endpoint, skipping your front end entirely. At the expensive end it is a real browser driven programmatically, which behaves much more like a person because it is one, mechanically speaking.

3. 03

   Supply identities in bulk

   Generated local parts on a domain the operator controls, disposable providers, or addresses from a breach list. The addresses are usually syntactically perfect, because generating valid-looking email is trivial.

4. 04

   Spread the source

   Datacenter ranges first, because they are cheap, and residential proxy networks once datacenter stops working. The same account creation then arrives from thousands of ordinary-looking consumer connections.

5. 05

   Use the accounts, or do not

   This is the step people forget. A large share of fake signups never do anything. They exist to be sold later, to age before use, to place a link, or because your form was simply on a list somebody was working through.

The signals that do

These are the signals that carry weight on fake signups, and why each one is the signal rather than the obvious alternative. Not all of them are ours: the ones marked you build this genuinely work and Kaidn does not check them, so you would be wiring them up yourself. Listing those unlabelled would read as a claim we cannot support.

The useful thing to understand about fake signups is that most of them are not trying to take anything from you. That sounds like good news and it is not, because it means the incentive you think you are protecting is often not the incentive driving the attack.

Accounts get created to be sold later, to age until they look established, to place a link, to sit in a list somebody bought, or simply because a script was working through a range of targets and your form answered. Removing the reward does nothing to any of that.

Two different problems wearing one name#

It is worth separating them, because the defences differ.

Automated bulk registration is a machine problem. Thousands of accounts, no human at the keyboard, and the giveaway is in how the session behaves rather than what it claims to be. This is the one that responds well to automation detection.

Human-driven fake registration is somebody genuinely sitting there, creating accounts by hand, usually because there is money at the end of it. Every automation signal comes back clean, because there is no automation. That is bonus abuse and it needs relationship signals, not bot detection.

Most teams buy a defence for one and are surprised when the other continues.

The cost you will feel first is email#

If you take one practical thing from this page: the deliverability damage arrives before anything else, and it is the hardest to undo.

Send a welcome email to a few thousand generated addresses and you will hit hard bounces and, worse, spam traps. Mailbox providers read that as a sender who does not know who their recipients are, and the penalty applies to every message you send afterwards, including the ones your paying customers are waiting for.

This is why "we will clean them up later" fails as a strategy. The reputational hit already happened, at the moment you first mailed the list.

Make the account worth less at the moment it is created#

The most effective structural change is usually not a detection one. It is to move the value of an account away from the instant it exists.

If a new account can immediately send messages, place links, consume API quota or appear in a public directory, bulk creation is worth automating. If those capabilities unlock after some real usage, or after a first payment, then the same attack produces thousands of accounts that do nothing useful for the attacker, and the economics quietly stop working.

Detection then handles the residue rather than carrying the whole load.

Where we sit#

We score the registration event: automation traits from the browser, form timing, email identity and domain infrastructure, IP and ASN reputation, and velocity across your traffic. The response is allow, review or block with the checks that fired and their weights, so you can set the line yourself rather than accept somebody else's.

We are not a CAPTCHA and we do not challenge the user. If you want a product that interrupts the person in the form, that is a different tool and reasonable to run alongside.

Scoring the registration#

The event, and the reasons worth branching on:

const r = await kaidn.score({
  event: "signup",
  user_id: user.id,
  ip: req.ip,
  email: user.email,
  device_id: body.kaidn_device_id,
  timezone: body.kaidn_timezone,   // checked against the IP country server-side
});

// automation is the one class worth refusing outright: there is no user to lose
const automated = ["headless_browser", "emulated_environment", "engine_ua_mismatch", "os_mismatch"]
  .some((code) => r.reasons.includes(code));

if (automated) return Response.json({ error: "unsupported client" }, { status: 403 });

// everything else: create the account, withhold what it is worth
if (r.verdict !== "allow") return createAccountUnverified(user, r.event_id);

return createAccount(user);

Collect the device signal at submit, and fail open#

The browser half is one import and one call, made at the moment they act rather than on every page load. The catch is not optional: a blocked script, an ad blocker or an offline visitor must never stop somebody signing up.

import { beacon } from "@kaidn/fp";

form.addEventListener("submit", async (e) => {
  e.preventDefault();

  let deviceId = null;
  try {
    // fingerprints the browser AND beacons it to the edge, ~200ms
    const fp = await beacon("https://api.kaidn.io/v1/fp", PUBLISHABLE_KEY);
    deviceId = fp.device_id;
  } catch {
    // FAIL OPEN. Your server scores the event either way, with one signal fewer.
  }

  await fetch("/api/signup", {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ email: form.email.value, kaidn_device_id: deviceId }),
  });
});

Something to measure before you buy anything#

Take last month's signups and plot time-to-submit on the registration form. If there is a spike under two seconds, you have automation and you now know its share. That is free, takes an hour, and tells you which of the two problems above you actually have.