Quick answer: Follow one test enquiry through four checkpoints: the form, the saved submission, the sending service and the recipient inbox. A success message is not a delivery receipt. Find the first missing checkpoint before changing plugins or DNS settings.
Start here: Match the symptom to the next check · Copy the test record
For: small service businesses whose website form appears to work but enquiries do not arrive. This is a troubleshooting framework, not a diagnosis of your site. Contact Form 7 is a documented example; other forms have different storage and sending behaviour.
- First, give customers a working alternative
- Find the first checkpoint you cannot verify
- Check the destination before touching the infrastructure
- Keep From, To and Reply-To separate
- Example: the form was working, the hand-off was not
- Copy a small evidence record
- When is the issue resolved?
- Useful detail: A successful send call is not a received email
First, give customers a working alternative
If genuine enquiries may be disappearing, make a verified alternative contact route visible while you investigate. That might be a monitored phone number or an email address you have actually tested. Do not send visitors from one unverified route to another.
Tell the person who normally receives enquiries what you are checking. Agree on a short test window and a recognisable marker, such as FORM-TEST-20260929-A. Use a test address you control and a harmless message. Avoid real customer records, attachments or confidential project details.
Record the time and time zone, page URL, browser and expected recipient. Change one thing at a time. Replacing the form, mail plugin and recipient together might make the symptom disappear, but it leaves you guessing which change mattered.
Find the first checkpoint you cannot verify
These stages are separate. Some products combine them or do not store submissions, so an absent entry is only meaningful after you check how that form is configured.
On a small screen, swipe the table sideways.
| What you see | What it does not prove | Next check |
|---|---|---|
| Validation error or no completion message | That the form accepted the enquiry | Required fields, visible error text and documented form status |
| Success message, no saved entry | That a message was stored or delivered | Whether entry storage exists and is enabled; then sending evidence |
| Saved entry, no notification | That a notification was attempted | Notification recipient, conditions and sending-service log |
| Sending service accepted the message | That it reached the intended inbox | Delivery event, bounce, quarantine, spam and mailbox rules |
| Message arrives but nobody responds | That ownership and reply routing work | Assigned owner, Reply-To and a reply to your controlled test address |
Choose the next check from the evidence you actually have
No completion message: correct a visible validation error and retry once with a unique marker. If the page still gives no clear result, record the browser and time before inspecting server or form logs. Do not infer delivery from a button click.
Completion message, but no stored entry: first confirm whether this form is configured to save entries at all. If it is not, look for a sending event and mailbox receipt; an empty entries screen cannot diagnose this route. If storage is expected, investigate that missing record before changing mail settings.
Stored entry, missing email: compare the exact route, notification condition and recipient for that entry with the sending-service event. If the event shows acceptance, ask the mailbox administrator to check bounce, quarantine and forwarding. If no event exists, investigate the form-to-sender hand-off. Keep the entry identifier and marker together so each team checks the same test.
Email received, no reply: assign an owner and test Reply-To with your controlled address. A delivery fix is not complete if the team still cannot answer the enquiry.
Contact Form 7’s official explanation of a successful response distinguishes completion of the sending function from later receipt. Its FAQ also says the plugin does not itself save submitted messages. Do not assume that a successful-looking form has a recoverable inbox behind it.
Check the destination before touching the infrastructure
Read the configured notification address character by character. Is it the current shared inbox, an old employee address or a forwarding alias? Does a conditional rule send a particular service choice to someone else? Inspect the exact path used by your test.
- At the form: check which notification is enabled and which submitted values control routing.
- At the mailbox: search for the unique test marker across inbox, spam, quarantine and archive. An administrator may need to inspect organisation-level quarantine.
- At a forwarding address: check the final destination too. Delivery to an intermediate account is not the same as receipt by the working team.
- At the team: confirm that someone actually monitors the destination and knows how to cover an absence.
If a direct message to the destination arrives but the form notification does not, you have narrowed the problem. You have not proved the form plugin is broken: the sender, sending service or message rules can still differ.
Keep From, To and Reply-To separate
These fields have different jobs. To is the business recipient. From identifies the sender of the notification. Reply-To tells the recipient where a reply should go.
For Contact Form 7, the mail setup documentation says the From address should belong to the website’s domain. Its mail best-practice guide explains using Reply-To for a different reply address and consulting the sending provider about authentication.
A conceptual setup is: an authorised address on your domain sends the notification to the business inbox, while Reply-To contains the visitor’s validated email field. Use your provider’s actual requirements; this is not a configuration string to paste unchanged.
Do not copy an SPF, DKIM or other DNS value from an unrelated tutorial. Ask the authorised mail administrator to check the provider’s current instructions and existing records. Do not disable spam protection across the business just to make one test pass.
Example: the form was working, the hand-off was not
Fictional example: a consultancy submits test A at 10:15. The page shows success and the form’s configured storage contains the entry. The notification is addressed to an old project alias. The intended shared inbox contains no matching message.
- Record the entry identifier, time and configured alias. Keep the evidence; do not repeatedly resubmit.
- The authorised administrator checks where that alias routes and updates the notification destination if appropriate.
- Send a new, uniquely labelled test B. Confirm one saved entry, one notification in the intended inbox and the correct customer details.
- Reply to the controlled test address. Confirm the reply arrives there, rather than returning to the website’s sending address.
- Record the change, result and person responsible. Review any stored enquiries from the affected period through the team’s approved access process.
The lesson is not that aliases are bad. It is that every extra hand-off needs an owner. A form can be very cheerful while sending your leads somewhere nobody looks.
Copy a small evidence record
- Test marker / time zone: unique label and submission time.
- Page and route: exact form URL and service choice tested.
- Acceptance: visible outcome and saved-entry identifier, if storage exists.
- Sending: service event or log reference; write “unavailable” if you cannot inspect it.
- Receipt and reply: intended mailbox, folder, receipt time and controlled reply result.
- Change and owner: one change, person responsible, retest outcome and next review.
Collect only the evidence needed. Message logs can contain personal data; restrict access and use the business’s retention rules rather than keeping everything indefinitely.
When is the issue resolved?
Close the incident when the intended recipient can find and answer a representative test through each important route. Include a valid minimal submission, a relevant conditional route and a mobile submission. Test an invalid entry too: the visitor should receive a useful error, not a misleading success.
Keep unresolved paths marked open and retain the alternative contact route while they matter. Recheck after changes to the form, notification address or sending service. A test proves that test worked at that time; it does not guarantee every future delivery.
Next: use the contact-page checklist for the visitor-facing copy, then the follow-up process for ownership. For analytics, separate clicks from actual enquiries.
Official documentation checked September 29, 2026. The diagnostic sequence and acceptance checks are our editorial recommendations, not measured results from a client system.
Useful detail: A successful send call is not a received email
WordPress’s wp_mail documentation says a true return value does not establish that the recipient received the email.
Use the application log to locate the next checkpoint, not to close the incident. The destination mailbox and the human handling the enquiry still need their own evidence.
Try this:
- Record the marked test submission and send-attempt time.
- Inspect the expected mailbox, including spam or quarantine where authorized.
- Confirm the assigned person can find and handle that exact test message before marking the route restored.
Source: WordPress: wp_mail return values. Checked October 3, 2026. The practical check is a PSL suggestion.
