Blog · 7 November 2026 · 7 min read
Contact form not working? How to check it in 10 minutes
It is the most common silent failure on a business website. The page loads, the padlock is green, the form says “Thank you, your message has been sent” – and the enquiries have been going nowhere for weeks. Nobody complains, because the customer assumes you are the one not replying, and moves on to a competitor. Below: eight reasons this happens, a test you can run yourself in 10 minutes, and a table that tells you who to ask for the fix.
Why forms break quietly
A form is a chain: the customer’s browser → a script on the page → your server → outgoing e-mail → the recipient’s mail server → a folder in your inbox. Every link can break on its own, and the “sent” message usually confirms only the first two.
- Messages land in spam or are rejected. Many plugins send the e-mail “from the customer”, with the customer’s address in the From field. To a mail server that is impersonating someone else’s domain: Gmail and Outlook increasingly reject such messages or file them as spam. Add a missing SPF or DKIM record for your domain – Google requires at least one of them from every sender writing to Gmail (since February 2024), because without it the recipient has no way to check that the e-mail really came from your server.
- The server stopped sending mail. After a hosting move, a PHP upgrade or a tightened provider policy, the mail function is sometimes switched off. The plugin gets no error, so it keeps saying “sent”.
- An SMTP password or API key expired. If the form sends through an external service (Gmail, Brevo, SendGrid, Mailgun), a password change, an expired key or newly enabled two-factor authentication cuts delivery overnight.
- The recipient changed. An employee left, the mailbox was deleted or is full, and the form settings still point at their address. The server sends, nobody reads.
- Spam protection rejects humans. reCAPTCHA with too high a threshold, a honeypot that the browser’s autofill fills in, or a word filter that blocks “http” in the message – the customer sees a vague error, or no error at all.
- The form does not work on a phone. A required field hidden under the keyboard, a button off-screen, a dropdown that will not open by touch. Most enquiries to local businesses come from phones, so a “mobile-only” bug is a bug for the majority.
- A script broke after an update. A new version of the plugin, theme or cookie-consent tool can block the form’s script. The “Send” button spins forever or does nothing. There is a red error in the browser console that nobody sees.
- The thank-you page is gone. The form redirects to “/thank-you”, which someone deleted during a clean-up. The customer sees a 404, sends again or gives up; your analytics stops counting enquiries at the same time.
The 10-minute test, step by step
- Send a test enquiry the way a customer would. From a phone, on mobile data (not the office Wi-Fi), from a personal address outside your company domain, e.g. Gmail. Put something easy to find in the message: “FORM TEST, 7 November, 14:05”. Note the time and what the page showed after you pressed “Send”.
- Check every place it could have gone. Inbox, Spam/Junk, Promotions/Updates (Gmail splits mail into tabs), and if the plugin stores entries on the site, its entries list too. Give it 5 minutes; an e-mail that has not arrived in 5 minutes usually never will.
- Look at the headers if it arrived. In Gmail: three dots → “Show original”. Look for the SPF, DKIM and DMARC lines – they should say
PASS. AFAILorSOFTFAILmeans the message got through this time but is borderline; the next one may not. Check the From field too: it should be an address on your domain, with the customer’s address in Reply-To. - Submit an empty form on purpose. Press “Send” without filling anything in. A good form highlights the empty fields and says what to fix. A bad one does nothing, or shows “an error occurred”. While you are there, fill fields in wrongly (an e-mail without @, letters in the phone number) and check the messages make sense.
- Open the console. On a computer, open the page with the form, press F12, choose the “Console” tab and press “Send” again. Red lines containing
403,500,blocked,Content Security Policyorrecaptchaare a ready-made hint for your developer – take a screenshot. - Check what the customer sees after sending. Does the thank-you page exist? Does the customer get an automatic confirmation (and does that confirmation stay out of spam)? Does it say when you will reply?
- Check the formalities. Next to fields collecting personal data there should be a short note on who processes them and why, with a link to the privacy policy. It is a GDPR requirement, and to a customer it signals a business that has its act together.
- Write down the result and repeat next month. A test done once protects you once. Put it in the calendar or hand it to someone on the team permanently – first day of the month, two minutes.
Symptom → cause → who fixes it
| What you see | Most likely cause | Who fixes it and how much work |
|---|---|---|
| “Sent”, but nothing arrives, not even in spam | The server is not sending mail (mail function disabled, expired SMTP key) or the recipient rejects the message without telling the sender | Hosting provider or web developer: switch sending to SMTP from your own domain, 1–2 h |
| Arrives only in spam | The sender impersonates the customer’s address; no SPF/DKIM for the domain; sending from a server with a poor reputation | Domain administrator (DNS records, 30 min) + developer (From on your domain, Reply-To = customer, 15 min) |
| The button spins or does nothing | Script error after an update, conflict with the cookie tool, reCAPTCHA or security-header block | Web developer, 1–3 h; a console screenshot halves the search |
| 404 after sending | Deleted thank-you page; changed address in the form settings | Anyone with access to the admin panel, 10 min |
| Enquiries arrive, but every third one is gibberish | No or too weak spam protection | Developer: honeypot + a simple rate limit, or Turnstile/reCAPTCHA, 1 h |
| Works on a computer, not on a phone | Field or button off-screen, dropdown not usable by touch, form inside an iframe | Web developer, 1–2 h; a phone screenshot is enough as a bug report |
| A customer says they “couldn’t send”, but it works for you | Spam protection rejects some real people (VPN, old browser, cookies disabled); word filter | Developer: lower the threshold, add a readable error message and a fallback contact (phone, e-mail) next to the form, 1 h |
How not to be back here in six months
- Store entries on the site, not only in e-mail. Most form plugins have a module that saves every submission in the site’s database. When mail fails, the entries are still there – and you have proof of when things stopped working.
- Send from your own domain over SMTP. The sender should be something like
forms@yourcompany.com, with the customer’s address in Reply-To. Add SPF and DKIM records for the domain – set up once, at your domain or mail provider. - Two recipients. A copy to a second mailbox (the owner’s, say) costs nothing and protects you from “the employee left and the form kept writing to them for a year”.
- A fallback contact next to the form. A phone number as a
tel:link and an e-mail address as plain text. If the form fails, the customer has a second route instead of a competitor. - Test once a month using the list above. Two minutes. Put it in the calendar.
What Webskan checks, and what it does not
Honestly: we do not submit your form – we do not want to fill customers’ inboxes with tests. Our in-depth audit does check everything visible without sending: whether fields have labels and readable error messages, whether the form works on a phone, whether it has spam protection and a data-processing notice, whether the thank-you page exists, whether the console is free of errors and whether the form’s scripts load at all. The “send a test from your phone” step stays with you – it takes two minutes and is in the table above. If you have just launched a new site and want a broader list, we have a 24-point launch checklist.
A quick picture, free
The free Webskan quick scan checks your site the way a customer’s phone sees it: performance, basic security and SEO. No e-mail, no sign-up, results in about 30 seconds.
Want forms, links, certificate and performance checked in one report with a to-do list for your developer? The Webskan in-depth audit ($69) includes a recheck after the fixes and 30 days of Webskan Monitor, which watches whether the site responds at all.
Sources and tools
- Google, Email sender guidelines – since 1 February 2024 every sender needs SPF or DKIM, and senders of more than 5,000 messages a day need SPF, DKIM and DMARC; “Don't impersonate other domains or senders without permission”
- Google, Trace an email with its full headers (“Show original”)
- Cloudflare, Turnstile – spam protection without puzzles for the user