Here’s the short version: you stop fake email signups with layers, not walls. Check every address in real time at the signup form (a sub-second API call that catches typos, dead mailboxes, and disposable domains before the account exists), make sure your disposable detection updates itself, and save double opt-in for the flows where a fake account actually costs you money. CAPTCHA is a bot tool, nothing more. It will never stop a human typing [email protected].
Layered like that, the junk gets filtered while genuine users notice nothing. Below is what fake signups quietly cost a SaaS, then the ladder step by step, so you can decide how far up you need to climb.
What fake signups actually cost
A fake signup looks free. Someone typed something into your form, your database gained a row, nobody got hurt. The bill arrives later, in places most teams never trace back to the form.
Your onboarding emails bounce, and your domain pays. Every new account triggers a welcome email, often a whole sequence. When the address behind the account doesn’t exist, those sends hard-bounce, and mailbox providers score your sending domain on bounce rate without caring that these were “just” welcome emails. Let enough fake addresses through and your transactional mail starts drifting toward spam folders, including password resets for real customers.
Your metrics stop meaning anything. Signup-to-activation is the number a product team stares at hardest, and fake accounts sink it. They register, never return, and now you can’t tell whether onboarding is broken or the funnel is polluted. Feed “signup” events to ad platforms as conversions and it compounds: the algorithm learns to find more of whoever produced them, freebie hunters included.
Trials and promo credits get farmed. Disposable addresses exist so that one person can be twenty new customers. If each account comes with trial days, API credits, or a discount code, every fake signup is a small subsidy paid in real money, plus the compute and support capacity those accounts burn.
Noise, everywhere. Sales calls dead leads. Lifecycle emails chase ghosts. Cohort analyses need asterisks. No single item is dramatic; together they make every downstream system a little less trustworthy.
Inflated user counts. “Total users” is a vanity metric, but it still gets quoted in board decks and investor updates. Decisions built on a user base that is partly phantom are worse decisions, and the gap between reported and real only widens with time.
You don’t need industry statistics to size the problem for your own product. Look up your welcome-email bounce rate. If it sits meaningfully above zero, fake signups are already inside.
Five ways to stop fake email signups, from least friction to most
Think of these as rungs on a ladder. The bottom ones are invisible to users and catch most of the junk; climb higher only when your abuse level justifies it.
1. Validate addresses in real time, at the form
The highest-value rung, and the place to start. When a visitor submits your form, an API call checks the address before you accept it: valid syntax, a real domain, a mail server that answers, a mailbox that actually exists, no disposable provider behind it. Modern verification is fast enough to hide inside the form’s normal submit round-trip — Reoon’s live validation typically answers in about half a second.
What you do with the result is where “without killing conversions” gets decided:
- Typos get a suggestion, not a rejection. Someone enters
[email protected]; show “Did you mean gmail.com?” inline and let them fix it in one tap. You just turned a guaranteed bounce into a working customer. - Dead mailboxes get a plain message. “We couldn’t find a mailbox at this address — mind checking the spelling?” is honest, accuses nobody, and keeps the person moving.
- Valid addresses feel nothing. No extra fields, no challenge screens, no visible delay.
Wiring it up is one call in your signup handler; the Reoon API documentation shows the request and the verdict fields you branch on. If your signup runs on WordPress, you can skip the code entirely — Reoon has a WordPress plugin that validates form entries for you.
2. Block disposable emails at signup — with detection that updates itself
Disposable services (Mailinator, 10 Minute Mail, and hundreds of quieter clones) hand out mailboxes that work for a few minutes and then evaporate. The address is technically real at the moment of signup and dead before your day-two email goes out. It’s the standard tool for trial farming, which is why disposable emails hurt SaaS products more than almost anyone else.
The trap is blocking them with a static list — some file of known domains you found on GitHub. It works on deploy day. Then it rots, because disposable providers register fresh domains precisely to escape those lists, faster than any manually maintained file can track. Six months in, half your list points at domains nobody uses anymore while the new ones walk right past it. What you want is dynamic detection: a service that keeps discovering new disposable domains and hands you the updates automatically. If you added real-time validation in step 1, check that your provider does this. Catching new disposable domains is the part that matters.
When you do catch one, keep the message friendly: “Temporary addresses won’t work here — you’ll need this email to log in later.” The disposable user either leaves (they were never going to pay) or enters a real address. Both outcomes beat a fake account.
3. Add double opt-in — but only where the stakes are high
Double opt-in, where the account doesn’t fully work until the person clicks a confirmation link, is the strongest proof available: the mailbox exists and its owner wants in. Fake signups drop to roughly zero behind it.
It charges for that certainty. Some share of genuine signups never confirm — the email lands in spam, arrives late, or the person simply wanders off — and each of those is a real user lost at the door. Pretending otherwise is how “let’s add double opt-in” becomes a quiet conversion leak.
So gate the valuable thing, not the door. Let people into the product on a validated address, and require confirmation only where a fake account has a direct cost: before granting promo credits, before enabling email-sending features, before anything compliance-sensitive. The full trade-off, including when single opt-in is genuinely the better call, is in our double opt-in vs single opt-in comparison.
4. Use CAPTCHA for bot waves, not as the whole plan
An honest word about CAPTCHAs, since they’re often the first thing teams bolt on: they solve a different problem. A CAPTCHA distinguishes humans from scripts. It never looks at the email address, so a human typing [email protected] passes every puzzle without slowing down. If your problem is trial abusers and fat-fingered typos, and for most SaaS products it is, CAPTCHA doesn’t touch it.
Where it earns its place is automation: mass fake registrations, credential stuffing, signup floods. Prefer the invisible, risk-based variants that only challenge suspicious traffic, and it’s perfectly reasonable to run with CAPTCHA off until a bot wave actually shows up. A hard puzzle in front of every signup, forever, taxes all your genuine users for the sins of bots.
5. Clean up the users you already have
Everything above protects the future. It does nothing about the addresses already sitting in your database from before the checks existed.
That backlog matters most right before a big send. A product announcement to “all users” is a campaign no matter what you call it internally, and announcement bounces damage your domain exactly like campaign bounces do. Before the next launch email, run the base through bulk email verification and suppress everything that comes back invalid. Keep the accounts — just stop emailing the dead ones.
That first cleanup also measures your problem: the invalid percentage in your existing base tells you how much junk the form has been waving through, and how much the earlier rungs are worth to you.
The balanced setup
For most SaaS products, this combination prevents fake signups without adding a single second of visible friction:
- Real-time validation on the signup form — one API call catching typos, dead mailboxes, and disposables in the same sub-second check
- Dynamic disposable detection — inherited from that API, never a static list
- Double opt-in on high-stakes flows only — credits, sending features, compliance steps
- CAPTCHA held in reserve — risk-based, switched on during bot waves
- A base re-verification before big announcement sends
Real users sail through. Trial farmers and typos stop at the form. Your welcome sequence goes out to people who exist.
If you’d like to watch the validation layer work before committing to anything, create a free Reoon account — you get free verification credits every day, no card required, which is plenty to wire the API into a staging form and see the verdicts come back on real submissions.
FAQ
Does email verification add signup friction?
None that users can feel. The check runs inside the form’s normal submit round-trip and finishes in well under a second. The only people who see anything are the ones whose address failed — and for a typo, an inline “did you mean” correction saves a signup that would otherwise have bounced away. That’s friction working in your favor.
Can’t I just use a free disposable-domain blocklist?
You can, and it will genuinely work for a while. But disposable providers create new domains specifically to escape public lists, so a static file starts decaying the day you deploy it. Unless someone on your team owns updating it (nobody ever does), expect it to quietly stop catching things within months. Fine as a stopgap, not a defense.
Will CAPTCHA alone stop fake signups?
No. CAPTCHA checks whether the visitor is human; it never evaluates the email address itself. Humans type fake and disposable addresses all the time and pass every challenge. Use CAPTCHA against bots, and pair it with real-time address validation for everything else.
Should I delete existing unverified users?
Suppress, don’t delete. Verify the base, keep every account, and simply stop emailing the addresses that come back invalid. Deleting throws away history you may want later, and the deliverability damage never came from storing dead addresses — only from sending to them.
