SaaS Signup Verification
Block disposable and fake signups at the form, in real time.
The Problem
Your signup form is the front door to the product, and it is the one place where anyone on the internet can put anything into your database. If the only thing standing between a throwaway address and a provisioned trial account is a regular expression that checks for an @ sign, you are going to collect junk.
What junk signups actually break
The obvious cost is the activation email that never arrives. The user typed the address wrong, or used a temporary inbox that expired ten minutes later, and now they cannot confirm their account. They do not email support about it. They leave, and you never learn why.
The less obvious costs are the ones that quietly corrupt how you run the company:
- Activation and conversion metrics stop meaning anything. Every fake signup is a permanent zero in the denominator. Your trial to paid rate looks worse than it is, so you optimise onboarding to fix a problem that is really a data problem.
- Free trial abuse. Disposable inboxes make it trivial to farm unlimited trials. One person cycles through them, and you pay for the compute, the seats and the support.
- Your transactional sending reputation. Password resets, receipts and onboarding sequences fired at addresses that do not exist generate hard bounces against the domain you rely on for messages that must arrive.
- Sales time. Reps work signups that were never real people, and the lead scoring model learns from noise.
- Billing and support overhead. Accounts that can never be recovered because the email behind them no longer exists become tickets, refunds and manual database surgery.
Why blocklists on their own do not hold
The common patch is a hardcoded list of disposable domains in the codebase. It works for a month. New throwaway domains appear constantly, and the list in your repo is only as current as the last time someone remembered to update it. Meanwhile it does nothing about the address that is simply typed wrong, or the domain that no longer publishes mail records, or the role inbox someone used because they did not want to give you a real one.
The timing problem
Cleaning the user table once a quarter does not help, because by then the fake account has already been provisioned, already skewed the cohort, already triggered the onboarding sequence and already bounced. The only moment where verification actually prevents damage is the moment the form is submitted, while the user is still on the page and can correct a typo.
The Solution
Mailthentic exposes a real-time API you call from your signup handler. The address is checked before the account is created, while the user is still in front of the form and can fix a mistake.
What the API checks, in the request
- Syntax: catches the typos and malformed input a simple pattern match lets through.
- Domain and MX records: the domain must resolve and publish mail exchange records. A domain that cannot receive mail cannot receive your activation email.
- Disposable detection: a maintained set of known temporary and throwaway domains are flagged, maintained centrally so you are not shipping a stale list inside your own codebase.
- Role-based flagging: maintained prefixes such as info@, admin@ and support@, so you can decide whether a shared inbox is acceptable for a trial account.
- Catch-all detection and risky or invalid detection, with a mailbox probe where the receiving server allows one.
Every response carries the status, the reason, the SMTP response code and a confidence score. That gives you room to build a policy instead of a binary wall: hard block the invalid and the disposable, allow the unknown through but hold the account for review, allow role addresses but skip them in your sales routing.
Being honest about the limits
If the signup uses a Gmail, Google Workspace, Outlook or Microsoft 365 address, the receiving server returns 250 OK even when the mailbox does not exist, because that is how those providers defend against harvesting. No verifier can confirm the mailbox in that case, and we report it as unconfirmed rather than pretending. The same applies to catch-all domains, which accept every address by design. Blocking on unknown would reject a large share of legitimate consumer and business signups, so the sensible policy is to block the definite failures and let the unconfirmed ones proceed with the normal double opt-in you already run.
Greylisting is handled correctly as well: a 421, 450 or 451 is a temporary deferral, not a rejection, and Mailthentic retries with a backoff instead of failing a genuine user.
Beyond the form
For the users already in your database, upload a CSV in bulk. Duplicates are removed before processing, so you are not charged for the same address twice. Push the verdicts into Brevo, HubSpot, Salesforce, Mailchimp or PlusVibe so marketing and sales work from the same clean record. Pay-as-you-go credit expiry follows the current terms shown on pricing, or run on a monthly plan. Contact data is never sold, shared or reused, and the service is GDPR aligned.
Key Benefits
-
Real-time API call at the form, so a bad address is caught while the user can still fix it, not weeks later in a cohort report
-
A maintained set of disposable domains detected centrally, so you stop shipping a stale blocklist inside your own codebase
-
Activation, trial to paid and retention numbers stop being diluted by accounts that were never real people
-
Protect the transactional domain that sends your password resets and receipts, by not firing them at addresses that do not exist
-
Status, reason, SMTP response code and confidence score on every response, so you write a policy instead of a binary block
-
Bulk CSV for the users already in your database, with duplicates removed before processing
Frequently asked questions
Where in the signup flow should the API call go?
Will this block real users by mistake?
Can you tell me whether a Gmail signup address really exists?
Why not just keep a disposable domain list in our own code?
Should I reject role-based signups like info@company.com?
What about the accounts already sitting in our database?
Ready to get started?
Start with 50 free verification credits. No credit card required.