The user types their address, hits submit, and walks away. They meant zhang@gmail.com. What they submitted was zhang@gmail.co. The form accepts it, because gmail.co is a syntactically valid domain. The confirmation email sails off to an address no one owns. The user never arrives, never complains, and you never learn why.
This is the quiet leak in most signup flows. It is not a bounce you can measure later. It is a silence you never see.
What a typo correction actually does
The useful case is narrow. The local part, the bit before the @, is almost always typed correctly. The damage is in the domain. People write gmail.co instead of gmail.com, gmial.com instead of gmail.com, hotmial.com instead of hotmail.com. The fix is to compare the typed domain against a list of known-good domains and offer the closest match.
The comparison is edit distance. You count the insertions, deletions, and substitutions needed to turn the typed domain into a candidate. One edit, co to com, is a strong signal. The verifier then returns a suggestion instead of a rejection, and the UI asks "did you mean gmail.com?"
curl "https://mailprobe.kevin-c0319.workers.dev/v1/verify?email=zhang@gmail.co"
{
"email": "zhang@gmail.co",
"valid": false,
"deliverable": null,
"reason": "typo_suspect",
"score": 0,
"suggestion": "zhang@gmail.com",
"checks": {
"syntax": true,
"mx": { "ok": false, "records": [], "error": "no_mx", "source": null }
}
}
The domain gmail.co has no MX records, which is the tell that trips the check. The API returns suggestion with the corrected address and reason set to typo_suspect. Note deliverable is null rather than false: the verifier is not certain the typed address is dead, it is certain a better candidate exists.
A small client handler turns that into a prompt:
async function checkEmail(email) {
const res = await fetch(
"https://mailprobe.kevin-c0319.workers.dev/v1/verify?email=" +
encodeURIComponent(email)
);
const data = await res.json();
if (data.suggestion) {
showHint(`Did you mean ${data.suggestion}?`);
return data.suggestion;
}
return email;
}
The leak leaves no trace in your dashboards
A hard bounce shows up in your email logs. A mistyped domain shows up as nothing: no signup event worth keeping, no bounce, no complaint. The only signal is a slow, unexplained gap between form submissions and confirmed accounts. If that gap is larger than your open-rate math predicts, a share of it is almost certainly typo loss, and the fix is a one-line hint at the form boundary rather than a rework of the whole funnel.
The mistake teams make is hunting for the leak in the wrong place. They audit their sending reputation and their subject lines, because those are where the metrics live. The typo loss is upstream of all of that, in the half second a user spent typing an address they will never check. You cannot A/B test your way out of an address no one owns.
Why the suggestion must not be automatic
The risk is over-correction. Edit distance has no sense of meaning. If you are too eager, you start "fixing" addresses that were right.
Imagine a user at a small company gmail.com.au who fat-fingers gmail.con.au. One edit away sits gmail.com.au, a real domain they may not own. Or a user on a regional provider whose domain is genuinely one letter off from Gmail. Correcting silently would ship their mail to a stranger. That is worse than the original typo, because it looks like success.
The safe rule is to suggest, never to substitute. Show the hint, pre-fill the corrected value in a confirm step, but require the user to accept it. When the edit distance is more than one, or the candidate domain is not in your known set, stay quiet. A correction offered for a two-letter mistake is a correction that will often be wrong, and a wrong correction erodes trust faster than a missed one.
There is also a cost side. Running edit distance against a domain list is cheap, but it should sit behind the cheaper checks. If the syntax is invalid or the domain is on the disposable list, there is no point computing suggestions. Spend the comparison only on addresses that are well formed and have a plausibly real, if wrong, domain.
Testing the hint is cheap
Show the suggestion to half of your signups and compare confirmation rates to the control group. The lift, when the address was genuinely mistyped, is immediate, and the downside in the control group is zero. If the lift is small, your users are not mistyping domains often, and you have spent an afternoon confirming it. If it is large, you have found a leak you did not know you had, and the repair is a few lines of client code.
The one thing to watch while testing is the false-correct rate. If the treatment group starts showing confirmation rates below the control, your suggestion is firing on addresses that were right, and you are sending users to confirm mail that was already correct. Pull the threshold back to a single edit and a known domain, and the false-correct rate drops to near nothing.
The payoff
The win is not correctness for its own sake. It is the users you keep. A mistyped domain is a user who wanted in and got nothing. One hint at the form boundary recovers them with zero friction, and it costs you one DNS lookup you were going to make anyway.
Pair the suggestion with a confirmation email and the loop closes. The hint catches the obvious typo on the spot. The confirmation email catches the rest, including the catch-all and unknown cases. Between them they remove the silent leak without ever silently rewriting a user's address.
I used MailProbe for the request and response shapes here. Its hosted endpoint returns the suggestion field and the typo_suspect reason, and it is at https://mailprobe.kevin-c0319.workers.dev/. The suggestion is a hint, not an edit, which is the part that matters in production.
Top comments (0)