'Thanks for contacting us' is not proof: four ways a website message disappears

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.

1. The careers mailbox turns customers into applicants

Four of my letters went to addresses of the form jobs@, careers@, bewerbung@, karriere@.

All four came back as job applications. Not one exception.

"Thanks so much for your interest in joining our team… unable to reply"

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.

2. Captcha markup is not captcha

I nearly discarded most of a channel over this one.

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.

3. 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.

4. Delivered is not delivered

Bounces come in two shapes and one of them is easy to miss entirely.

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:

newer_than:7d (from:mailer-daemon OR from:postmaster OR subject:undeliverable
  OR subject:undelivered OR "delivery has failed")

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.

The ten-minute check on your own site

Not from your office network, and not from the account that owns the site:

1. Open your contact page on a phone, on mobile data, in a private window.
2. Submit a real message using a Gmail address. Watch what the page says afterwards, word for word.
3. See where it lands — inbox, Promotions, spam — and how long it takes.
4. Follow every publicly visible address on your site and check what is on the other end: a mailbox someone opens, or an intake system.
5. Send one message to each of those addresses from outside your own domain and see which ones come back.

Every one of the four failures above is invisible from inside the company and every one of them
costs inbound. The first three cost you the message. The fourth costs you the message and tells the
sender it went.

---

If you run the ten-minute check and something in it surprises you, I would be glad to hear which
one — I am collecting failure modes and I doubt these four are the last of them.

I do outside audits of sites and storefronts, and the repairs that follow.
Portfolio: smirnov-artur.github.io/webgl ·
Telegram @smirnovarturr · [e-mail].