BOT DEFENSE FOR WEB3

Email Validation Has Three Jobs. Most Forms Only Do the First.

Syntax, domain, mailbox. A form that checks only the shape of an address collects perfectly formatted mailboxes that do not exist, and pays for the bounces later.

An email address can fail at three different levels, and each level needs a different check. Syntax is the cheap one: does the string look like an address, one at sign, a plausible local part, a domain with a dot. Domain is next: does the domain exist, does it publish MX records, can it receive mail at all, which kills the large class of typos where the local part is fine and the domain is a keyboard slip away from a real provider. Mailbox is the expensive one: does this specific mailbox exist on that domain, answered through verification services that query the mail server's behavior, with all the caveats catch all domains create. Forms that stop at syntax, which is most forms, because syntax is a regex and the other two are services, spend their savings downstream: bounce handling, polluted engagement metrics, welcome flows mailed to voids, and sender reputation damage that arrives as a deliverability problem weeks later, attributed to everything except the form that caused it.

Typos are the highest value catch

The domain check's best party trick is not fraud defense. It is the typo suggestion: the shopper who typed their real address at gmal dot com or hotmail dot cm wants their order confirmation, and a form that spots the near miss and offers the correction, did you mean gmail dot com, saves the customer, the support ticket, and the abandoned account in one move. Implement it as a suggestion, never a silent correction. Silently rewriting an address the form thinks is wrong will eventually rewrite a correct address at a small provider into a wrong one at a big provider, and that error mails someone's receipt to a stranger.

Track the suggestion acceptance rate. It is one of the few form metrics that reads cleanly: a healthy rate in the low single digits of signups says the check is catching real slips. Zero says the check is not running. A strangely high rate says your audience's most common provider changed, or your suggestion table is steering, and both are worth an hour.

Related reading on this site: Home and Form Abuse: Attacks That Pass Every Validation Check cover the neighbouring problems in more depth.

Mailbox verification and the catch all problem

Verification services probe the receiving server and report back in grades, deliverable, undeliverable, risky, unknown, and the grade that breaks naive integrations is the catch all domain, a server configured to accept mail for any local part, which makes every probe come back possible and no probe conclusive. Corporate domains run catch all for good reasons. The correct handling is to accept the address, mark the record unverified rather than verified, and let engagement be the judge: a catch all address that opens and clicks verifies itself over time. Rejecting catch all addresses at the form, which some integrations do when they treat anything short of deliverable as a failure, locks out exactly the business customers the form was built to welcome.

Role addresses and disposable domains are policy decisions wearing technical clothes. A role address, info at, sales at, is a real mailbox shared by a team; whether your product wants it depends on whether your accounts are personal or organizational. Disposable domains are clearer: they are a deliberate temporary identity, and consumer signups that accept them are choosing a trial the user designed to be abandonable. Decide both policies on purpose, write them in the spec, and stop letting the verification vendor's defaults decide them by accident.

Verify at the moment it costs least

Verification has a freshness problem. A mailbox verified at signup can be abandoned by the time the winback campaign mails it in month nine, so one check at the form does not discharge the list hygiene duty. The economical pattern is staged: syntax and domain at the form, because they are fast and free; mailbox verification at signup for high value flows and before major sends for the whole list, because bounces cluster in old records; and suppression rules that retire addresses after hard bounces without waiting for a human to review them. Spend the verification budget where the bounce would hurt: the big seasonal send, not the Tuesday newsletter to the engaged segment that verifies itself by opening.

Frequently asked questions

What are the three levels of email validation?

Syntax, whether the address is well formed; domain, whether the domain exists and accepts mail; and mailbox, whether the specific mailbox exists. Each level catches errors the others cannot, and mailbox checks are complicated by catch all domains.

What is a catch all domain and why does it matter?

A catch all domain accepts mail for any address at that domain, so verification probes cannot confirm an individual mailbox. Addresses at such domains should be accepted and marked unverified, then confirmed through engagement, rather than rejected.

Should a form auto correct email typos?

It should suggest the correction and let the user accept it, never rewrite silently. A silent correction will eventually change a valid address at a small provider into an invalid one at a large provider and send mail to the wrong person.

How often should a mailing list be verified?

At signup for high value flows, and again before major sends, because mailboxes are abandoned over time. Hard bounces should trigger immediate suppression regardless of when the address was last verified.