Your Website Says “Message Sent.” Did the Quote Request Arrive?
A customer sees “Thanks, we received your request.” The owner checks the inbox and finds nothing. Both experiences can happen on the same day. A successful web form submission, a successful handoff to a mail system, and a message that reaches the inbox are three different checkpoints. Run this test any time you replace a […]
A customer sees “Thanks, we received your request.” The owner checks the inbox and finds nothing. Both experiences can happen on the same day. A successful web form submission, a successful handoff to a mail system, and a message that reaches the inbox are three different checkpoints.
Run this test any time you replace a form, move hosts, switch mailbox providers, or change who receives quote requests. Use your own test contact details and avoid entering payment details or other sensitive information.
Test the public path a customer actually uses
Start in a private browser window or a browser where you are signed out of the site. Open the service page your customers use, follow its quote button, and submit the form from a phone. Include an easy-to-find test reference in the message such as FORM-TEST-1106-A. Write down the time, page URL and the exact success or error message. Label the inquiry as a test before anyone counts it as a lead.
Have someone with access to the authorized business inbox search for that reference in inbox, junk and any quarantine tool they normally use. Check shared mailboxes and routing rules if needed. If the form is also supposed to notify a second staff member, test that destination. Finally, reply to the notification and verify that the reply actually reaches your test address. Check any customer confirmation email separately.
Use the first missing checkpoint to narrow the problem
| What you see | Where to look next | Proof of the fix |
|---|---|---|
| No success message or saved entry | Required fields, form errors, spam protection, device or connection | Repeat the public test and confirm the intended result. |
| Saved entry, no mail in the sending log | Notification rules, recipient address and the site’s sending configuration | Locate the test message in the authorized sender’s log or get a confirmed handoff. |
| Sent or accepted, no inbox message | Mail provider delivery status, bounce, quarantine or routing rules | Find the message in the expected mailbox and confirm the destination. |
| Message arrives, but Reply goes elsewhere | The Reply-To address used by the notification template | Reply to a fresh test and confirm receipt in the test customer’s inbox. |
If your form intentionally does not store entries, “no saved entry” is not evidence of failure. Use the authorized sending log or inbox to find the next checkpoint. WordPress’s mail function documentation makes a similar distinction: accepting a message for processing does not establish that the intended person received it.
Check the sender and the reply address separately
For a typical notification, use an address your mail service authorizes for the From field. Put the visitor’s email in Reply-To if your form supports it. That lets staff answer the visitor without asking your website to send mail as a stranger’s address. Have whoever manages your email verify the expected sender and authentication settings; avoid replacing DNS records or adding another mail plugin as a first guess.
Give the recipient a fallback. If your form stores entries, document who checks that queue when delivery fails and how long entries are retained. If it doesn’t, decide what customer contact option the site should offer when the form is unavailable. Give weekend or vacation coverage a named owner.
Try the paths most likely to differ
A single test confirms the path you used, at that moment. If the form lets someone choose “service” or “billing,” test both. If a campaign uses a shorter form or a booking tool, test the exact landing page instead of using the general contact form as a proxy. Test the mobile path and the desktop path if they use different forms. If file uploads are required, use a harmless sample file of an allowed type and size.
When a test fails intermittently, repeat it with a fresh reference and log the inputs that changed: route, device, time and whether an attachment was included. Share the test reference and timestamp with the person investigating, rather than sending a customer’s submission around by email. If a marketing report suddenly shows many form events but inbox volume is unchanged, check whether the analytics event fires on button click or only after the server accepts the form. Neither measurement proves an email was delivered.
Keep one short test record
Save the page, device, time, reference, inbox, reply result and owner. Record the result as pass, fail, or unverified at each checkpoint. If you make a fix, send a new test reference and save the before and after results. If analytics records submissions, keep the test out of customer reporting where your setup allows it and do not use the event as proof of receipt.
When the delivery path is working, use the contact page usability review to improve the form itself and the inquiry handoff guide to decide what happens after the message arrives.