The silent contact form: the failure nobody sees

A client contacts me about rebuilding his website. Twelve months live, not a single enquiry through the contact form. His conclusion: the site doesn’t convert.

The actual conclusion, after an hour of checking: the form worked perfectly. It was the email that never went out. Twelve months of potential enquiries lost, with no signal to alert him.

This isn’t an isolated case. It’s the most frequent and least detected problem I come across.

Why the failure is invisible

A web form performs two distinct operations. It collects the data, then it triggers an email. The confirmation shown to the visitor — “Thank you, your message has been sent” — rewards the first operation. It says nothing about the second.

In practice: the server hands the message to its outbound queue, the queue replies “accepted”, the visitor sees the confirmation. What happens to the message afterwards falls entirely outside that chain. It can be rejected by the receiving server, filed as spam, or silently discarded.

Nobody knows. The visitor believes they wrote. The owner believes no one enquired. Both are wrong.

The three causes I encounter

Sending through the server’s built-in function. Most shared hosting sends email through PHP’s built-in mail function. Those messages leave without authentication, from an IP address shared with hundreds of other sites. Major mail providers reject them or file them as spam almost systematically.

No domain authentication. SPF declares which servers may send on your domain’s behalf. DKIM cryptographically signs each message. DMARC states what to do when either one fails. Without those three records correctly configured, a message claiming to come from your domain but leaving from a shared server is treated as spoofing. Technically, that’s exactly what it is.

An inconsistent sender address. The form sends from the address the visitor typed, so the recipient can reply directly. The result: a message claiming to come from a consumer mailbox, but dispatched from your host. No authenticity check can pass.

How to verify in ten minutes

Don’t assume it works. Test it.

Send yourself a message through your own form, from an address outside your domain. Then check three places: the inbox, the spam folder, and — if your provider has one — the quarantine.

If the message arrives, open its full header. Most mail clients let you view the source. Look for lines starting with spf=, dkim= and dmarc=. Three pass results: the configuration is sound. A single fail or none: you have your explanation.

Repeat towards an address at a different provider. A message can pass with one and be blocked by another. Testing a single destination proves nothing.

What fixes it

The principle is simple: stop sending from the web server.

A transactional email service takes over. The form hands it the message, and that service — whose entire business this is — dispatches it from authenticated infrastructure with a monitored sender reputation. You also get a delivery log: you know whether the message left, whether it was received, whether it bounced.

Add two rules:

• The sender must be your domain, never the visitor’s address. That one goes in the reply-to field, not the from field.
• The form must write somewhere other than email. An entry in your CRM, a row in a table, a ticket. Email becomes a notification, not the sole record of the enquiry. If delivery fails, the enquiry still exists.

What to take away

Before concluding that a site doesn’t convert, verify that it transmits. A silent form isn’t a content, design or SEO problem — it’s a technical failure, and it can be fixed in a morning.

What it cost in the meantime, however, cannot be recovered.