ARTICLE
If you run a SaaS product with a free trial, free credits, or a generous free tier, you already know the pattern.
A real user signs up once. An abuser signs up again and again — often with a new disposable address each time — until your trial, compute, storage, or API credits become a shared resource for people who never intend to pay.
Many teams respond with the obvious tool: email validation. That helps with deliverability. It does not fully answer the question your product actually needs answered at registration: Should this signup receive access?
This article explains the difference, what risk factors matter for trial abuse, and how a signup-risk decision API fits into the flow you already have.
Email validation answers whether an address looks mail-capable. Signup risk scoring answers whether a registration should receive costly product access. Free trial abuse needs an explainable allow, review, or block decision before you grant the trial.
Key takeaway: if your policy is "valid email = grant trial," you are optimizing for mailbox shape, not registration risk.
The real cost of free trial abuse · What email validation actually solves · The decision you need at signup · Risk factors that matter for trial abuse · A practical integration pattern · DIY disposable lists vs a decision API · What good looks like before you scale acquisition
Trial abuse is not only fake emails in the database. It is wasted product cost and distorted metrics.
Common damage includes burned trial seats and AI/API credits; inflated activation and retention dashboards; support load from throwaway accounts; abuse of promotional or referral value; and noisy analytics that make product decisions harder.
If your free tier has any marginal cost -- compute, storage, model usage, human onboarding -- repeat disposable registrations are a direct margin problem.
Traditional email verification products are built around deliverability and list hygiene. They typically help answer questions like: Is the address syntactically valid? Does the domain have mail infrastructure? Will this address bounce?
Those checks matter when you are sending mail. They are incomplete for signup trust. A disposable mailbox can be perfectly deliverable. A role address like admin@ can receive mail and still be a weak account-ownership indicator. A typo domain may look invalid enough to fail some checks and still slip through others. A placeholder identity may pass basic validation while still being low-quality for a trial grant.
So if your policy is valid email equals grant trial, you are optimizing for mailbox shape, not registration risk.
At registration, most products need a policy-ready recommendation: allow lower-risk users into the trial; review uncertain registrations before granting expensive benefits; block high-risk attempts before they consume resources.
That decision should be explainable so engineering and support can audit why something was flagged; deterministic -- same input context, same score behavior under the same model version; and integrable -- one backend call before you grant access, not a replacement for Clerk, Auth0, Supabase, Cognito, or your auth stack.
Signup Risk API is built around that decision. It analyzes the email and optional signup context (name, client IP on Growth and above, industry scoring profiles on Scale and above) and returns a 0-100 risk score, risk band, allow / review / block recommendation, check-level evidence, and optional plain-language explanation.
It is not SMTP mailbox verification, KYC, device fingerprinting, or payment-fraud scoring. It answers whether a registration should receive access based on signup-risk check results.
A useful signup-risk check looks beyond "is this email real?" and evaluates several independent risk factors.
Confirmed and likely disposable domains are the highest-frequency trial-abuse vector for many SaaS products.
DNS, MX, SPF, and DMARC evidence helps separate healthy domains from incomplete or suspicious mail infrastructure — without treating temporary DNS failures as invented risk.
Free consumer providers, business/custom domains, education, and government domains provide context. Important nuance: “not free” is not automatically “verified business.”
Shared mailboxes (support@, admin@, info@) are often poor ownership indicators for individual trials.
Lookalike or mistyped provider domains create both support debt and abuse opportunities.
Keyboard walks, numeric-only locals, and placeholder-style addresses catch low-effort fake registrations that disposable lists miss.
When a name is supplied, weak alignment with the email local-part can support a review decision — without claiming to verify a person’s real-world identity.
Where your plan includes it, datacenter / VPN / proxy / Tor-style infrastructure context can strengthen trial-abuse decisions. On Signup Risk, IP intelligence starts at Growth — Free and Developer do not include it.
No single risk factor should be treated as absolute proof of fraud. The value is combining evidence into a scored recommendation your application can route.
You do not need to rebuild authentication.
Integration Flow
1
User submits signup on your form.
2
Your backend calls Signup Risk API with the email and any allowed context.
3
You read decision.action and decision.risk_score.
4
Apply policy: allow, review, or block before granting credits.
Keep API keys server-side. Use the dashboard at https://app.signuprisk.com to create a first-party key, then follow the quickstart at https://docs.signuprisk.com.
Many teams start with an open-source disposable-domain list. That can catch obvious burners cheaply. It usually fails as a complete control because lists lag new disposable providers; deliverable free accounts can still be abusive; list matches rarely produce an explainable allow/review/block policy; and you still need domain, identity, and sometimes network context for harder cases.
A disposable list can be one input. It is rarely a complete trial-abuse system.
Before you drive heavy traffic into a free trial, confirm your backend can map allow / review / block to concrete trial behavior; know which optional checks you need on day one — email/domain may be enough; IP context and automation (bulk/webhooks/industry) can wait until volume justifies Scale and above; and make your free-tier policy explicit about what review means.
Email validation answers whether an address looks mail-capable. Signup risk scoring answers whether a registration should receive costly product access.
If free trial abuse is burning credits or polluting your funnel, evaluate registrations with an explainable allow / review / block decision before you grant the trial -- not after the damage is already in your metrics.
IP intelligence: Growth and above only. Bulk scoring, webhooks, and industry scoring profiles: Scale and above. Core email/name/domain scoring is available on every plan, including Free and Developer.
Create an API key in the dashboardFollow the API quickstartGet explainable allow, review, or block decisions from one API call.
