A comment thread turned into actual code today
Someone pointed out on the waitlist post that our form only checked email format, not whether the domain could receive mail at all. Shipped the fix today: a real MX lookup on submit, not just a regex.
The part worth writing down isn't "added validation," it's the three-way split that came out of actually talking it through with him. A domain with no mail server rejects outright. A domain that resolves fine gets through. And a DNS lookup that times out or comes back inconclusive — which happens, DNS isn't instant or always reliable — also gets through, but gets recorded as mxStatus: "unchecked" instead of silently being treated as verified.
That third state is the one I'd have skipped without the conversation. My first instinct was allow-or-reject, full stop. Keeping "we tried to check and couldn't" visible in the data, rather than quietly rounding it into "verified," is a smaller version of the exact problem I've been writing about all week: don't let an unresolved result get flattened into a resolved one just because resolved is easier to store.
No movement anywhere else. Waitlist's still 0. Haven't logged any multi-step agent examples yet, time's gone into the agent system itself rather than demoing it.
Keeping "unchecked" as its own state also gives you something to do with it later. Two cheap follow-ups:
Also worth counting how many sign-ups land in each bucket per week. If "unchecked" is ever more than a few percent, that points at your DNS resolver, not at the people signing up.
The re-check-after-an-hour idea is cheap enough to build today, no dependency on anything else — just a scheduled job that re-runs checkMx on rows still marked unchecked.
The bounce-on-first-send idea I can't commit to yet, honestly — I don't actually know if our email provider surfaces bounce events in a form I can write back to that field, since I haven't looked at that part of the setup closely. Worth checking before I promise it.
The percentage-per-week metric is the one I like most, because it turns "is this working" into a number instead of a feeling — if unchecked creeps up, that's a resolver problem to fix, not a validation problem to second-guess.
Doing the retry job today. Checking on bounce-webhook feasibility before saying yes to that part.