How this is usually discovered
A client mentions, in passing, that they filled in the form on your website a few weeks ago and never heard back. You check. There is nothing. You fill it in yourself. The page says "Thank you, your message has been sent." Nothing arrives.
Then the uncomfortable arithmetic: how long has it been like this, and how many people wrote to you in that time? On the inherited sites we diagnose, a dead contact form is the single most common finding, and the typical duration before anyone notices is months.
It is worse than a form that shows an error. A form that fails silently tells the visitor their message went through, so they wait for a reply that never comes, and conclude you ignored them.
The two-minute test
Do this now, on your phone, not on your own Wi-Fi.
- Open your website's contact page and submit the form with a real message.
- Check the inbox it should arrive in. Check the spam folder too.
- If your site has a booking form, do the same.
Nothing within five minutes, in either folder, and you have a dead form. Something in spam, and you have a deliverability problem, which is a different fix and a smaller one.
Put a reminder in your calendar to repeat this monthly. It is the cheapest monitoring there is.
Why forms stop sending
Forms almost never break on the day they are built. They break later, when something around them changes.
The site sends its own email and the host stopped allowing it. Many WordPress forms send email directly from the web server. Hosts increasingly block this, or mail providers refuse it, because unauthenticated mail from a web server looks like spam. The form plugin reports success because handing the email to the server succeeded; the server then quietly dropped it.
A plugin update changed something. The form plugin updated, or the email plugin did, or the two stopped agreeing. Settings reset. A required field was renamed. The recipient address reverted to the developer's.
The recipient address is wrong. The form still sends to the email address of whoever set it up: a former staff member, the previous owner, the developer. The mail is arriving, just not to you.
The spam protection went too far. A CAPTCHA or spam filter was tightened and now silently discards real submissions along with the bots. No error, no email.
The email service's credentials expired. If the site sends through a proper email service, the API key or password can be rotated or the account can lapse. The form does not know; it just fails.
DNS records were changed. A new email provider, a new website, a well-meaning DNS edit, and the authentication records that let your domain send mail are gone. Messages go to spam or are rejected.
Fixing it properly
The immediate fix is usually one of the above, and a developer with access can find it in under an hour. The proper fix is to remove the two conditions that let it fail silently in the first place.
Send through a transactional email service, not the web server. Route form mail through Postmark, Resend, Brevo, Amazon SES or your host's SMTP relay. These services log every send, report failures, and deliver reliably when your domain is authenticated. On WordPress this is one plugin and an API key. On a modern site it is a few lines in the form handler.
Store every submission somewhere other than email. Every serious form tool can keep a copy of submissions in the site's database or in a spreadsheet. Then a lost email is an inconvenience rather than a lost enquiry. When we build forms, submissions are written to a store before the email is even attempted, so an outage at the email service cannot lose a lead.
Make failure visible. A form that cannot send should say so to the visitor, with your email address as a fallback, and should alert you. The success message should mean the message actually went somewhere. A form that says "sent" when it did not is lying to your customer on your behalf.
Authenticate your domain. SPF, DKIM and DMARC records let your domain send email that reaches inboxes. If confirmation or form emails are landing in spam, this is the reason.
What to check on an inherited site
If you have taken over a site someone else built, three questions cover most of it:
- Where does the form send, and is that address still yours?
- How does the site send email: directly from the server, or through a service?
- Where else are submissions stored, if anywhere?
If the answers are "not sure", "directly" and "nowhere", the form is a liability waiting for a plugin update.
Where this sits in a diagnosis
Testing every form and tracing where its mail goes is one of the first items on our website diagnosis, because it is the fault most likely to be costing you customers right now, and because it is nearly always fixable the same day. If the form on your site has never been tested from a phone, do that before you read anything else here.