The cheapest place to catch a bad address is the form
A cleaning run has just shown you a few thousand dead addresses, and somebody asks the obvious question: how did they get in? Every one of them came through a form.
There's a second reason with a sharper edge. Bots submit forms at scale, and a signup flow with no defense becomes a way for someone else to send confirmation emails to addresses that never asked for them, from your domain.
The order the work happens in
Fix the typos in the browser first
A domain suggestion for gmial.com costs nothing, needs no API call and catches a large share of real errors. Do this before anything more elaborate.
Check the MX record before you check the mailbox
A domain with no mail server cannot receive anything. It is one DNS lookup, it is fast, and it removes invented domains without a verification credit.
Verify asynchronously, with a short timeout
A full check involves a live connection to somebody else's server, so it takes as long as their server takes. Never let that block the form.
Fail open, always
If the check does not come back, accept the registration. An unresolved result usually means a receiving server refused the probe, and rejecting that person costs you a customer over another company's policy.
Rate limit and add a honeypot
Verification is not bot defense. A hidden field bots fill in and a per-IP limit stop the automated submissions that verification would otherwise charge you to check.
What each result means here
The same four results and their flags, read against this job. A catch-all worth keeping in one situation is one to exclude in another.
| Result | What to do with it |
|---|---|
| Valid | Accept and continue. No friction. |
| Invalid | Show an inline correction while the person is still on the page. This is the only moment a bad address can be fixed. |
| Catch-all | Accept. Common at businesses, and refusing these means turning away corporate signups. |
| Unknown | Accept and flag. A non-answer from a server is not the visitor's fault. |
| Role flag | Accept for a B2B product, where info@ is often the right contact. Question it for a consumer account tied to one person. |
| Disposable flag | The one case for blocking outright, and only if a throwaway signup genuinely costs you something. |
How you know it is finished
New signups from the last month show a bounce rate close to zero on the first send, and the form rejects nothing that a real person typed correctly.
What this does not fix
Form-level checking is low volume and high value: a few thousand signups a month sits inside the 100 free credits plus a $5 top-up for 1,000. Unknown results are not billed, which matters here because a form generates more of them than a batch does.
Questions people ask
Should a failed verification block a signup?
No. Use a short timeout, fail open, and only surface an inline correction when the address is clearly invalid. Blocking on a non-answer turns another company's server policy into your lost customer.
Does real-time verification slow down my form?
It adds the time a DNS lookup and an SMTP connection take, which is outside anyone's control because it depends on the receiving server. Run it asynchronously and the person never waits.
Is a regular expression enough for a signup form?
It catches malformed input and nothing else. A syntactically perfect address at a domain with no mail server passes every regular expression ever written.
Try it on the file in front of you
100 free checks a month, no card. Addresses we could not get an answer on come back labeled as unknown, and those are not billed.