A customer submits your contact form, but no notification arrives. An order confirmation goes missing. A password-reset message never reaches the user.
These situations can look identical from the inbox, but the cause may be different. The website might not generate the message, the sending service might reject it, or the receiving mailbox might filter it.
If WordPress is not sending emails, start by finding where the message stops. That gives you a better basis for fixing the problem than repeatedly changing plugins or mail settings.
This guide explains the checks to make, how to interpret delivery evidence, and how to test the final result.
First, Understand What “Sent” Actually Means
Many WordPress notifications use the wp_mail() function. WordPress documentation states that a successful return value does not prove the recipient received the email; it means the sending method processed the request without reporting an error. Developer.WordPress.org
Think of the journey in stages:
| Stage | Question to investigate |
|---|---|
| Website action | Did the form submission, order event, or reset request occur? |
| Message generation | Did WordPress or the plugin create a notification? |
| Sending service | Was the message accepted, rejected, or queued? |
| Receiving server | Did it accept or reject the message? |
| Mailbox | Did it reach the inbox, spam folder, quarantine, or a rule-controlled folder? |
A “success” message at one stage does not establish success at every later stage.
1. Identify Which Emails Are Missing
Before changing anything, record what works and what fails.
Check whether the problem affects:
- Contact-form notifications.
- Password-reset emails.
- New-user messages.
- Order or booking confirmations.
- Administrative notifications.
- Every website-generated message.
Also note whether it affects all recipients or only one mailbox provider.
| Symptom | Useful starting point |
|---|---|
| One form fails | Its notification settings and conditions |
| All website emails fail | Shared sending configuration and service logs |
| Only one recipient is affected | Address, filtering, rejection, or suppression |
| A manual test arrives but order emails do not | The order notification’s trigger and settings |
| Emails arrive in spam | Sender authentication, reputation, and message content |
Record when the issue began and whether it followed a hosting move, plugin update, password change, or DNS edit.
2. Check the Recipient and Mailbox
Verify the destination address in the specific notification settings.
A form plugin may use its own recipient address rather than the WordPress administration email. Other plugins can have separate recipients for each notification type.
Then check:
- Spam and junk folders.
- Mailbox rules and forwarding.
- Organizational quarantine.
- Mailbox storage limits.
- Spelling errors or obsolete addresses.
Search by subject, sender, and approximate time.
For a controlled comparison, send a non-sensitive test message to two mailboxes you own at different providers. This can help distinguish a broad sending problem from a recipient-specific issue.
3. Confirm the Notification Was Triggered
A working email connection cannot deliver a message the application never created.
For a contact form, check:
- Whether the submission completed.
- Whether the notification is enabled.
- Whether conditional rules prevented it.
- Whether spam protection blocked the submission.
- Whether the recipient field resolves correctly.
For an order or booking plugin, check which event is supposed to generate the message. Confirm that the event actually occurred.
If submissions are stored, inspect the relevant entry. Do not assume every form plugin stores submissions automatically.
Test the Actual Workflow
An email plugin’s test button checks its configured sending route. It does not necessarily test a contact form’s conditions, an order-status trigger, or another plugin’s separate integration.
After the basic mail test, repeat the action customers use.
4. Use an Authorized Sender Address
A common configuration problem is putting the visitor’s email address in the From field.
Your website may then appear to send mail on behalf of a domain it is not authorized to use.
For contact notifications, a practical configuration is:
| Field | Example |
|---|---|
| From | Website Notifications <notifications@example.com> |
| To | The business’s notification mailbox |
| Reply-To | The visitor’s validated email field |
Use a sender your chosen sending service permits and authenticates.
Contact Form 7 specifically recommends a From address belonging to the website’s domain and explains how Reply-To lets the business reply to the person who submitted the form. Contact Form 7
Follow your own plugin’s field syntax. A placeholder copied from another plugin may not work.
5. Inspect Logs Before Changing the Sending Route
Where available, check both the website-side log and the sending provider’s activity log.
Look for:
- Test timestamp and time zone.
- Recipient address.
- Sender address.
- Message or request identifier.
- Error code.
- Queue, bounce, or rejection status.
What Different Results Suggest
| Result | What to investigate next |
|---|---|
| No message appears in the relevant log | Notification trigger or the correct logging location |
| Authentication error | Credentials, authorization, or permitted sender |
| Connection timeout | Host restrictions, endpoint, port, or network access |
| Sender rejected | Sender verification and domain configuration |
| Queued or deferred | Provider explanation and retry status |
| Bounced | Exact recipient-server rejection |
| Accepted or delivered | Provider’s status definition and recipient-side filtering |
A missing website log is not definitive proof that no message was generated. Some integrations send directly through their own API and may bypass another plugin’s logging.
Protect Information in Logs
Logs can contain message bodies, customer information, and password-reset links.
Restrict access, use suitable retention settings, and redact sensitive information before sharing screenshots with support.
Never publish credentials, API keys, or full debug logs in a public forum.
6. Check SMTP or API Delivery Settings
If the current sending route is failing or unsuitable, an authenticated SMTP or transactional-email integration may help.
- SMTP sends through a configured mail server.
- API delivery submits messages through a provider’s supported integration.
Neither option guarantees inbox placement. Both still depend on correct configuration and recipient-side acceptance.
Review:
- Server or API endpoint.
- Provider-prescribed port and encryption.
- Authentication method.
- Approved sender.
- Account status and sending allowance.
- Any sandbox or recipient-verification restrictions.
Use the provider’s current instructions rather than guessing settings.
If the provider requires OAuth or an app password, use its supported method. Do not disable certificate verification or weaken account security to make a test pass.
Keep one clearly defined mail-routing configuration. Multiple plugins attempting to control the same messages can make diagnosis harder.
7. Verify Domain Authentication
Authentication helps receiving systems assess whether messages are authorized.
| Mechanism | Main purpose |
|---|---|
| SPF | Identifies servers authorized to send for an envelope-sender domain |
| DKIM | Adds a domain-associated signature that receivers can verify |
| DMARC | Checks alignment with the visible From domain and publishes policy/reporting instructions |
Google’s Gmail guidance requires SPF or DKIM for all senders to personal Gmail accounts, with additional requirements for bulk senders. It recommends setting up SPF, DKIM, and DMARC to improve delivery. Gmail Help
Make DNS Changes Carefully
Use the exact records supplied by your sending provider.
Before saving changes:
- Check the hostname.
- Check whether an existing record needs updating.
- Confirm which systems send for the domain.
- Keep a copy of the previous configuration.
- Use the provider’s verification check afterward.
Do not overwrite working email records blindly. MX records primarily control incoming mail routing; changing them is not a general fix for website-generated email.
If you receive a test message, inspect its authentication results using the mailbox provider’s message-details or original-message view.
8. Check Hosting Restrictions and Provider Limits
Ask your host or sending provider whether the website is encountering:
- Outbound connection restrictions.
- Disabled or restricted server mail.
- Sending quotas.
- Account suspension.
- Rate limits.
- Recipient suppression after a previous bounce.
Provide an exact timestamp and error message where possible.
If the website sends to its own domain but those messages fail while external tests work, ask the host to check whether local mail routing matches the domain’s actual email setup.
Do not change unrelated hosting settings without evidence.
9. Test for Plugin Conflicts Safely
If the problem followed an update or appears tied to a plugin, test changes in staging where practical.
Use a backup, change one component at a time, and record the result.
Keep staging messages confined to test recipients. Avoid triggering real customer confirmations, subscriptions, or payment-related workflows.
Do not disable essential security or checkout plugins on a busy live website simply to run a broad experiment.
10. Verify the Fix From Start to Finish
After making a change:
- Send a basic mail test.
- Submit the real contact form.
- Test other affected notifications using controlled accounts.
- Check the sending log and recipient mailbox.
- Confirm sender, subject, formatting, and reply behavior.
- Test more than one recipient provider where possible.
For order-related tests, use the store’s supported test process and check whether notifications depend on a specific status.
A single successful test is useful evidence, but repeat the workflows that originally failed.
What to Send Support
A concise report helps the right team investigate:
Issue: [Which notifications are missing]
Started: [Date and relevant recent change]
Sending route: [Host mail, SMTP provider, or API integration]
Test timestamp and time zone: [Details]
Result: [Exact redacted error or status]
Checks completed: [Recipient, trigger, sender, logs, authentication]
Share message identifiers privately when requested. Keep secrets and customer content out of public tickets.
Frequently Asked Questions
1. Why does my form say “sent” when no email arrives?
The message may have been accepted for processing without reaching the inbox. Check the notification configuration, sending-provider activity, and recipient filtering.
2. Will installing an SMTP plugin fix every WordPress email problem?
No. It will not fix an incorrect recipient, disabled notification, failed trigger, or every deliverability issue. Diagnose the failing stage first.
3. Why does the email test work but my contact form fail?
The test may use different settings or bypass the form’s conditions. Inspect the actual submission and its notification configuration.
4. Should I use a customer’s address in the From field?
Use a sender authorized by your sending service. For form notifications, place the customer’s validated address in Reply-To where supported.
5. Can I safely log every outgoing email?
Only with appropriate access controls and retention. Messages may contain personal information or security-sensitive links. Log only what you need for diagnosis.
Conclusion
Find where the email stops before changing the system.
Check the recipient, confirm the notification trigger, inspect the logs, and verify the sending route and authentication. Then retest the actual customer workflow. This approach produces a clearer diagnosis and makes it easier to confirm that the problem has been resolved.
