Your Contact Form Fails Quietly. Here's How to Check

A contact form is the only part of a website that is allowed to fail without saying anything. If a page is down, you see a broken page. If your payment gateway stops working, a customer rings you. But if a form stops delivering, the visitor sees Thank you, we'll be in touch shortly, feels satisfied, and goes away. You see nothing at all. You just have a quiet week, and then a quiet month, and you assume the market is slow.

This is worth taking seriously because the failure is invisible in both directions. The sender thinks they have contacted you. You do not know they exist. Nobody complains, because from each person's point of view nothing went wrong.

How a form actually gets to your inbox

You cannot debug this without a rough mental model of the journey, so here it is in plain terms. There are roughly six steps, and the message can die at any of them.

1. The visitor's browser loads the form. Usually some JavaScript — small programs that run inside the browser — is involved, for validation, for a spam check, or because the whole form is built by a plugin.
2. The visitor presses submit. The browser sends the data to your server, or to a third-party form service.
3. The server accepts and processes it. It may store the entry in the website database.
4. The server hands an email to a mail system. This is the step nearly everyone gets wrong, and we will come back to it.
5. The receiving mail provider decides whether to accept it. Gmail, Outlook, or your hosting company's mailbox makes a judgement about whether this message is legitimate.
6. The message lands somewhere you look. Inbox, Promotions tab, Spam, or a mailbox nobody has opened since the site launched.

Six steps, six places to lose an enquiry. Let us go through the ones that fail most often.

The email that pretends to be your customer

Here is the single most common cause, and it is nearly always invisible.

Most contact forms, by default, send the notification email with the visitor's address in the From field. It feels helpful — you can hit reply straight away. But think about what is actually happening. A server in a data centre, owned by your hosting company, is sending an email claiming to be from rajesh@gmail.com. It is not Gmail. It has no authority to speak for Gmail.

Receiving mail systems check for exactly this. Three acronyms matter here, and each gets one sentence:

• SPF (Sender Policy Framework) is a public list, published in your domain's DNS settings, of which servers are permitted to send mail claiming to be from your domain.
• DKIM (DomainKeys Identified Mail) is a cryptographic signature added to the message, proving it left a server that holds your domain's private key.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) is your instruction to the world about what to do when SPF and DKIM fail — ignore it, quarantine it, or reject it outright.

When your web server sends a message claiming to be from a Gmail address, Gmail's SPF record says that server is not authorised. Gmail's DMARC policy is strict. The message is refused or filed as spam. Your form says thank you, the server says sent, and the message dies on the receiving end where nobody involved can see it.

The fix is structural, not clever. The email should be sent from your own domain — something like website@yourbusiness.in — with the visitor's address placed in the Reply-To field instead. Your reply button still works. The sending domain now matches a server that is genuinely authorised to send for it. Then make sure your domain has an SPF record that includes whatever actually sends the mail, and DKIM signing switched on.

Better still, stop letting the web server send mail directly. Route form notifications through a proper transactional email service — Google Workspace SMTP, Amazon SES, Brevo, Postmark, whichever suits — using authenticated credentials. A shared hosting server's default mail function has a reputation it shares with every other site on that machine, including the ones sending things you would not want associated with your brand.

The form that never sends at all

The second family of failures happens before anything reaches a mail server.

JavaScript errors. A plugin updates, a theme updates, a tracking script from an ad platform gets pasted into the header, and two pieces of code collide. On a modern site a single JavaScript error early in the page can stop everything after it from running — including the code that submits your form. The page looks perfect. The button does nothing, or spins forever. Nobody reports it, because the average visitor assumes they did something wrong and leaves.

Anti-spam that is too aggressive. Google reCAPTCHA and similar tools score visitors on how human they appear. Set the threshold high and you will quietly block real people — particularly someone on an older Android phone, a shared office IP address, or a VPN. Worse, honeypot fields (hidden inputs that bots fill in and humans do not) get filled by password managers, which auto-complete every field they can find, including invisible ones. Your customer is discarded as a bot.

Expired or misconfigured API keys. If your form pushes to a CRM (customer relationship management system — the software holding your leads and their history) or an email tool, the connection key can expire or get revoked. Many form plugins are cheerfully indifferent to this: the submission succeeds from the visitor's point of view and the handover silently fails. If you have data flowing between systems, someone needs to own the integration between your website and your CRM rather than assuming it will keep working forever.

The mailbox nobody opens. Forms are often set up to email whoever built the site, or an info@ address that was forwarded to a staff member who left in 2023. Or the mailbox hit its storage quota and has been bouncing everything for four months.

How to test yours properly

Most owners test by filling in the form from their own laptop with their own email address. That test passes almost every time, and proves almost nothing. You are on the office network, logged into everything, with a browser Google trusts. You are the least representative visitor your site has.

Here is a test that tells you something. Give it twenty minutes.

1. Use mobile data, not office Wi-Fi. Turn Wi-Fi off on your phone. Most enquiries arrive from phones on mobile networks.
2. Use a browser you are not logged into. Open a private window. Do not let your password manager touch the fields.
3. Send from four different providers. One Gmail address, one Outlook or Hotmail, one Yahoo, and one address on a business domain. Deliverability differs wildly between them. If three arrive and one does not, you have learnt something valuable.
4. Put a timestamp in the message. Type the actual time. Later you will be comparing what the website thinks it received against what arrived.
5. Check spam, Promotions and Updates. Not just the inbox. Check on the phone app and in the web interface — filters can behave differently.
6. Check the database, not just the email. Most form plugins store every submission. Compare the stored list against your inbox. Entries in the list with no matching email is proof of a mail delivery problem, cleanly separated from a JavaScript problem.
7. Test every form, not the main one. The quote form, the callback widget, the newsletter box, the form on the landing page from last Diwali's campaign. They are often built with different tools and break independently.
8. Test on an old phone. Borrow one. A five-year-old Android with a slow connection is a large share of Indian web traffic, and it is where JavaScript failures show up first.

What the results tell you

Symptom	Most likely cause
Stored in database, no email anywhere	Sending address or SPF/DKIM problem
Email in spam folder only	Authentication weak, or sending from the visitor's address
Nothing stored, nothing sent, button spins	JavaScript error or failed spam check
Works on desktop, fails on phone	Script conflict or a field hidden off-screen
Arrives for Gmail, not for Outlook	Domain reputation or missing DMARC

What not to buy

Two things get sold as solutions to this and are not worth your money.

Email deliverability audits sold as a monthly retainer. SPF, DKIM and DMARC are DNS records. They are set up once, checked when you change mail providers, and otherwise sit there doing their job. Paying a monthly fee to have someone re-check records that have not changed is a subscription to nothing. Pay for the setup, ask for the records to be documented in writing, and move on.

Replacing a working form with an expensive form builder. When enquiries go missing, the reflex is to buy a fancier form — multi-step, conditional logic, drag-and-drop everything. It rarely helps, because the failure is almost never in the form's design. It is in the delivery. A shinier form built on the same broken plumbing loses enquiries just as efficiently, and now you have more JavaScript to go wrong.

Also be wary of anyone who proposes WhatsApp as the fix without addressing the underlying problem. A WhatsApp button is a good addition — many Indian buyers prefer it, and it has the enormous advantage of showing the sender a delivered tick. But it is not a repair. It is a second door next to a broken one, and you still have a broken one.

Build in a tripwire so it tells you next time

Fixing today's failure is the smaller half of the job. The real goal is that the next failure announces itself.

Three practical measures, in increasing order of effort:

• Always store submissions in the database as well as emailing them. Then email is a convenience, not the only copy. If mail breaks, the enquiries are still there.
• Send a copy to a second address on a different provider. If your business runs on Google Workspace, add an Outlook address as a silent second recipient. When one fails, the other usually does not.
• Put a diary reminder on the first Monday of every month to send one real test from your phone on mobile data. Sixty seconds. It is the cheapest insurance in your business.

If you want to go further, a monitoring service can submit a test entry automatically each day and alert you when the confirmation does not arrive. That is genuinely useful, and it is the sort of thing worth setting up alongside the rest of your business automation — the point of automation is that systems tell you when they break, rather than waiting for you to notice a thin month.

One honest caveat: spam filtering is a moving target. Gmail and Outlook change their rules, and they do not publish the details. Good authentication makes delivery far more likely; nobody can promise it. That is another argument for storing everything in the database, where no filter can touch it.

What to do this week

Run the twenty-minute test above, today, from your phone on mobile data, with four different email providers. Compare what arrives against the stored submissions list in your website admin. If there is a gap, you now know roughly where it is, and this article should help you tell your developer what to look at rather than asking them to "check the form".

Then fix the sending address so notifications come from your own domain, confirm SPF and DKIM, and add a second recipient on a different provider. If any of that is beyond what you want to handle in-house, our technical support and web development teams deal with this regularly, and you are welcome to get in touch — though we would rather you ran the test first, because knowing which step is failing saves everybody time.

Questions we get asked