How to Stop Fake and Invalid Emails at Signup Without Hurting Conversions

Every invalid address in your database walked in through a door you control. Most teams only find out months later, when a campaign bounces and the sender reputation has already taken the hit. The cheap moment to catch a bad address is while the person who typed it is still looking at the form.

This post covers what actually gets typed into an email field, why the usual defences miss most of it, and how to add real-time validation without turning your signup into an obstacle course.

What actually gets typed into a signup form

Five different things arrive at an email input, and only one of them is a subscriber you can reach.

1. Typos. gmial.com, hotmial.com, yahooo.com, a missing letter in the local part. This person wanted your emails and will never receive one. It is the most expensive category, because you lose a lead who was already convinced.
2. Disposable addresses. Ten-minute inboxes created to collect a lead magnet and abandoned before your welcome email lands. See disposable email addresses for how they behave over time.
3. Role-based addresses. info@, sales@, support@ — shared inboxes read by several people, with higher complaint rates than personal addresses. Not fake, just different. Our post on role-based addresses covers when they are worth keeping.
4. Bot and junk signups. Form spam, competitors poking around, asdf@asdf.com. Volume varies wildly by how visible your form is.
5. Well-formed but dead. Spelled correctly, real domain, mailbox closed two years ago. Nothing on the client side can detect this — the address looks perfect right up until it bounces.

That last category is larger than most people expect. In our H1 2026 benchmark — a distribution analysis of 229,305 addresses across 377 real mailing lists — 10.2% of addresses were invalid and a further 8.7% came back risky. Those lists were not built carelessly; they were built without a check at the door.

Why the usual defences miss most of it

Regex validation

A regular expression confirms shape, not existence. asdf@asdf.com passes every regex ever written. So does an address at a domain that has no mail server, and so does a mailbox that was deleted last year. Regex is a formatting check, and treating it as validation is the single most common mistake in signup forms.

An MX lookup on its own

Better: it proves the domain is configured to receive mail, which kills off misspelled domains that do not exist. But the popular typo domains — gmial.com, hotmial.com — are mostly registered by squatters who run real mail servers precisely to catch this traffic, so an MX check waves them straight through. And it says nothing about the specific mailbox: on a catch-all domain the server accepts every address you throw at it.

Double opt-in

Genuinely useful, and we recommend it — but it confirms intent rather than filtering bad input. You still pay to send the confirmation, you still take the bounce, and a mistyped address simply never confirms, so the subscriber disappears and you never learn why. The two solve different problems; see double opt-in vs single opt-in.

CAPTCHA

Stops automated submissions. Does nothing about a human who types gmial.com, which is the majority of what a real form collects.

The four checks that belong in a signup form

1. Syntax and typo detection. Not just pass or fail — if someone types gmial.com, offer gmail.com. This recovers subscribers instead of rejecting them.
2. Domain and MX records. Does the domain exist and accept mail at all?
3. Disposable and role-based flags. Cheap to check, and you need them to decide policy rather than to block outright.
4. A real-time mailbox check. The SMTP conversation is the only step that answers the actual question: does this mailbox exist?

Block, warn or accept: decide before you build

Most conversion damage comes from teams treating validation as a binary gate. It is not. Each result deserves a different response:

The last row matters more than it looks. Mail servers greylist, rate-limit and time out for reasons that have nothing to do with the address. If your form blocks on unknown, it will quietly turn away real customers on exactly the days your traffic is highest. Fail open, always.

Where the check belongs

Client-side for the experience, server-side for enforcement. The browser check gives instant feedback and the typo suggestion; the server check is what actually protects your database, because anyone can bypass JavaScript. Three rules save most of the pain:

• Validate on blur, not on every keystroke. You pay per check, and a half-typed address is always invalid.
• Set a time budget and honour it. Wait a second at most; if no answer has come back, accept the address and verify it asynchronously.
• Store the result with the record. When that address bounces in six months, you want to know what it looked like on day one — it is the difference between a list problem and an acquisition problem.

Two ways to do this with ClearBounce

Shield, if you would rather not touch the backend

ClearBounce Shield attaches to an existing input and validates as the user types. Rules are set in the dashboard — block disposables, block catch-all domains, block free providers — and blocked attempts are logged, so you can see what your form is actually collecting.

<!-- ClearBounce Shield -->
<script src="https://clearbounce.net/shield/widget.js"></script>
<script>
  ClearBounceShield.init({
    shieldId: 'your-shield-id',
    inputSelector: 'input[type="email"]',
  });
</script>

The API, if you control the server

curl -X POST https://clearbounce.net/api/v1/verify \
  -H "X-API-Key: your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"email": "jane@gmial.com"}'

The response carries both the verdict and the reasoning, so you can apply the table above in code. Note what happens with the typo address: because gmial.com runs a real mail server, the result is not a hard rejection — it comes back risky, with the suggestion attached (response trimmed for readability):

{
  "success": true,
  "data": {
    "status": "risky",
    "subStatus": "low_quality",
    "checks": {
      "syntax": true,
      "mxRecords": true,
      "isDisposable": false,
      "isRoleBased": false,
      "hasTypo": {
        "original": "gmial.com",
        "suggested": "gmail.com",
        "confidence": 0.87
      }
    }
  }
}

In a signup flow, hasTypo is the field worth wiring up first. It converts a lost subscriber into a one-click correction, which is the only branch of this whole exercise that adds subscribers. Full field reference is in the API documentation.

What to do with risky and catch-all results

Catch-all domains accept mail for every address, real or not, so no verification service can confirm an individual mailbox on them without sending. Many providers quietly report these as deliverable; we report them as risky, because that is what they are. At a signup form the right move is to accept the address, tag it, and re-verify the segment before it goes into a large send. Our post on what to do with catch-all addresses goes into the trade-offs.

How to tell whether it worked

• Bounce rate on the first campaign after signup. This is the number the whole exercise exists to move.
• Blocked signups, broken down by reason. If disposables are 15% of your form traffic, the problem is what you are offering, not your validation.
• Conversion rate, before and after. If it dropped, you are blocking too much — almost always role-based addresses, catch-all domains, or unknown results that should have been let through.

Frequently asked questions

Can you validate an email address in real time on a signup form?

Yes. Run the check when the user leaves the email field, give it a short time budget, and accept the address if the answer has not arrived in time. The check confirms syntax, the domain's MX records, whether the domain is disposable or role-based, and whether the mailbox itself accepts mail. Enforce the result on your server as well, since anyone can bypass client-side JavaScript.

Should I block disposable email addresses at signup?

It depends on what the signup is worth. For paid plans, free trials and anything with an ongoing relationship, blocking disposable addresses is reasonable. For an ungated content download it usually costs you more leads than it saves, and tagging the address is the better trade.

Does real-time email validation hurt conversion rates?

Only if you block too much. Blocking addresses that genuinely cannot receive mail does not cost you real subscribers. Conversion drops when a form also blocks role-based addresses, catch-all domains or results that came back as unknown, because most of those are real people. Block the undeliverable, suggest a correction for typos, and accept the rest with a flag.

Is double opt-in enough on its own?

Double opt-in confirms intent, but it is a confirmation step rather than a filter. You still pay to send the confirmation email, you still take the bounce, and a mistyped address simply never confirms, so you lose the subscriber without ever learning why. Validation at the form and double opt-in solve different problems and work best together.

Conclusion

Validation at the form does not replace cleaning your list; it reduces how much there is to clean. Block what genuinely cannot receive mail, offer a correction when someone fumbles a domain, flag what is uncertain, and never let a slow mail server cost you a customer. Done that way, the check is invisible to everyone typing a real address — which is the entire point.