How to tell whether a client contact form has quietly stopped

Why a broken form gives no sign

Sending a form and sending an email are two separate jobs, and WordPress treats them that way. The browser posts the form, the site stores or processes it, the page returns a success message, and only after all that does something try to hand an email to a mail server.

If that last step fails, none of the earlier ones know. The visitor has already been thanked. The success message is not a report that you received anything; it is a report that the page finished loading.

Which is why this class of fault can run for a very long time. There is no error page, no admin notice, no uptime alert, and no bounce, because the failure is usually a message that was never accepted rather than one that was returned. Search Engine Land has documented a case where an agency lost months of leads to exactly this, with campaigns still delivering prospects the whole time.

Seven ways a WordPress contact form fails silently

Every one of these leaves the site looking healthy.

• The host switched mail off and told nobody. Hosts restrict or disable PHP's mail function to stop outbound spam, sometimes after a security event on the server. The site carries on working perfectly. Nothing in WordPress reports it.
• SMTP stopped authenticating. An API key expired, a password rotated, a mail provider suspended the account, or a host migration left the SMTP plugin pointing at settings that no longer exist. Extremely common straight after a move.
• An update changed where notifications go. A plugin or theme update resets a notification address or reads an old setting differently, and mail starts going somewhere nobody reads.
• It is arriving, in the spam folder. The mail is being sent and delivered, and filed somewhere the client never looks. From the site's side this failure is indistinguishable from success.
• Authentication stopped matching. SPF, DKIM and DMARC records get edited during a DNS change or a mail migration, and receiving servers quietly start refusing mail that used to be accepted.
• The address belongs to somebody who left. The form still sends faithfully to a mailbox that is full, closed, or forwarding into a void.
• A caching layer is serving an old form. The page a visitor gets is a stored copy, pointing at an endpoint or carrying a token that is no longer valid.

Notice how many of these are triggered by routine work. Updates, migrations and DNS changes are the ordinary business of running client sites, and they are also the events most likely to break a form. The maintenance is what breaks it, which is precisely why it goes unnoticed by the person who did the maintenance.

How to check one contact form today

Six steps, about five minutes per site.

• Submit the form yourself, from a browser you are not signed into on that site, using an email address on a different domain from the client's.
• Check the inbox and the spam folder. A message in spam is a different problem from no message at all, and the fix is different too.
• Check the plugin's own entry list. Most form plugins store submissions in the database. Stored but not emailed means the form works and the mail is broken. Not stored either means the form itself is failing.
• Send a test mail from WordPress directly, with any of the small test plugins that do this. If that fails too, the problem is the site's mail, not the form.
• Check the notification address on the form, and check a human still reads it.
• Look at when it last worked. Line the last successful enquiry up against the site's update history, and the cause is usually sitting on the same date.

Step three is the one that saves the most time, and it is the one people skip. It splits the problem cleanly in half: a stored submission with no email is a mail problem, and an unstored submission is a form problem. Everything you do next depends on knowing which of the two you have.

If it turns out to be mail, the durable fix is to stop relying on the server's own mail and send through a proper mail service with authentication in place, then get SPF, DKIM and DMARC lined up for the sending domain. That is well-trodden ground and there is good documentation for it everywhere.

Why testing by hand stops working around ten sites

The six steps above are fine for one site. Multiply them by forty client sites and by every event that warrants a re-test, and the arithmetic stops working. Nobody is going to submit a hundred and twenty test enquiries a month, and the ones they do submit will be on the sites they already worry about rather than the quiet one where a form has been dead since a migration in March.

Manual testing also has a subtler flaw: it tells you the form worked at the moment you tested it. It says nothing about the three weeks between tests, which is where the leads actually went.

So the routine that gets written into the care plan is not the routine that gets done, and everyone involved knows it.

Watch the enquiries, not the form

There is a way round this that does not depend on anybody remembering anything.

Instead of testing whether a form can send, watch what it is actually producing. If real submissions from every client site land somewhere you can see, then a form that has stopped announces itself: the site simply stops appearing. No test needed, no schedule to keep, and the check happens continuously rather than on the day somebody got round to it.

It also catches the failures a test submission never would. A test you send yourself will not show you that genuine enquiries are being filed as spam, or that a client's mailbox stopped being read in April. Real traffic shows you both.

This is what contact form submissions in WPCentrify does: enquiries from every connected site collected into one list, with a spam filter that explains its decisions rather than just filing things away. A site with no enquiries this month is visible next to the ones with plenty, which is the entire diagnostic.

A routine that actually gets done

If you take nothing else from this, take these four:

• Test after the event, not on a calendar. Updates, migrations, DNS changes and mail provider switches are when forms break. Test then and you catch most of it.
• Know which plugins store entries. On sites where the plugin only sends and stores nothing, a failed notification is an unrecoverable lead. Those sites deserve attention first.
• Put SMTP on every site. It removes the single most common cause, even though it removes none of the others.
• Watch the output, not the mechanism. Somewhere you can see enquiries arriving across the portfolio turns this from a task somebody has to remember into something you would notice anyway.

The failure this article is about is not really a technical problem. Technically it is small, and usually a ten-minute fix. What makes it expensive is the time between the break and the discovery, and the only thing that shortens that is watching the right thing.