I audit websites from the outside and then write to whoever owns them, which means I spend a lot of time in other people's contact channels — forms, chat widgets, published addresses. Over one week that came to seventy-odd contact pages and around a hundred messages.
The thing I did not expect to learn: whether a message arrives is a completely separate question from whether the form works. Four failure modes, all measured, all of them holes that a site owner cannot see from the inside, because from the inside everything looks fine. The careers mailbox turns customers into applicants
Four of my letters went to addresses of the form jobs@, careers@, bewerbung@, karriere@.
Empfangsbestätigung Ihrer Bewerbung — confirmation of receipt of your application
The second one is the one to sit with. That message was about the company's broken product configurator on their own website. The reply was a receipt confirming my application for a job.
The mechanism is an applicant tracking system. careers@ is not a mailbox with a person behind it, it is an intake pipe: everything that lands there becomes a candidate record with a status field, and nobody in sales or engineering will ever open it. Two of the four were the same well-known hiring platform.
Why this hits site owners specifically: the careers address is the easiest address on the whole site to find. It is on the jobs page, in the footer, in the structured data, and it is indexed. It is frequently the only address a company publishes as plain text, because the sales route is a form. So an outsider with something useful to tell you — a customer, a supplier, a stranger who found a bug in your checkout — reaches for the address that is visible, and it is the one address in the company where their message provably will not be read.
Worth ten minutes of your time: Is there a non-careers address published in plain text anywhere on your site? If the only reachable string is careers@, that is your business channel now, whether you meant it or not. Does your ATS auto-reply to everything, including messages that are obviously not applications? Does anyone read the "unqualified" bucket in the ATS? That is where your bug report lives. Captcha markup is not captcha
Census of seventy contact pages: markers for hcaptcha or recaptcha present in the HTML of sixty-five. Visibly rendered captcha widgets: zero.
On some hosted platforms an invisible captcha is mixed into every form by default and switched on selectively — the markup is a platform default, not a decision anyone made about that shop. Filtering by "the page contains the string hcaptcha" would have thrown away ninety-three per cent of the channel, including every shop whose form happily accepted my message and replied with a confirmation.
What actually blocks a form is a rendered widget: a visible h-captcha / g-recaptcha container or an actual hCaptcha iframe on the page. That costs one request to check, against a string match that is worse than useless because it is confidently wrong.
Two related things, both measured: Cloudflare Turnstile in managed mode leaves cf-turnstile-response empty until submit. I watched a token field stay blank for sixty seconds and marked the form unreachable. It was not: the token is fetched at submission time. On another site I had written off as "Turnstile, no way through", the challenge solved itself in a normal browser tab — an 837-character token appeared a few seconds after load, the form went, and the page said "Thank you — Your form has been submitted successfully". Waiting for the token before clicking is pointless. Check the result, not the field. Invisible reCAPTCHA (data-size="invisible") and the Enterprise variant are not barriers by design — no human step exists in the mechanism. A visible v2 checkbox is a different matter.
For an owner this cuts both ways. If you added a captcha because of spam, verify it renders at all — you may be protected by a string in your HTML and nothing else. And if it does render, know what it costs: a visible challenge on a B2B contact form is a toll charged to every genuine inquiry, in exchange for stopping bots that mostly are not stopped by it. Your success indicator is probably lying
I need to know whether a message went, so I have become uncomfortably well informed about how forms signal success. Three real cases: Fields cleared, URL changed, no message sent that I could prove. The submit went through, the connection dropped on the same action, everything looked like a successful navigation. I logged it as unconfirmed and did not resend, because a duplicate is worse than a miss. Fields stayed filled, no error, no success. Two attempts, checkValidity() true, form intact. The click had been dispatched to a background renderer — the button was "pressed" in a tab that was not in front. No error anywhere. Four forms redirected to ?contact_posted=true and showed "Your e-mail has been sent." I checked, and without that URL parameter the confirmation string does not exist on the page at all. The confirmation is a consequence of the parameter, not evidence of delivery on its own.
The only thing I now accept as proof is confirmation text rendered on the page after submission. Cleared fields lie. A URL change lies. A missing error message proves nothing whatsoever: the absence of a failure signal is not the presence of a success.
For owners: go and submit your own contact form and watch what the page tells you. If the answer is "it scrolls to the top and the fields are empty", a meaningful share of your visitors will conclude it failed. They will submit again, or they will leave and not come back. Say the word "sent", in a sentence, where the fields used to be. Delivered is not delivered
The ordinary one is mailer-daemon. The other arrives from postmaster@ on the recipient's own domain, and it means the published address forwards to somebody's personal mailbox and the forwarding broke. A search for mailer-daemon alone does not see it. This one does:
Three more findings from the same pile: 554 5.7.1 Relay access denied from an address published on the company's own contact page. That mailbox does not accept external mail at all. Nobody there knows. Business auto-replies land in Promotions. A manufacturer's "Your request to us" receipt, with a printout of the fields I had filled in, was sitting in the Promotions tab and never in the inbox. I had recorded that delivery as unproven for a day. If your own order confirmations or inquiry receipts go out with marketing headers, this is happening to your customers too — and they will not go looking. Some hosted form products reject free mail domains. @gmail.com was rejected outright by two different vendors' contact forms. As an anti-spam measure it is understandable. As a filter on your inbound it is brutal: a large share of small-business owners, sole traders and individual customers have no other address.