Business guide
Contact form says sent, but no email arrives? Trace the enquiry properly
Find where a website enquiry fails: browser submission, server processing, sending-provider acceptance or delivery to the business inbox.
A success message does not prove inbox delivery
Your customer fills in the form, sees "sent" and expects someone to respond. The email notification may still fail later. There are several stages between the button and your inbox: the browser submits the request, the website processes it, a sending service accepts a message and the receiving mail system handles it. Diagnose those stages separately.
Use a labelled test submission containing no sensitive customer information. Record its time, the page used and a unique reference such as FORM-TEST-24. Ask the person investigating to follow that reference through the available records. Repeatedly submitting unlabelled messages makes it harder to tell which attempt actually worked.
Check whether the website received and accepted it
If the form reports an error or never finishes, begin with the website request. A developer can inspect the server response and relevant application logs. Missing required fields, validation errors, an unavailable endpoint or an incorrect production configuration can stop processing before any email is attempted. The exact fix depends on the form platform.
If the website displays success, confirm what that status means in the implementation. It may mean a request was accepted for processing rather than that a notification was delivered. If an anti-spam honeypot intentionally discards the submission, it should not be counted as a genuine delivered lead. Do not change your reporting to hide this distinction.
For WordPress, identify the form plugin and the separate mail-sending arrangement. In Contact Form 7, review the Mail tab recipient and sender configuration. In WPForms, check the notification is enabled, its destination is correct and any conditional rule applies to the test. An on-screen confirmation and an email notification are separate parts of the workflow.
Check the sending service and the intended recipient
Ask whether the application recorded a send attempt, which recipient it used and what response came back. Check for a misspelled inbox, a disabled notification rule or a sender domain that is not authorised in the chosen email service. Keep credentials private while checking their presence and permissions.
Use the sending provider’s message record where available. In Resend, email.sent means the API request succeeded and delivery will be attempted; email.delivered means the recipient’s mail server accepted it, not that a person read it or that it landed in the inbox. Delayed, bounced and failed events identify different problems. Follow the specific event rather than changing unrelated DNS records.
- Submit
The browser sends the form with a unique test reference.
- Process
The website validates and handles the request.
- Send
The email provider records acceptance or a specific error.
- Receive
The destination system accepts, rejects or filters the message.
Check the inbox, spam and receiving-side rules
Search the mailbox for the exact test reference, including spam and any quarantine or admin logs available. Check forwarding rules, aliases and group restrictions. Compare delivery to another approved test destination if that helps isolate the fault, without forwarding live customer information to personal accounts.
Google Workspace documents form-delivery problems where the sending arrangement needs attention, including authentication. Have the website provider and email administrator work from the same test details. A vague "email is broken" message gives them less to investigate than a timestamp, destination and sending-provider record.
If some destinations receive the message but Gmail does not, compare the sender records and Gmail filtering evidence. For Microsoft 365, ask the authorised administrator to use Exchange Online message trace. Investigate the particular destination rather than replacing the entire form because one mailbox behaves differently.
Verify the fix with the receiving person
After a change, repeat the complete test and have the actual recipient confirm arrival and a successful reply. Check mobile submission too. Keep a minimal record of the result and decide who will notice future delivery failures. If enquiries are also saved in an approved business system, make sure someone reviews that queue rather than assuming email is the only record.
My website maintenance work can investigate this journey from submission to receipt. First we establish where it breaks, then fix that part and repeat the test. Use the delivery guide for messages arriving in spam and the abuse guide for automated junk: they address different causes.