Email Verification for SaaS: Stop Fake Signups
Fake signups drain your free tier, skew your metrics, and quietly damage the deliverability of the transactional email your real users depend on. Verifying the address at signup closes that door without blocking genuine people.
Fake signups are not a vanity-metric problem. They poison your activation rate, burn free-tier compute, hand attackers a foothold for fraud, and quietly wreck the deliverability of the transactional email your real users depend on. The fix is not a harder CAPTCHA. It is checking, at the moment of signup, whether the address someone typed can actually receive mail.
This is the difference between accepting an account and accepting an address. Most SaaS signup forms validate the format and stop there. That leaves the door open to disposable inboxes, typo addresses, and bots cycling through made-up mailboxes.
What a fake signup actually costs you
The damage is rarely one big event. It is a slow tax across several systems at once.
- Trial abuse. One person spins up twenty trials with twenty disposable addresses to dodge limits. Your free tier becomes a free service.
- Polluted analytics. Signup-to-activation, retention cohorts, and funnel numbers all skew when a chunk of your "users" never existed.
- Wasted onboarding sends. Every welcome email, verification link, and drip to a dead address is a hard bounce.
- Deliverability blowback. Enough bounces and spam-trap hits and the mailbox providers throttle you. Now your password resets and receipts to real customers land in spam or vanish.
That last point is the one people miss. Transactional email is your highest-trust channel, and fake signups attack it from the inside.
Where verification fits in the signup flow
You verify the address before you create the account and before you send the first email. Two timing options, and you can run both:
- Real time, on the form. An inline API call as the user moves off the email field. Bad addresses get caught while the person is still there to fix a typo.
- Server side, on submit. A check inside your signup endpoint that decides whether to create the account, flag it, or reject it. This is the one that actually stops bots, since it cannot be skipped from the client.
What a real check looks at
Format validation alone is close to useless against motivated abuse. A serious check runs several layers, and each one closes a different gap.
| Layer | What it catches |
|---|---|
| Syntax and MX records | Typos and domains that cannot receive mail at all |
| Mailbox probe (SMTP) | Domains that exist but where the specific mailbox does not |
| Disposable detection | Throwaway services used to farm trials |
| Catch-all handling | Domains that accept everything, where deeper probing is needed |
| Role and gibberish flags | info@ addresses and random keyboard mashing from bots |
The hard cases are Microsoft 365 mailboxes and catch-all emails, where a plain SMTP check returns "accepted" for any address you ask about. Tooling that actually probes those, rather than guessing, is what separates a useful result from a coin flip. Prime Verifier runs its own sending fleet specifically so these checks return a real answer instead of "unknown".
How to act on the result without blocking real users
Do not treat verification as a simple yes or no gate. A blunt block will eventually reject a legitimate person on a quiet domain. Tier your response instead:
- Deliverable. Create the account, send the welcome email.
- Undeliverable or disposable. Reject at the form with a clear message, or require a different address.
- Risky or unknown. Allow the signup but hold full access behind a confirmation click, and skip marketing sends until they confirm.
The confirmation email (double opt-in) still matters. Verification tells you the address is real; the click tells you the person controls it. Together they stop almost everything.
A practical implementation order
- Add a server-side verify call inside your signup endpoint. Client-side checks are nice for UX but trivial to bypass.
- Map the verification result to your three tiers above.
- Suppress onboarding and drip sends for anything not confirmed deliverable. This protects your sender reputation directly. See improve email deliverability.
- Run a one-off pass over your existing user table to find dead and disposable addresses already inside. Email list hygiene is the same engine pointed at your back catalogue.
If you want to see the categories before wiring anything up, the free email verifier on the homepage gives you the same result fields the API returns, and new accounts get 100 free verifications. For volume and the verification API, check the pricing page.
FAQ
Will verifying at signup slow down my form?
A real-time check typically returns in under a second for most domains, and you can run it asynchronously so the field validates while the user fills the rest of the form. For the strict gate, do the check server side on submit, where a small added latency is invisible next to account creation and the first email send.
Can verification stop every bot?
No single layer does. Verification removes the cheap, high-volume abuse: disposable addresses, dead mailboxes, and gibberish. Pair it with double opt-in and basic rate limiting and you cover the realistic attack surface. Anything determined enough to beat all three is rarely worth their effort against a normal SaaS.
Does this really affect my transactional email?
Yes, and that is the strongest reason to do it. Sending welcome and reset emails to addresses that bounce raises your bounce rate and trips spam filters, which then suppress delivery to your genuine users. Cutting the bounces at signup keeps the channel your paying customers rely on healthy. More on the mechanics in our reduce email bounce rate guide.