# The contact form says "message sent" but nothing arrives

> This is a different problem from WooCommerce order emails: here it’s a contact or quote form (Contact Form 7, WPForms, Gravity Forms...) showing a success confirmation to the visitor, while the email never actually leaves the server. The confirmation shows client-side regardless of whether the send actually succeeded server-side, which makes this more deceptive than a plain lost email.

- Source canonique : [https://allaux.fr/en/wordpress-woocommerce/problemes/formulaire-contact-ne-part-pas](https://allaux.fr/en/wordpress-woocommerce/problemes/formulaire-contact-ne-part-pas)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> The confirmation is produced in the browser and proves nothing: open the Network tab, submit the form and read the response code the server returns. If it is clean, the blockage is in delivery. Set WP_DEBUG and WP_DEBUG_LOG in wp-config.php, submit again, read wp-content/debug.log, then move sending to an authenticated SMTP relay.

## How I go about it

1. **Reproducing and checking the network** — I send a test and check the browser’s network tools to see whether the submit request actually reaches the server, or gets blocked before it’s even sent.
2. **Checking reCAPTCHA or hCaptcha** — I check that the site key and secret key actually match, and that there’s no mismatch between the domain configured with the provider and the site’s real domain.
3. **Testing the server-side send** — I test wp_mail() directly to find out whether the block comes from the send function itself, often limited by PHP’s mail(), or an earlier step on the form side.
4. **Looking for a JavaScript conflict** — If the request never leaves, I look for a plugin breaking the form’s Ajax submit handler, often another plugin loading a duplicate or conflicting script.
5. **Setting up an authenticated SMTP relay** — If the block is on the send side, I configure an authenticated SMTP relay via the phpmailer_init hook, more reliable than the server’s native mail() function.

## What I handle regularly

- The "your message has been sent" confirmation shows, but nothing ever arrives in the inbox
- The form seems to work, but no trace of the submission shows up anywhere
- The submit button stays stuck or doesn’t react at all to a click
- The form used to work fine, then stopped sending with no setting changed
- Some messages arrive, others don’t, with no obvious pattern

## Why the confirmation sometimes lies

A contact form relies on the same weak point as transactional email: wp_mail() defaults to PHP’s mail() function, often poorly regarded by receiving mail servers. But here the trap is more deceptive, because the plugin shows a client-side success message as soon as the JavaScript runs, without waiting for reliable confirmation that the server-side send actually went through.

A misconfigured reCAPTCHA or hCaptcha key, site key and secret key swapped, or a domain mismatch, can silently block the submission itself: the visitor sees no error and no visible blocking. A JavaScript conflict caused by another plugin can also break the form’s Ajax submit handler, which looks like it "works" while never sending anything to the server.

## Misconfigured SMTP, or broken JavaScript

> A misconfigured SMTP relay is fixed at configuration level, with a plugin or a phpmailer_init hook. A JavaScript conflict or validation breaking the submission needs proper front-end debugging, not just a setting change.

## Related pages

- **Custom WooCommerce plugin development** — When a form needs to connect to a business tool beyond a simple email send. ([/wordpress-woocommerce/extension-sur-mesure](/wordpress-woocommerce/extension-sur-mesure))
- **Urgent troubleshooting** — A silent quote form costs leads every day it stays broken. ([/services/depannage-urgent](/services/depannage-urgent))
- **All WooCommerce work I handle** — Other faults and features I handle on WooCommerce. ([/wordpress-woocommerce](/wordpress-woocommerce))

## FAQ

### How do I know if the problem is my mail server or the form itself?

By testing wp_mail() independently of the form. If the direct send also fails, the problem is server-side or SMTP. If it works, the block is earlier, in the form or its JavaScript.

### Can reCAPTCHA really block a submission without showing anything?

Yes, a misconfigured key or a mismatched domain can silently prevent the submission, with no visible error message for the visitor.

### Is an SMTP plugin enough to fix this?

If it’s a deliverability issue (PHP’s mail() poorly regarded), yes, an authenticated SMTP plugin is usually enough. If it’s a JavaScript conflict, an SMTP plugin won’t change anything.

### Why did it use to work and not anymore?

Often another plugin update introduced a JavaScript conflict, or a reCAPTCHA key was renewed without updating both sides (site and provider).