WordPress 6 min read

When your WordPress contact form says sent but the inbox is empty

Contact form says sent but no email arrives? I explain how to trace missing WordPress enquiries, check delivery and get the right fix for your site.

When your WordPress contact form says sent but the inbox is empty

Your contact form shows a success message. The customer assumes you have their enquiry. Your inbox is empty, and you only discover the problem when someone phones to chase it.

When a WordPress contact form is not sending emails, I would trace one submission from the browser to the receiving mailbox. The form, the mail service and the inbox are separate stages. A green confirmation message does not tell us which of those stages completed.

Start with one identifiable test enquiry

I would submit the affected form with a unique subject, such as “Website enquiry test 01 October 09:30”, and record the time, page URL and address meant to receive it. Use invented test details rather than a real customer's personal information.

Then I would check what the visitor actually sees. Does the form finish submitting? Does it display a validation error? Is there a saved entry, if the plugin is configured to store entries? Does the notification appear in the outgoing mail service's records?

This gives us a trail to follow. Sending five more unlabelled messages and installing another mail plugin can make the original failure harder to identify.

A successful send is not proof of inbox delivery

The WordPress documentation for wp_mail() explicitly distinguishes a successful return value from the recipient receiving the email. Depending on the setup, WordPress may have handed the message to its mail transport without knowing what happened afterwards.

I would separate the evidence into stages:

  • Submission: did the website accept the form?
  • Notification: did the form configuration generate the expected message?
  • Handoff: did the sending service accept it?
  • Delivery: was it rejected, delayed or accepted by the receiving mail server?
  • Visibility: did it reach the inbox, spam folder, quarantine or a mailbox rule?

Even a delivery event usually needs interpreting in the context of the provider. It does not prove that someone opened the enquiry or that it appeared in their main inbox.

Check the actual form notification settings

The site's general administration email is not necessarily the address used by each form. I would inspect the recipient on the specific form, including any conditional routing. A sales enquiry and a support request may go to different people.

Common things worth checking include an old staff address, a disabled notification, a condition that no longer matches the form fields, or a copied form still using the original recipient. If only one form fails, those details matter more than a site-wide change.

I would also compare a plain test with the failing type of enquiry. If a basic message arrives but an attachment does not, the investigation should include file restrictions and message size. If one option sends to a different department, test that route explicitly.

Use a sender your website is authorised to use

The visitor's email address belongs in the enquiry and, where supported, the Reply-To field. Using it as the notification's From address asks your website to send as somebody else's domain.

For example, Contact Form 7's mail setup guidance calls for a From address on the website's own domain. I would check the form's settings alongside the sending provider's requirements, rather than copy a configuration from an unrelated site.

The aim is straightforward: the notification has an authorised sender, and clicking Reply addresses the person who submitted the form. Both need testing. An email that arrives but sends your reply back to your own website address still creates unnecessary work.

Inspect the mail service before changing everything

If the notification is generated but delivery fails, I would check the configured sending service, its account status and any error attached to the test message. Expired credentials, a disconnected account or a provider restriction need different fixes.

An authenticated SMTP or API connection can provide a clearer sending path, but installing a connector is not the same as configuring it correctly. I would verify the authorised sender and the domain records required by that provider, with the person who manages the domain where necessary. WordPress's mail administration guidance explains why the server and sender configuration matter.

I would avoid changing several mail plugins and DNS settings together. Make the change that the evidence supports, send a new identifiable test and compare the result. Keep the original settings recorded so an unrelated service is not accidentally disrupted.

If one mailbox receives it, investigate the other mailbox

A test to another address you control can help narrow the problem. If the same notification arrives there, I would look at the intended recipient's spam, quarantine, forwarding and rules, using the message timestamp and provider records to help the mailbox administrator find it.

That is a diagnostic comparison, not permission to redirect every customer enquiry into a personal mailbox. Keep the real destination appropriate for the business and restrict test content to what is needed.

Where a form stores submissions, that may provide a way to review missed enquiries. I would check whether storage was enabled and which records actually exist before promising recovery. Messages that were never stored cannot simply be recreated from an empty inbox.

Test the customer journey after the fix

I would finish by submitting the real public form, receiving its notification in the intended mailbox and checking that a reply goes to the test sender. If the form sends an acknowledgement or creates a CRM record, those are separate checks too.

For forms that matter commercially, I would agree a simple recurring test and a named person responsible for checking it. If entry storage or mail logging is used, decide who can access it and how long it needs to be retained. A useful operational record does not need to become an indefinite archive of enquiry content.

My WordPress development and support work covers investigating problems in existing sites as well as building new functionality. You do not need a redesign proposal just because a form has stopped reaching the inbox.

Is your website losing enquiries?Send me the form's page URL, what happens when you submit it and when you first noticed the problem. I can help trace the failure and scope the fix. Please leave passwords and customer messages out of the initial enquiry.
Get help with your WordPress form

Need a hand with this?

Get direct help with a WordPress fault, a custom feature or the regular upkeep of your website.

A related project

A custom price history feature for WooCommerce

Bespoke plugin work to record product price changes and present the history by date, delivered through an agency.

Talk directly to Adam

Share this article

Back to Blog