Key takeaways
- Confirm whether the form stored the enquiry before troubleshooting the inbox.
- A PHP mail success response does not guarantee email delivery.
- Verify the sender domain, SPF and DKIM records and your outbound mail provider.
- Use a controlled test and read the provider logs; never collect passwords in enquiry forms.
A successful form submission and a delivered email are two different results. This checklist helps you find where the notification actually stops.
First separate a lost enquiry from a lost notification
A form can save a lead correctly while the notification never reaches its recipient. The opposite is also possible: an email may appear while the website fails to retain a submission record. Before changing plugins, send one clearly labelled test enquiry and check three places independently: the success message in the browser, the form entries or database, and the recipient inbox. If the entry exists but no email arrives, focus on delivery rather than rebuilding the page.
- Use a unique subject such as Test enquiry 2026-10-30 so you can trace it.
- Confirm the form action and server response, including validation or 403/500 failures.
- Check the form-entry dashboard and each configured notification recipient.
Check the WordPress and server mail path
Many WordPress forms call wp_mail(), which depends on the server mail configuration or a configured mail transport plugin. An application-level success flag only shows that the request was accepted at some stage, not that a receiving mailbox delivered it. Hosting accounts may restrict outbound mail or use shared server IPs with uneven email reputations. Test server mail separately from form validation and check any mail queue, PHP logs or host mail logs you are allowed to access.
- Confirm the form plugin notification is enabled and the recipient address is correct.
- Make sure the sender uses an address authorized for the configured sending domain.
- Ask your host whether local PHP mail is supported or blocked.
Verify sender authentication and delivery reports
Modern mail providers use domain authentication and reputation to decide whether they trust a message. Check SPF and DKIM according to your email service provider, and review DMARC alignment where applicable. Do not guess DNS values from another hosting company; copy the exact records issued for your verified sending domain. After DNS changes propagate, send a fresh test and inspect the email provider event log for accepted, delivered, delayed, bounced or rejected status.
- Use a domain you own and have verified with the sender service.
- Check both inboxes if you have primary and secondary notifications configured.
- Read junk and quarantine folders, then inspect provider logs to locate the actual failure.
Choose a reliable transport and failure experience
A supported mail API or authenticated SMTP relay can be more observable than basic PHP mail because it returns a provider response and delivery events. There is no universal requirement to use SMTP specifically; an HTTPS email API is a valid alternative when your hosting environment allows outbound requests. Whichever route you choose, build a clear failure mode: store the enquiry securely, show a truthful response and expose a separate way to contact the business if delivery is unavailable.
- Use server-side request timeouts and avoid retry loops that send duplicates.
- Record the provider message identifier without logging the full customer message publicly.
- Test a real enquiry after deploying, not only a simulated local success.
Protect the form and the personal data it collects
Contact forms should validate expected input types on the server, protect against cross-site requests where relevant, rate-limit abusive traffic and avoid reflecting unsanitized content. Use consent and a clear privacy statement appropriate to the enquiry. Administrators should be able to remove submissions when required and restrict access to stored leads. Anti-spam controls can reduce noise, but ensure legitimate users can still submit from phones and keyboard navigation.
- Check required labels, error messages and focus handling.
- Test one valid, one invalid and one interrupted request.
- Do not send form submissions to arbitrary third-party addresses.
A short go-live test before trusting the contact page
Complete the same journey a prospective customer would follow: open the contact page on a phone, choose the service, fill valid details, submit once and confirm the browser message, saved record and delivery to the authorized recipients. Check the form in a private browser window so you are not accidentally relying on administrator authentication. Record any errors with a timestamp and request ID, then test again after a fix. For custom WordPress forms, see the site’s services for forms and integration troubleshooting.
- Check one real message to every configured inbox.
- Verify the server and delivery-provider events.
- Review the /services/forms-integrations service for a broader implementation approach.
Have something like this in mind?
Good development starts with understanding the site, the people using it and the decisions that matter after launch.
Discuss a WordPress form or email issue
