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.

  1. 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.
  2. 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”.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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

  1. 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”.
  2. 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.
  3. 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. A FAIL or SOFTFAIL means 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.
  4. 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.
  5. 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 Policy or recaptcha are a ready-made hint for your developer – take a screenshot.
  6. 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?
  7. 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.
  8. 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 seeMost likely causeWho fixes it and how much work
“Sent”, but nothing arrives, not even in spamThe server is not sending mail (mail function disabled, expired SMTP key) or the recipient rejects the message without telling the senderHosting provider or web developer: switch sending to SMTP from your own domain, 1–2 h
Arrives only in spamThe sender impersonates the customer’s address; no SPF/DKIM for the domain; sending from a server with a poor reputationDomain administrator (DNS records, 30 min) + developer (From on your domain, Reply-To = customer, 15 min)
The button spins or does nothingScript error after an update, conflict with the cookie tool, reCAPTCHA or security-header blockWeb developer, 1–3 h; a console screenshot halves the search
404 after sendingDeleted thank-you page; changed address in the form settingsAnyone with access to the admin panel, 10 min
Enquiries arrive, but every third one is gibberishNo or too weak spam protectionDeveloper: honeypot + a simple rate limit, or Turnstile/reCAPTCHA, 1 h
Works on a computer, not on a phoneField or button off-screen, dropdown not usable by touch, form inside an iframeWeb developer, 1–2 h; a phone screenshot is enough as a bug report
A customer says they “couldn’t send”, but it works for youSpam protection rejects some real people (VPN, old browser, cookies disabled); word filterDeveloper: 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