A customer fills out your contact form. The page says the message was sent. Your inbox stays empty.
When WordPress is not sending emails, work through the delivery path in order: check the form’s notification settings, confirm how the website sends mail, review sender authentication, and look at the receiving inbox. Then submit the actual form again and verify that the message arrives.
The important distinction is simple: a success message on a form does not prove email delivery. WordPress’s wp_mail() documentation makes the same distinction for the underlying mail function: a successful return does not confirm that the recipient received the email.
Here is how to find the break without changing settings at random.
First, separate a missing email from a missing submission
There are several steps between a visitor pressing Submit and someone on your team reading the inquiry:
- The browser submits the form.
- The form validates and processes the request.
- The website generates a notification email.
- A mail service accepts the message for sending.
- The receiving system accepts, rejects, or filters it.
- The recipient finds it in the inbox or another folder.
A failure at one step calls for a different fix from a failure at another. If the form plugin stores entries, check whether the test submission is there. Some plugins or plans do not save entries by default, so do not assume an empty entry list proves that nothing was submitted.
An entry in WordPress shows that information was recorded. A local mail log may show that the website generated or handed off a message. Neither, by itself, proves that the message reached the inbox. Read the status and error details rather than treating the existence of a log entry as confirmation.
Use the symptom to choose the next check
| What you notice | What to check next |
|---|---|
| The form shows an error or will not submit | Validation, spam controls, browser errors, and the form configuration. |
| An entry is saved, but no notification is generated | Whether notifications are enabled, the recipient address, and conditional notification rules. |
| Both a mailer test and the real form fail | The sending connection, credentials, host restrictions, and provider error log. |
| A mailer test arrives, but the form email does not | The form’s recipient, From address, routing conditions, and spam handling. |
| One recipient receives it and another does not | Receiving-system filters, quarantine, forwarding, and the exact destination address. |
| The provider marks it delivered, but the inbox is empty | The receiving mailbox and its rules. “Delivered” may mean the recipient’s server accepted it, not that it landed in the inbox. |
Check what each status means in your provider’s documentation. For example, SendGrid’s activity documentation distinguishes a sending request from acceptance by the receiving mail server.
Step 1: Run a traceable test on the real form
Start with a small, recognizable submission. Use a subject or message such as “Website form test — November 3, 10:15 AM,” adjusted to your test time. Record the page URL, intended recipient, timestamp, and time zone.
Use an address you control and harmless test information. Submit from the public page in a private browser window so you experience the form as a visitor would. Note the exact success or error message.
Next, check the saved entry, any available mail log, and the recipient’s mailbox. Search for the test phrase in all folders, including spam, junk, and archive. If your business uses an email administrator, ask them to check quarantine and message tracing.
This gives you a specific message to investigate. “The form stopped working” is difficult to trace; a timestamp, recipient, and unique subject are much more useful.
Step 2: Check the notification settings
Open the notification settings for the form you actually tested. A site can contain several forms with different recipients and rules.
Check that notifications are enabled and that the To address is correct. Look for old staff addresses, spelling errors, an unmonitored inbox, or a field that unexpectedly replaces the recipient. Review conditions that send notifications only when a visitor chooses a particular service or location.
Do not assume that changing the WordPress administration email updates every form notification. Review the form’s own settings.
Also check whether the plugin marked the submission as spam. If it did, investigate the reason using the plugin’s tools and a controlled test. Turning off all spam protection on a public form can create a different problem without fixing the original one.
If only an attachment-heavy form fails, repeat the test with harmless text and no upload. That helps isolate file restrictions or message size from the basic sending path.
Step 3: Use a verified sender address
The From field identifies the sender. The Reply-To field controls where a response goes. Mixing those roles is a common configuration mistake.
For a typical contact form, use a provider-authorized address on your business domain as From. Put the visitor’s email address in Reply-To so your team can answer the inquiry without making the message appear to originate from the visitor’s mail provider.
A simple example is website@example.com as From, inquiries@example.com as To, and the submitted visitor address as Reply-To. The example domain is illustrative; your real sender must be verified and permitted by the service that sends your mail.
Contact Form 7’s mail guidance explains the same-domain From address and the separate Reply-To setting. Other form tools may use different labels, so follow the documentation for the plugin installed on your site.
After changing these settings, test both delivery and replying. A notification that arrives but sends the reply back to your own website address can still slow down lead follow-up.
Step 4: Check PHP mail and the sending connection
WordPress normally calls a mail function rather than operating a complete email delivery service itself. In a default setup, sending can depend on the web server’s PHP mail configuration. If that local mail environment is unavailable, restricted, or incorrectly configured, the message can fail before it reaches the recipient.
The official WordPress mail administration guide explains this dependency. Ask your host whether outgoing website mail is configured and whether restrictions or recent changes could affect it. Working email in your normal mail app does not prove that the website uses the same sending route.
If the server’s default route is unsuitable, configure a supported connection to an email provider through authenticated SMTP or the provider’s API. SMTP is a way for the website to submit mail to a sending server. An API is another supported route offered by some providers.
Installing an SMTP plugin is only the beginning. Complete the provider connection, verify the sender, and use the host, encryption, port, and authentication method specified in that provider’s current instructions. Avoid leaving multiple plugins competing to control outgoing mail.
Use the mailer’s test feature and read the result. An authentication error points to a different problem from a connection timeout or a sending limit. The mailer developer’s troubleshooting guidance can help interpret those failures, even though the exact screens depend on the tool you use.
Step 5: Check SPF and DKIM for the actual sender
Connecting the website to a provider and authenticating the sending domain are related tasks, but completing one does not automatically complete the other.
SPF identifies authorized sending systems for a domain. DKIM adds a signature that receiving systems can verify. DMARC checks alignment with the visible From domain and provides policy and reporting controls.
Ask your email provider or administrator to confirm that the DNS records cover the service the website now uses. Follow that provider’s exact records rather than copying settings from an unrelated tutorial. Google’s sender guidelines explain these authentication methods and why unauthenticated messages may be rejected or filtered.
Keep existing legitimate senders in mind when making DNS changes. Do not weaken authentication controls simply to make one test pass. After the provider confirms the setup, send a fresh test and inspect the received message’s authentication results. Google explains how to check message authentication; other inbox providers offer similar header or message-detail views.
Step 6: Investigate spam folders and receiving rules
If the message exists in the receiving system, find out where it went. Check junk folders, quarantine, forwarding rules, shared-mailbox rules, and whether the destination account can receive other external messages.
A test to a second inbox you control can narrow the investigation. If it arrives there but not in the business mailbox, share the evidence with the receiving email administrator. If it fails everywhere, return to the website and sending-provider logs.
Keep the first comparison simple. A short text notification is easier to trace than a message containing large attachments and several links. Once the basic route works, retest the full notification you intend to use.
Marking a legitimate message as not spam may help that mailbox, but it does not establish that all future visitors’ inquiries will be delivered correctly. Confirm the sender setup and the reason for filtering as well.
Step 7: Retest the full path after the fix
A successful test from an SMTP plugin checks its sending path. It does not test every form setting. Submit the real public form again after the mailer test succeeds.
- Use a fresh test phrase and record the time.
- Confirm the correct recipient receives the complete inquiry.
- Reply and check that the reply reaches the submitted visitor address.
- Test any service-specific notification routes.
- Check the customer confirmation email separately, if the form sends one.
- Verify that error alerts or logs can reveal a future failure.
If the form still fails while the mailer test works, review the form configuration before replacing the whole email setup. If the problem began after an update, investigate conflicts in a staging environment or with your developer so you do not interrupt the live site unnecessarily.
What to give your host or developer
Send the form URL, test timestamp and time zone, intended recipient, exact error text, and the sending provider’s message ID if available. Explain whether the submission was saved, whether a mailer test arrived, and whether a second inbox received the form notification.
Share logs securely and remove passwords, API keys, and unnecessary personal information. If logging records inquiry contents, limit access and retention to what your business needs. A temporary phone or alternative contact option can also help visitors reach you while the form is being repaired.
Stop guessing where the lead went
When WordPress is not sending emails, follow the evidence from the form to the receiving mailbox. Fix the failed step, then verify the complete customer journey. The useful result is an inquiry your team can read and answer.
If you need help reviewing the form and its website configuration, explore Around29’s web development services.