When Contact Form 7 is not sending email, start by recording what happened in the browser. A rejected submission, a successful submission with no message at the destination, and an email in quarantine are different problems. Changing several settings at once makes them harder to distinguish.
1. Record the browser result first
Open the published form while signed out of WordPress, enter safe synthetic data, and submit once. Record the page URL, exact response message and test time. Keep client data and credentials out of screenshots and support tickets.
If the form rejects input or never reaches a success response, investigate that before email delivery. Confirm required fields are filled, check the browser console and network request for errors, and review recent form, theme, caching or security changes. Do not disable spam protection on a live site just to get a passing test.
If you see a success message but no expected email, continue down the mail path. Contact Form 7’s official FAQ explicitly discusses this situation; the visible response is not an inbox receipt.
2. Review the Contact Form 7 Mail tab
In WordPress, edit the exact form embedded on the page and open its Mail tab. Check the destination carefully for typos and old client addresses. Review the sender address and resolve any configuration warnings using the plugin’s documentation. Contact Form 7 expects a sender address in the website’s domain.
Make one controlled change at a time and retest. If multiple forms exist, confirm you edited the form used on the affected public page. A correctly configured test form does not establish that the client’s enquiry form uses the same settings.
3. Trace the message beyond WordPress
Check your actual mail transport: the host’s mail service or the configured SMTP/API mail provider. Review its logs around the recorded test time for an accepted message, an error, a rejection or a later bounce. Verify credentials and sender authorization in the provider’s own dashboard before replacing them.
Then check the destination mailbox, spam folder and any business quarantine. Ask the mailbox administrator to inspect filtering when appropriate. Avoid repeatedly resubmitting without a reference; several similar messages make a single test difficult to follow.
WordPress documents that a successful wp_mail() result means processing did not report an error, not that the recipient received the email. That distinction explains why a WordPress-side success and a missing message can coexist.
4. Retest the same journey and keep a record
After a fix, submit through the original public page again. Verify the browser response and receipt at the intended recipient. Record what changed and the time you confirmed recovery. Check downstream CRM or automation effects and remove labelled test records according to the client’s process.
For recurring checks, LensShift can monitor a configured Contact Form 7 enquiry form. It records browser submission and a matching monitoring copy separately. An actionable failed check receives a confirmation run before an incident opens; a complete pass records recovery.
What a pass means: the configured browser submission succeeded and a matching email reached LensShift’s monitoring mailbox. It does not prove delivery to your client’s normal inbox, cover every visitor journey, or guarantee continuous uptime.
Before closing the support ticket
- The original public form submits with the expected values.
- The client’s normal recipient has independently confirmed receipt.
- Mail configuration warnings and relevant provider errors have been reviewed.
- Your monitoring check passes, or any unsupported behavior is documented.
- The client knows how test enquiries will appear in their workflow.