Sign-Up Form Email Checks: Block, Warn or Allow? A Decision Table for Each Reason
For a sign-up form: block or ask to retype on Invalid format, No mail server, Typo domain and Mailbox not found; decide on Disposable address as a product choice; and allow risky results. Those are the reasons the API returns, and your form decides what each one does. The email verification for SaaS sign-up forms page has the overview; the API reference and quickstart have the calls.
The decision table
| Reason | Status | Suggested action | Why |
|---|---|---|---|
| Invalid format | invalid | Ask to retype | Not shaped like an address |
| No mail server | invalid | Ask to retype | The domain cannot receive mail |
| Typo domain | invalid | Suggest the fix | gmial.com is almost always a slip |
| Mailbox not found | invalid | Ask to retype | The mail server said no |
| Disposable address | invalid | Block or flag | A throwaway mailbox |
| Accepts all addresses | risky | Allow | Catch-all; real users live here |
| Role address | risky | Allow | Small teams use info@ |
| Mailbox check unavailable | risky | Allow, re-check later | Not a verdict on the user |
Block versus flag disposables
Blocking disposables is a trade-off. It keeps trial abuse and bounced onboarding emails down, but some privacy-minded users use them and a trial with no card is an easy target. A softer option is to allow the account but hold back marketing email and gate expensive features. Our test of blocking disposable emails on a sign-up form and the note on Gmail sign-ups on a B2B product go through the options.
Never block on a timeout
If the call is slow or fails, let the user in. Queue a re-check after sign-up. The Next.js sign-up guide shows a timeout-safe pattern, and stopping fake sign-ups covers the other layers, such as a honeypot.
Show a helpful message
Say what is wrong and how to fix it. "We could not find that mailbox, did you mean name@gmail.com?" converts better than a generic error. The email typo corrector shows the patterns you can suggest.
What this cannot do
- A valid result means the mailbox existed at the time; it does not prove the user owns it. For that, send a confirmation link.
- Yahoo and AOL accept mail for any address during the check, and Microsoft consumer mailboxes are not probed, so those come back risky.
- It does not detect a real person using a fake name.
Try it on your own users
Run a CSV of existing sign-ups on the verify page: the first 100 checks are free with a Google sign-in, no card. For the API plan, see pricing.
Common questions
Which email results should a sign-up form block?
Invalid results such as Invalid format and No mail server are safe to block or ask the user to fix. Disposable address is a product decision, and Mailbox not found is usually worth a prompt to retype.
Should a form block risky emails?
Usually not. Risky means the mailbox could not be confirmed, which includes catch-all domains, role addresses and providers that hide mailbox status. Many real users fall there.
What if the API is slow or down?
Let the sign-up continue and check again later. A check in the request path should never stop a real person from signing up.
Where do I call it from?
On blur or on submit from your server. The API reference and quickstart have samples.
What does the API cost?
Pro is $39 a month and includes 10,000 API calls a month (Business includes 100,000). The first 100 checks are free with a Google sign-in, no card.
Check your list before you send
Real mailbox checks over SMTP, and nothing is sent to the address. Sign in with Google and your first 100 email checks are free, no card. Plans for bigger lists are on the pricing page.