Stop Bad Email Addresses at the Signup Form

Every bad address in your list entered through a door you control. Somebody typed gmial.com, or used a throwaway address to get a whitepaper, or entered [email protected] to see the pricing page. Your form accepted all of it, because most forms check for an @ and a dot and then stop.

List cleaning is repair work, and it is worth doing. Preventing the address from entering in the first place is strictly cheaper, because you never pay to store it, never risk your reputation mailing it, and never pay to verify it later.

This post is the prevention side. Four things at the form, in the order of how much they return.

011. Catch the typos, and offer a correction

The largest single category of bad addresses is not fraud. It is fingers.

The common misspellings are a short and stable list. gmial.com, gmai.com, gmali.com, gnail.com, hotmial.com, yahooo.com, outlok.com. Domain typos cluster because keyboard layouts cluster.

The important design decision is what you do when you spot one. There are two options and they perform very differently.

Rejecting outright is what most implementations do. The user sees "please enter a valid email address," which is unhelpful because as far as they can tell they did. They retype the same thing. Sometimes they leave.

Suggesting the correction converts far better. "Did you mean [email protected]?" with the corrected version as a single clickable option. The user recognises their own mistake instantly and fixes it in one tap. You keep the signup and you get a working address.

Never auto-correct silently. gmial.com is almost certainly a typo, but you do not know that, and quietly changing what someone typed produces a support ticket you will find hard to diagnose.

022. Block disposable domains, but decide what you are protecting

Disposable addresses come from services that hand out a mailbox lasting ten minutes. Someone uses one to collect a lead magnet without giving you a real address. The address may verify as deliverable at the moment they sign up and be gone by the time you send anything.

Blocking them at the form is straightforward in principle. The difficulty is that the domain list is long, it changes constantly, and the providers rotate domains specifically to defeat blocklists. A list of a few hundred domains catches the well-known services and misses most of the current ones. Practical blocklists run to six figures and need updating.

Before you implement this, decide what you actually want. A disposable address on a newsletter signup is worth blocking, because that person will never be a customer and you will pay to store them for years. A disposable address on a free-trial signup is a business decision rather than a data-quality one, and some products legitimately want to let people try without committing an address.

Our post on detecting disposable email addresses covers the detection side, and the free disposable checker will tell you about a specific domain with no signup.

033. Verify at the point of capture, not just in batches

The strongest prevention is checking the address while the person is still in front of you, because that is the only moment you can ask them to fix it.

There is a real trade-off here and it is about latency. A full verification involves DNS lookups and a conversation with the recipient's mail server, and that takes longer than a form submission should wait. Blocking a signup on a network round trip that might take several seconds is a good way to lose signups.

The pattern that works is tiered. Do the cheap checks synchronously and the expensive ones after.

Synchronously, before the form submits: syntax validity, the typo suggestion, the disposable check, and whether the domain has an MX record at all. These are fast. The MX check in particular is high value and low cost, because a domain with no mail server can never receive mail, and that verdict is certain.

Asynchronously, after the signup completes: the full mailbox-level scan. If it comes back undeliverable, you tag the record and suppress it before your first campaign rather than blocking the signup on it.

This gets you the confidence of a deep check without putting a network call in the critical path. Paid plans include API access if you want to wire this up, and the MCP server covers the same ground if you are working through an AI assistant.

044. Confirm the address is one the person wanted to give you

Every check above validates that an address is real. None of them validates that the person intended to give you that address, or that they wanted your mail.

Confirmed opt-in closes that gap. You send a single message with a confirmation link, and only addresses that click enter your list. It works because it requires access to the mailbox, which no amount of syntax validation can prove.

The cost is real: you will lose a portion of signups who never confirm. The gain is that the list you end up with is composed entirely of people who demonstrably received your mail and took an action. That population produces dramatically lower complaint rates, which is the metric that matters under the current bulk sender requirements, where the ceiling allows only 150 complaints per 50,000 messages.

Whether the trade is worth it depends on your list. It usually is for newsletters and marketing lists. It usually is not for transactional signups where the address is already proven by the transaction.

05What order to implement in

If you are doing one thing, do the typo suggestion. It is the cheapest to build, it catches the largest category, and it improves conversion rather than costing it, which makes it the only item on this list with no downside.

If you are doing two, add the MX check. A domain with no mail server is a certain failure and the check is a single DNS lookup.

Third is the disposable block, and only after you have decided what you want it to protect.

Confirmed opt-in is last, not because it is least valuable, but because it is the one with a genuine conversion cost and therefore the one that needs a real decision rather than a default.

06What prevention does not fix

You still need to clean, and prevention does not change that.

A perfect signup form gives you a list of addresses that were valid on the day they were captured. Then people change jobs, domains lapse, and mailboxes get abandoned. That decay happens in the world regardless of how good your form is. Our post on list decay rates has the arithmetic.

What prevention changes is the starting point. A list built through a form that catches typos, blocks disposables and confirms intent starts near zero bad addresses and accumulates them slowly. A list built through a form that checks for an @ starts dirty and gets dirtier. Both need periodic cleaning. One needs much less of it.

Fix the door, then clean the room. Doing it the other way round means cleaning the same room repeatedly.

Check a domain or address for free, no signup required.