When Validation Blocks Real People

In short. Validators refuse real addresses constantly, and the refusals do not appear in any report you are reading. Five specific patterns cause most of it, and all five are fixable without letting abuse through.

The failure that leaves no trace

A false positive in email validation is an address that belongs to a real person at a real mailbox, refused because a check decided it was disposable or invalid.

The person sees "please enter a valid email address" under a field containing their perfectly valid email address. They try once more, conclude the site is broken, and leave. No error is logged, because nothing errored. No conversion is lost, because none was ever recorded. No ticket is filed, because writing to support requires caring more than the situation deserves.

This is why the problem persists in companies with good analytics. The data simply is not there unless someone instruments the validator itself, and almost nobody does.

The five sources

Catch-all corporate domains. A company accepts mail for every address on its domain. To an SMTP probe this is identical to a throwaway service: both answer yes to any mailbox you ask about. Small businesses run this way constantly.

Young domains. A company registered its domain six weeks ago. Age based heuristics treat it as suspicious for months, which means the newest and most eager customers get the worst experience.

Subaddressing with a plus. The name+shop@ convention is supported by most major providers and used by exactly the sort of organised person you want as a customer. A surprising number of validators reject it outright, and a few strip the tag silently, which is worse because it breaks the filing the user set up.

Institutional aliases. University and organisation addresses that forward elsewhere look like relays to a heuristic hunting relays.

Unlucky words. A domain containing mail, box, post or drop gets pattern matched by validators that use name shape as a signal.

Why catch-all is genuinely indistinguishable

This one deserves more than a line, because it is the source teams argue about.

The only mechanical way to ask whether a mailbox exists is to open an SMTP conversation and ask the receiving server. A catch-all domain answers yes to every question, by design, because its owner wants mail to sales@, info@ and every typo of both. A throwaway service answers yes to every question for the same technical reason. Individuals run them too, since one invented address per service on a domain you pay for is about the tidiest arrangement there is, and over SMTP it looks like neither a company nor a person.

There is no follow-up question that separates them. The difference is intent, which is not observable over SMTP. Any validator claiming to distinguish them reliably is guessing from other signals, and guesses have error rates.

What the loss looks like from the outside

Nothing at all. That is the whole problem.

Your signup funnel shows people reaching the form and not completing it, at a rate you have long since accepted as normal. Some of that rate is people changing their mind. Some of it is your validator telling honest customers that they do not exist. Without instrumenting the validator you cannot tell those apart, and the second group is not small.

How to actually measure it

Three numbers, in order of how much work they take.

Refusal rate. Log every time validation refuses an address, as a share of form submissions. If this is above a couple of percent, something is wrong, because genuine throwaway usage on an ordinary consumer site is rarely that high.

Refusals by domain. Group the refusals. Real throwaway services cluster into a handful of well known names. If your list is a long tail of domains you have never heard of, most of those are companies.

Refused versus confirmed. For a week, let refusals through but require confirmation by link. The share that confirms is your false positive rate, measured rather than estimated. This costs one week and settles arguments that otherwise run for years.

What to fix first

Stop validating on the client. A blocklist shipped to the browser is public, trivially bypassed by anyone who cares, and applied to everyone who does not. The only people it stops are honest.

Separate "disposable" from "invalid". They are different findings requiring different responses. Malformed is a typo, tell the user. Disposable is a policy decision, and treating a policy decision as a spelling mistake is what produces the maddening experience described above.

Say what happened, and offer a way through. "We cannot accept temporary email addresses here" is honest and lets the customer choose another address. "Please enter a valid email address" is a lie that makes them think your form is broken.

Never block silently. Accepting the address and then quietly discarding the account is the worst outcome for everyone, and it is more common than you would believe.

The compromise that works

Let everyone in, and gate the value rather than the door.

Accept any address that is syntactically valid and has working mail servers. Send a confirmation link. Withhold whatever an abuser would want, the trial credit, the referral bonus, the ability to post publicly, until the address is confirmed and some time has passed.

This defeats throwaway addresses on its own, because a mailbox that expires in a day cannot confirm anything on the third day. It costs legitimate users one click. And it removes the need to guess about domains entirely, which is the part that was never going to work reliably.

If you are still deciding whether to block at all, the full argument on both sides is worth reading before you tune anything.