The form submitted. That is not the same as delivering.

This is the single most common defect we find on sites built by somebody else, and it is worth being precise about why it survives so long: there is no symptom. The form works. You can fill it in yourself, press send, and watch a thank-you page appear. Everything you can observe from your own side is exactly what a working form looks like.

The thank-you page is drawn by your website. It means the server accepted the submission and returned a response. Somewhere after that, a separate system is meant to turn that submission into a message and hand it to a mail server, and there are four places it stops. None of them changes what you see.

The four places it dies¶

In rough order of how often we find them, and they are not mutually exclusive. Two of these together is common, because the first one hides the second.

One: it sends as you, from somewhere you never authorized¶

A form is typically configured to send from an address at your own domain, because that is what looks right in an inbox. The server actually sending it belongs to your web host, and your domain has probably never said that host is allowed to send on its behalf. RFC 7208 (opens in a new tab) is how a receiver checks that, and a message failing it is discarded or filed as spam by the receiving system. The send succeeded. The delivery did not, and the sender is not told.

The same mechanism catches the fix people try first. Adding your web host to the list of authorized senders is correct, and it is also the eleventh thing on a list that permits ten (opens in a new tab), in which case nothing improves and the whole record is now failing instead. The mail half of this problem is its own argument, and it is the next thing to read if the description fits.

Two: the destination mailbox no longer exists¶

The address in the form's configuration was a real person in 2021. They left, the mailbox was deleted or converted, and the alias that replaced it was never put into the code because nobody knew the code contained an address. This one is quietly the worst of the four, because the submissions are genuinely being sent and genuinely being rejected, and the bounce is returning to an address that is also nobody.

Three: there is no error path at all¶

A form handler either checks whether the send succeeded or it does not. A great deal of the code we inherit calls a mail function, ignores what it returns, and renders the thank-you page unconditionally. That is not an obscure bug; it is the absence of a branch. Nothing on the page can distinguish a message that was delivered from one that was refused, because the page was never given the information.

Four: it arrives, and arrives somewhere nobody looks¶

The mail is delivered to a shared mailbox that three people can see and none of them owns, or to a folder a rule moved it to, or to a spam folder that a receiver decided on for the reasons in failure one. The messages exist. Nobody has read them since March. This is the version that feels least like an outage and costs the most, because a form that works badly for eight months has collected real inquiries and lost every one of them.

Why store it as well as send it¶

Email is a delivery mechanism and it is not a record. A form that only composes a message and hands it away has made the arrival of that message the single point at which the inquiry can be lost, and every one of the four failures named here happens after that handover.

The version that survives all four is a form that writes the submission down first and then attempts delivery, treating the send as a notification rather than as the inquiry itself. The record exists whether or not the mail arrives; the three silent outcomes become rows somebody can read; and the question of who has written to us stops being answered by searching an inbox. We did this to our own contact form for exactly these reasons, and the ordering is the whole point: store, then send.

What to check, and when¶

1. 1.Submit the form yourself and confirm the message in the destination mailbox, not on the thank-you page. Check the spam folder before concluding anything.
2. 2.Find out what address the form sends from and which server actually sends it, then check whether your domain authorizes that server. These two facts are usually held by two different suppliers who have never spoken.
3. 3.Name the mailbox that receives it and name the person who owns that mailbox. An address with no owner is the failure that takes longest to notice.
4. 4.Ask whether a failed send is recorded anywhere. If the answer is that failures cannot happen, the answer is that failures are not detected.
5. 5.Repeat this on a schedule. Nothing about this defect announces itself, so the only thing standing between you and eight silent months is somebody testing it deliberately.

Forms are the cheapest part of a website to build and the most expensive part to have wrong, because the loss is invisible and compounds. A site that ranks well, loads fast and converts a visitor into a submission has done all of the difficult work; losing it at the last handover is an unforced error and it is entirely testable.