Three weeks ago I had a simple question: if the contact form on a
small business website breaks tonight, how long until anyone notices?
The honest...
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
No spam. Unsubscribe anytime.
That off-by-one at the protocol layer is brutal — a check silently reporting healthy for a week is exactly the failure class this tool exists to catch.
On closing the loop: shipped a version today. One synthetic test per run with a unique token embedded in the submission, and the site owner confirms receipt with one click in the dashboard (we record the timestamp). I went with the human click instead of a per-submission alias into a mailbox I control — reading their inbox means OAuth/IMAP per customer, and the click reaches the same proof without me touching their mail. Your alias design is the cleaner automation; the click is the cheaper thing to trust.
the human click is the right call — it separates 'smtp accepted' from 'a person actually got it'. mine keys the token to the run id and burns it on first confirm, so a stale dashboard tab can't mark a dead run healthy.
Same goal, different mechanics — each daily run writes its own check row with its own token, and the confirm button only exists on the latest row. So a stale tab can only confirm a run that actually happened; it can't touch today's dead one. Your keyed-and-burned version is tighter against replays, though.
And you just earned your finder's fee: chasing your stale-tab scenario I found the actual hole — a failed submission was still minting a confirm token, so a dead run was confirmable as healthy. Fixed today: only accepted submissions mint one, and the confirm card only renders on passing rows.
the token lands in the row at insert and gets nulled inside the same update that stamps the confirmation, so the second click finds nothing to match against. a tab that outlives its row has nothing left to aim at.
Same-transaction burn, no window in between — that's the clean way to do it. This thread was better than most code reviews I've had. Week 2 log will have the first real confirmations from running the loop on my own site.
The Gmail relay thing doesn't surprise me at all. The failure I'd worry about most is the one where the form says "thanks" to the visitor but the email quietly lands in the agency's spam folder, because nothing on the site side looks broken. Does your test lead check the inbox it actually lands in, or only that the form submit returned success?
Exactly the right question, and the honest answer: today the paid check confirms the form accepts the submission (HTTP success) — it does not confirm the email lands in the inbox. The "thanks page but spam folder" case is the scariest failure mode, and the current design can't see it.
The TXT record only proves ownership so I submit to opted-in sites — it doesn't close the inbox loop.
Closing that loop is the next build: a unique token in each test lead, plus a confirmation signal back (a one-time forward, or a forwarding rule the user sets once). I'd rather admit the gap in a comment than ship a claim the engine can't back.
checking the inbox is the right instinct, and the layer below it is worse: i
wrote an address probe that opened an SMTP session and issued RCPT, and it
returned 250 for every address including ones that don't exist - taking the
socket over meant the 220 greeting was never read, so every reply arrived one
command late and RCPT consumed the answer to MAIL FROM. a check that never reads
the first line of the conversation reports success forever, and it looks like a
healthy week.