Contact form says sent, but no email arrives: three ways it fails silently

A contact form can show a success message while the enquiry goes nowhere. After we moved a group of client sites to a different host on 28 August, we found three forms failing in three different ways. One sent every enquiry to us instead of the client, one showed visitors an error, and one told visitors they had signed up while quietly failing to send anything. The only reliable test is to submit a real enquiry and check where it arrives.

Why the move broke things

The sites had been running on one host and were moved quickly to another after the original hosting arrangement failed (the full story is in our post on what happens when a host fails). The code was the same on both. What did not travel with it was the settings: the email service's key, the address the site sends from, and the address enquiries go to. Those live in the hosting account, not in the code, so a move leaves them behind unless somebody copies them across and checks.

We audited all of them on 1 September. Here is what the audit found.

Failure 1: enquiries sent to the wrong person

On a builder's site, the setting for where enquiries are delivered still held a value from the testing phase: an address of ours. The form worked perfectly. Every enquiry that came in from 28 August arrived in our inbox, and the client saw none. The visitor saw a normal success message, we had a working form, and the business owner was left wondering why nobody was calling.

Nothing in the code was wrong, which is why it took an audit of the hosting settings to find it. Once found, it is a settings change, not a code change.

Failure 2: a form that broke loudly

On an appliance repair site the hosting account had no custom settings at all, so the site tried to send email with a missing key. The form was completely broken from 28 August, and a visitor who tried it would see an error. That is the best of the three failures, because it was at least visible. It lasted from 28 August until the audit on 1 September.

Failure 3: a success message that was not true

A swimwear label's site was the worst of the three. It is a pre-launch list sign-up, and it replied "You're on the list" to every visitor. In the background, each confirmation email failed.

The site had been built to run on Cloudflare's platform, and on the new host a small compatibility layer stood in for it. That layer passed along the database but not the plain settings values, so the "from" address the form built was hello@undefined. The email service rejected it. The site's code caught the rejection, wrote it to a log, and carried on, because the design was that a signup should never fail for the visitor. Sign-ups between 28 August and 1 September went nowhere, and no error appeared anywhere except in the logs.

We fixed the settings, fixed the compatibility layer so that it reads the host's settings properly, and tested the form.

There was also a fourth risk behind these. All the forms on these sites send from one shared sending domain. That domain's own DNS went offline from 30 August to 1 September while the domain was on hold over a renewal, which meant the authentication records for our sending were unreadable and any email in that window risked being rejected or marked as spam. We cannot tell from the tools we have whether any were.

What a form should do when sending fails

A form that cannot send should say so to the visitor, at the moment it fails, and give them another way to reach you, such as a phone number. It should also tell somebody on your side, by a second route, so that a failure is noticed in minutes rather than when the quiet week turns into a quiet month. That site did the opposite. It had been built so that a failed email could never get in the way of a signup, which is a reasonable goal for the visitor and a poor one for the business when nothing records the failure anywhere a person will read.

How to test your own form

1. Use your phone on mobile data, not your office network.
2. Fill the form in as a real customer would, with a name and an email you can read, and submit it.
3. Check the inbox you expect leads at. Then check spam, then check any other address that might be receiving them.
4. Do the same after any change to hosting, email provider, domain or site rebuild.
5. If you build or manage a site, look at the logs from the moment you submit. A success message proves the page responded. It does not prove an email left.

Do this once a quarter on a site that does not change. The cost is two minutes.

If your enquiries are landing in spam rather than going missing, that is a different problem with a different fix, covered in why contact form emails land in spam.

What it says about how a site is looked after

Nothing in these three failures was visible from the outside, and none of them showed up in a build or a page check. They surfaced because someone looked at each site's settings and then tested a real submission. That is the work we do after a site is live, and it is why we think the ongoing arrangement is the honest way to run a site: it is what keeps enquiries arriving after launch, and what you are paying for. On our base plan the monthly report and upkeep are part of the fee. If you would like us to test your form, our free website audit is the place to start.