How to stop fake signups

What it costs you

• trending_downYour email deliverability, which is the expensive one. Fake addresses bounce, spam traps get hit, and your mail stops arriving for real customers too.
• trending_downEvery number you make decisions with. Signup conversion, activation, retention, and the cost-per-customer you report to whoever funds you.
• trending_downInfrastructure you are paying for on behalf of nobody, plus any per-user fee your own vendors charge you.
• trending_downSupport and moderation time, which grows with account count rather than revenue.
• trending_downYour database as an asset. Once real and fake are mixed together, you cannot cleanly pull them apart later without guessing.

How the attack runs

1. 01

   Find a form that costs nothing to submit

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

2. 02

   Automate the submission

   At the cheap end, a script posts straight to your registration endpoint and never touches your front end. At the expensive end, a real browser is driven by software, which behaves much more like a person because mechanically it is one.

3. 03

   Supply emails in bulk

   Made-up addresses on a domain they own, throwaway providers, or addresses from a breach list. The addresses are usually perfectly well formed, because generating valid-looking email is trivial.

4. 04

   Spread out where it comes from

   Data centre addresses first, because they are cheap. Residential proxies once data centre stops working. The same signups then arrive from thousands of ordinary-looking home connections.

5. 05

   Use the accounts, or do not

   The step people forget. A large share of fake signups never do anything at all. They exist to be sold later, to age until they look established, to plant 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. It is not, because it means the reward you think you are protecting is often not what is driving the attack.

Accounts get created to be sold later, to age until they look established, to plant 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 with one name#

Worth separating, because the defences are different.

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

Fake signups made by hand are somebody genuinely sitting there creating accounts, usually because there is money at the end. Every automation signal comes back clean, because there is no automation. That is bonus abuse, and it needs signals about how accounts connect to each other, not bot detection.

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

The first cost you feel is email#

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

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

That is why "we will clean them up later" fails. The reputation hit already happened, the moment you first mailed the list.

Make a new account worth less on day one#

The most effective change here is usually not a detection one. It is moving the value of an account away from the second it exists.

If a new account can immediately send messages, plant links, burn API quota or show up in a public directory, bulk creation is worth automating. If those things unlock after some real usage, or after a first payment, the same attack produces thousands of accounts that are useless to the attacker, and the economics quietly stop working.

Detection then mops up what is left, instead of carrying the whole load.

Where we sit#

We score the registration: signs of a script in the browser, form timing, the email and the domain behind it, IP and network reputation, and how fast the same pattern is repeating across your traffic. You get back allow, review or block, with the checks that fired and what each one counted for, so you set the line yourself rather than accepting somebody else's.

We are not a CAPTCHA and we never interrupt the user. If you want a product that stops the person in the form, that is a different tool and it is reasonable to run both.

Scoring the registration#

The call, 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 when they act rather than on every page load.

The catch is not optional. A blocked script, an ad blocker or a flaky connection 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 chart how long each one took to fill in the form.

If there is a spike under two seconds, you have automation, and you now know what share of your signups it is. That costs nothing, takes an hour, and tells you which of the two problems above you actually have.