Email Verification for SaaS Companies

The Signup Form Is a Front Door for Bad Data

A SaaS company is built around its signup flow. It is the start of the funnel, the source of trial accounts, and the moment a stranger becomes a tracked user. It is also wide open. Anyone, and any bot, can put any string into the email field and create an account.

The result is a steady inflow of addresses that should never have become users. Some are honest typos from real prospects who will now never receive your onboarding email. Some are disposable addresses from temporary-mail services, used by people who want to look around without giving a real address. Others are created by automated abuse. Bot-created accounts in particular tend to have telltale gibberish in the local part of the address.

None of these accounts represent a real opportunity. Most never convert, and many were never going to. But every one of them is counted, stored, supported, and emailed as though it were a genuine user, and that is where the cost adds up.

What Fake and Invalid Signups Actually Cost

It is tempting to dismiss a fake account as harmless. It is not. The damage shows up in four distinct places.

Distorted metrics

SaaS companies run on funnel numbers: signups, activation rate, trial-to-paid conversion. Every fake or invalid signup inflates the top of that funnel and drags the conversion rate down, because the denominator is full of accounts that were never real prospects. You end up making product and go-to-market decisions on data that does not describe your actual market. A genuine improvement to onboarding can look like a failure simply because the cohort is padded with junk.

Wasted infrastructure and support

Fake accounts still consume resources. They take up database rows, occupy compute and storage, and sometimes generate background activity. When they do reach a human, they consume support capacity that should be spent on paying customers. None of this scales toward revenue, but all of it scales with the volume of bad signups.

Trial abuse

If your product offers a free trial, invalid and disposable emails are the mechanism that makes trial abuse possible. The math is simple from an abuser's point of view: if a trial grants two weeks of access and creating an account takes a minute, anyone willing to cycle through fresh disposable addresses can have your paid product for free, indefinitely. The disposable address is the cheap, renewable resource that the whole scheme depends on.

Damaged email deliverability

SaaS products are heavy lifecycle senders: verification emails, onboarding sequences, feature announcements, billing notices. Invalid addresses in your user base turn into hard bounces every time you send. Mailbox providers read a high hard bounce rate as a sign of poor list quality and respond by lowering your inbox placement, so even your real users start missing important messages. A practical bounce-rate benchmark is to keep total bounces under 3%, treat 3% to 5% as a cleanup warning, and treat anything above 5% as high risk.

How Email Verification Fixes This at the Source

Email verification checks whether an address is real and able to receive mail, and it does so without sending the user anything. Wired into the signup flow, it stops the bad data before an account ever exists, which is far cheaper than detecting and cleaning it afterward.

Block disposable addresses

Disposable detection identifies addresses from temporary and throwaway-mail services. For a SaaS product this is the single most valuable check, because the disposable address is the engine of trial abuse and a strong signal of a low-intent or fake signup. Blocking disposable addresses at the form removes the cheapest path to unlimited trials and makes abuse significantly more effort than it is worth.

Reject invalid addresses

The live deliverability check, a syntax check, an MX and DNS lookup, and a live SMTP handshake against the mailbox, confirms whether the address can actually receive mail. This catches both the honest typo and the gibberish address a bot generated. Rejecting an undeliverable address at signup means the prospect is asked to correct it on the spot, so a real user is not silently lost to a mistype, and a fake account is never created.

Flag role-based addresses and handle catch-all honestly

Role-based detection flags generic addresses such as admin@ or info@, which you may want to treat differently in onboarding. And because some company domains are catch-all and accept mail to every address, verification cannot always confirm an individual mailbox there. A good verifier says so plainly: it performs catch-all detection and reports the address as catch-all rather than guessing, so you can apply your own policy, perhaps an extra confirmation step, instead of being misled.

Where to Put Verification in a SaaS Product

The most important place is the signup form itself, in real time. As the user submits their email, a verification API call confirms the address before the account is created. If the address is invalid, the form shows an inline error and asks for a correction, which recovers real users who simply mistyped. If it is disposable, the signup can be blocked or routed to a stricter path. Because this happens before the account exists, your user base stays clean by construction rather than by cleanup.

Many SaaS teams add a second checkpoint at trial activation, verifying again before granting trial access as an extra gate against abuse, and pairing it with measures such as normalizing plus-addressed Gmail variations. Verification at signup also works well alongside an email confirmation step: verification proves the mailbox exists, and the confirmation click proves the person controls it.

Finally, run periodic bulk verification over your existing user and contact lists. Email addresses decay over time, so even users who were real and verified at signup accumulate dead addresses as people change jobs and providers. A bulk clean before major lifecycle sends keeps bounce rates low and your sender reputation healthy. The pattern most SaaS companies converge on is real-time verification at signup as the primary gate, plus periodic bulk cleaning for maintenance.

• Put verification before the account row is created, not after the welcome email bounces.
• Log result categories so product, growth, and fraud teams can see signup quality by channel.
• Clean free-trial, inactive-user, and newsletter segments before large lifecycle campaigns.
• Keep email confirmation for proof of control; use verification for proof that the mailbox can receive mail.

How to Verify with VeriMails

VeriMails gives a SaaS product both pieces from one account. The REST API verifies an address in real time, designed to be called from your signup form or registration endpoint. Each call returns a clear result, fast enough to run inside form submission without a noticeable delay, and the response tells you whether the address is deliverable, undeliverable, or disposable so your application can accept, block, or prompt for a correction. Bulk verification handles your existing user list: export it as a CSV, upload it, and VeriMails returns a results file marking every address.

Every address, by API or in bulk, runs the complete pipeline: syntax validation, MX and DNS checks, a live SMTP handshake, catch-all detection, disposable detection, and role-based detection. Results return clear verification statuses, and catch-all domains are reported honestly as catch-all rather than dressed up as a confirmed result.

Pricing is built for products at any stage. Verification costs from $0.0019 per email, with 10,000 credits for $19 and volume up to 5 million credits for $1,499, plus subscription plans from $15 to $299 per month for products with steady signup volume. Real-time and bulk checks both draw from the same credit balance. Every new account includes 100 free credits on signup, with no credit card required, and those credits never expire, so you can wire verification into your signup flow and test it before paying anything.

Frequently Asked Questions