When Validation Blocks Real People

In short. Validators refuse real addresses constantly, and the refusals do not appear in any report you are reading. Six specific patterns cause most of it, and all six 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 six 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.

The shape of the name itself. Hyphens, underscores, more than one dot, a local part longer than a form's arbitrary limit. All are legal, all are common, and all are refused by hand written checks that allow letters, digits and one dot because that is what the person writing the check happened to use.

The address shapes people actually have

That last source is worth measuring against something concrete, so here is our own rule, which is deliberately stricter than the mail standard because we are the ones handing out the names.

A name on this service is lower case, between three and thirty two characters, built from letters, digits, dots, hyphens and underscores, and it has to begin and end with a letter or a digit. That is a narrow subset of what mail actually permits, and it excludes plenty of legal addresses on purpose.

Now notice how many form validators refuse even that. Anything with an underscore fails a check written around firstname.lastname. Anything over twenty characters fails a field with a length cap somebody guessed at. A name with two dots fails a regular expression copied from an answer written in 2009. None of those addresses is disposable, none is invalid, and every refusal is attributed to the user having typed something wrong.

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.

The probe is worse than it looks

The SMTP check is sold as the rigorous layer, the one that goes and asks rather than guessing. It is worth understanding why it degrades exactly where you need it most.

Opening a connection to a stranger's mail server and asking whether a particular mailbox exists, without sending anything, is mechanically identical to what an address harvester does. Receiving servers know this. Large providers rate limit it, delay it deliberately, or answer affirmatively to every name asked in order to give harvesters nothing usable.

The result is an inversion. Against a small badly run domain the probe returns a clear answer that you did not need. Against the enormous consumer providers where most of your customers actually are, it returns either an unknown or an undifferentiated yes. Validators then score that ambiguity, and ambiguity scored as risk is a false positive with extra steps.

There is also a cost to the person being probed. Enough probing from one address range and your own sending infrastructure starts appearing in the reputation systems you were trying to protect.

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 log, field by field

Vague instructions to "add logging" produce nothing usable, so here is the record that answers the question in one query.

The moment it happened. The domain, kept in full, because the domain is what you will group by. The local part, not kept, because you do not need it and keeping it turns a diagnostic log into a store of personal data. Which check fired, named individually rather than as a single failure flag, so you can tell a list hit from a probe timeout from a pattern match. The verdict returned to the user. The session identifier, so the next two questions are answerable at all.

Then two derived signals, which are where the value is.

Did they submit again within a minute? A second, different address within sixty seconds of a refusal is the clearest evidence you will ever get that a real person was blocked and worked around you. Anyone abusing your form does not hesitate; anyone typo-ing does not change domain. Count these and you have your false positive floor without running an experiment.

Did the session ever complete? The share of refused sessions that end in nothing is the number to put in front of whoever owns the setting. It converts an argument about principle into a line about lost signups.

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.

Widen the syntax check before touching anything else. It is the cheapest fix on this page, it carries no abuse risk at all, and on most forms it removes more false positives than every other change combined.

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, and how detection works layer by layer explains which of your checks is producing which refusal.