How to Prevent Free Trial Abuse

Two different problems that look similar

"Is this one address risky" and "is this person abusing the trial by signing up repeatedly" are related but genuinely different questions. A risk API answers the first one well. The second one is fundamentally about correlating multiple signups over time, which requires state your application maintains — the API evaluates one address per request and doesn't retain a cross-account view of your signup history for you.

What risk scoring catches directly

• Disposable-domain signups — the single most common trial-abuse pattern, since a fresh disposable mailbox is trivial to generate for every new trial
• Generated-looking local parts — scripted account creation frequently produces addresses with detectable shape patterns (see How to Detect Fake Email Addresses)
• Brand-new domains, especially in the signup context where that signal is weighted up specifically because it correlates with this kind of abuse

This alone removes a large share of low-effort trial abuse, because most abuse at scale relies on cheap, disposable, or scripted addresses rather than hand-crafted ones.

What needs your own application-level logic

A determined abuser using real, non-disposable addresses (a stock of Gmail accounts, for instance) will pass individual risk checks cleanly — nothing about any single address looks wrong. Catching this pattern requires tracking across signups, not evaluating one address in isolation:

• Track how many trial signups have originated from the same domain in a given window — a spike of new accounts all on the same free-provider or corporate domain is a pattern the risk score alone won't surface
• Watch for sequential or templated local parts across signups (user1@, user2@, user3@, or a consistent naming pattern) — a correlation across your own signup log, not something a single-address check exposes
• Combine with non-email signals you control — payment method reuse, device/browser fingerprinting, IP address patterns — email risk scoring is one input into trial-abuse prevention, not a complete system on its own
• Rate-limit trial creation per underlying identity where you have one (a verified payment method, a phone number) rather than relying on email alone as the uniqueness key

Being honest about what this solves

A stateless email risk API meaningfully raises the cost of trial abuse — it removes the cheapest attack (disposable domains, generated addresses) and forces an abuser toward real, individually-legitimate-looking addresses, which is slower and more expensive to produce at scale. It does not, on its own, solve the velocity/correlation half of the problem. Any vendor claiming a single email check solves trial abuse completely is overstating what an address-level signal can do.

A practical combination

const risk = await checkEmail(email, { context: "signup" });
if (risk.decision === "block") return reject();

const domain = email.split("@")[1];
const recentSignupsFromDomain = await countRecentSignups({ domain, windowMinutes: 60 });
if (recentSignupsFromDomain > SIGNUP_VELOCITY_THRESHOLD) {
  return flagForReview(); // email risk alone looked fine; the pattern didn't
}

await createTrialAccount(email);