Troubleshooting

Your WordPress contact form is not sending emails

There are four places a WordPress enquiry dies, and from the admin screen three of them look the same: no email, no error, no record. Work down them in order — the first is by far the most common and the least suspected.

1. The email is sending and landing in spam

By default WordPress sends through wp_mail(), which hands the message to PHP mail() on your web server. That mail has no SPF or DKIM signature tying it to your domain, and it usually claims to come from an address at your domain while originating from a server your domain never authorised. Gmail and Outlook treat exactly that pattern as forgery.

The tell is that it fails for some recipients and not others, and that the form worked for years before the recipient changed provider.

Check: Send a test to a Gmail address and a non-Gmail address. Different results mean deliverability, not a broken form.

2. A field has no name, so the browser never sends it

This is the one that costs the most and gets found the least. Every form control needs a name attribute. A control with an empty name is not a broken field — the browser discards it entirely before the request leaves the visitor. It never reaches WordPress, so nothing is logged and no plugin can warn you.

It happens most often in visual builders, where the field label is filled in and the separate "name" or "key" box is left blank. The form looks perfect and submits happily. The enquiry simply arrives with the email address missing — or, if it was the only required field, does not arrive at all.

We found this on a live dental practice site. Forty-six people had typed their email address into a box that threw it away.

Check: Open the page, right-click the field, Inspect, and look for name="". If it is empty, that field has never worked.

3. The form posts to somewhere that no longer answers

If the form action points at an endpoint that has moved, or at a plugin route that was deactivated, the browser posts into nothing. Some setups show the success message anyway, because the message is triggered by the submit event rather than by a response.

A success message is not proof of delivery. It only proves JavaScript ran.

Check: Open your browser devtools, Network tab, and submit. A 404, a 419, or no request at all is your answer.

4. Spam protection is silently rejecting real people

reCAPTCHA and similar tools score a visitor and reject anything below a threshold. Set too strictly, they refuse genuine visitors — older browsers, privacy blockers, corporate VPNs, anybody who filled the form in slowly.

If the token is missing entirely, most setups reject the submission outright, and a rejected submission is usually not stored. The lead is gone and there is nothing to review.

Check: Ask whoever runs the site whether rejected submissions are stored anywhere. If the answer is no, you cannot know what you have lost.

The uncomfortable part: causes 2, 3 and 4 produce no error, no log entry and no bounce. The form appears to work. You only find out when someone rings up asking why you never replied.


Frequently asked

Why does the form say "message sent" if nothing arrives?
Most success messages are shown by JavaScript when the submit button is pressed, not when the server confirms delivery. It confirms the click, not the enquiry.
Would an SMTP plugin fix this?
It fixes cause 1 only, which is a genuine and common cause. It does nothing for causes 2, 3 or 4, because in those cases no email is ever attempted.
How would I know if I am losing enquiries right now?
You cannot, from inside WordPress, if the data never reaches it. That is the gap FormHam exists to close — we check the rendered page itself, nightly.

Want us to check it for you?

We will test every form on your site and tell you exactly what we find. If nothing is wrong, we will say so.

Talk to us