Why your contact form stopped delivering

“Our contact form has not sent anything in three weeks.” Not three weeks of no enquiries. Three weeks of enquiries that were submitted, acknowledged on screen with a friendly thank-you, and never arrived. It is the most expensive silent failure a business website has, and it is almost always a mail delivery problem rather than a form problem.

Why web servers are bad at sending email

A contact form submission ends with the web server trying to send an email. Twenty years ago that worked because every server had a mail program and every mailbox accepted whatever arrived. Today a message from an unknown server with no reputation, no authentication records and a cloud IP address that was in a spam blocklist before you rented it is dropped before anyone sees it. Not bounced. Dropped. The form plugin reports success because handing the message to the local mail program did succeed. What happened after that is invisible.

The three things we check

• Is the server’s IP on a blocklist? Most virtual servers are, by default, listed in a policy blocklist that says “this range should not send mail directly”. That one listing is enough for the major mailbox providers to refuse the message, and the server cannot get itself removed because the listing is about the range, not about you.
• Does the domain say this server may send for it? SPF, DKIM and DMARC records in DNS tell the receiving side which servers are allowed to send mail from your domain and let them verify the message was not altered. A form that sends “from” the visitor’s own address fails this test every time, because your server is certainly not authorised to send mail for Gmail.
• Is there a real mail service in the path? A server with no mail program at all fails loudly, which is better. A server with a half-configured one fails quietly for years.

What we do instead

The web server never sends mail directly. Every site we run hands its outbound mail to an authenticated relay: either the business’s own mail provider using an application password, or a transactional mail service with its own reputation. The relay has correct SPF and DKIM records, so the message arrives authenticated, and the form’s “from” address is always one on the business’s own domain, with the visitor’s address in reply-to so the recipient can still just hit reply.

For one client whose server sat in a blocklisted range, we routed the mail through a second server we already run for them, which had a clean address and the right DNS, and delivery went from zero to all of it the same afternoon.

Keep a copy on the server

Email is a delivery channel, not a database. We configure the form plugin to store every submission on the site as well, with the date, the fields and the sender. When someone asks “did we get an enquiry from so-and-so”, the answer is a search in the admin rather than a guess. It also means a mail outage loses nothing, because the submissions are still there to be read.

How to test it properly

Submit the form from an address at a major mail provider, and from one at the business’s own domain. Check the recipient’s spam folder, not just the inbox. Check the stored copy exists. Then look at the mail relay’s log for the message and confirm it was accepted by the receiving server, not just sent. If any of those steps is a guess, the form is not working, whatever the thank-you page says.

A contact form that works is part of every site we build or take over. If yours has gone quiet and you are not sure why, that is the first thing we would check.