Your form says “sent”: how to verify the enquiry arrived

To check whether a website enquiry actually arrived, trace one labelled test from the browser to the system that stores it, then to the destination mailbox. The “Sent” message, server response, saved record and notification email are separate checkpoints. One successful checkpoint does not establish the others.

This method is useful for a service business receiving appointment requests or quote enquiries. It helps locate a break in the process before you replace a plugin, change DNS settings or rebuild the form. It does not assume that your website has a fault.

When is this check useful?

A visitor says they contacted you, but your team cannot find the request. Submissions appear in the administration screen, but notification emails are missing. Or an analytics report counts form submissions without a matching list of enquiries. Start with the available records: these situations can have different explanations.

GA4’s form_submit event records a form submission. It does not certify that your application saved it, that an email arrived or that the enquiry is a qualified lead. Google describes the trigger in its enhanced measurement documentation. A received enquiry, a qualified lead and a sale remain different business outcomes.

Prepare the access and a test without client information

First identify the intended destination: an administration screen, database, CRM, mailbox or a combination. Do not assume that your form stores submissions. Check the actual configuration and available features.

• Arrange access to the test form, application logs and submission register.
• Use a local mail capture or a mailbox your organisation controls and authorises for the test. Check automatic acknowledgements too: a test must not email a real client.
• If the public journey must be tested, obtain approval for that test and its recipients. Use a sandbox for deliberate failure scenarios.
• Record the form, language, device, browser and timestamp with its time zone. Put a synthetic marker, such as TEST-FORM-01, in a suitable field.

Browser network tools and the local demonstration below require no purchase. In a real installation, log access, retention and some form or email features may depend on the existing subscription. Check what is included before buying another tool. A technical colleague may be needed to connect the records.

1. Check the request the browser actually sent

Before submitting, open the browser’s developer tools and select the Network panel. Send one clearly labelled test. Find the form request and record its method, path, HTTP status and the result in the response body. Keep the returned submission identifier, if one is available.

If no request appears, inspect field validation and browser errors first. A 4xx or 5xx response needs to be matched to the relevant application logs; the status alone does not identify the cause. Even a 2xx result must be interpreted according to the API’s contract. In particular, 202 Accepted means that processing has been accepted but is not complete, as defined in RFC 9110, section 15.3.3. Follow the application’s documented process to obtain the final status.

A redacted record of the status, timestamp and identifier is often enough for the investigation. Do not share an unchecked network archive: it may contain cookies, tokens and personal information.

2. Find the saved enquiry in its intended system

Search the authorised administration screen or register using the same identifier or marker. Reload the view or reopen the record to check that it was retained. Compare the relevant fields, language and assigned team with the expected values. A positive HTTP response is not a substitute for this check.

If the form relies entirely on email, record “no independent submission register configured”. That is a diagnostic limitation, not proof that an enquiry was lost. If you cannot access the storage system, record “saved record not verified”. Establish the expected behaviour before proposing a fix.

3. Trace the notification separately

Match the submission ID to the email message ID and event timestamps. Identify the last confirmed state: accepted for processing, pending, failed or handed to the receiving mail server. Read the details and reason for a rejection before changing sender or domain settings.

Provider terminology varies. For example, SendGrid’s processed event means it accepted the message; delivered means it handed the message to the receiving server; deferred indicates a temporary delay. None of these means that a person read it. Check the definitions in the SendGrid Event Webhook reference or your own provider’s documentation.

For a WordPress form that uses wp_mail(), a true result does not establish delivery to the recipient. The official WordPress reference makes this limitation explicit. This does not mean that every WordPress form uses the same sending mechanism.

An enquiry can be saved even when its notification fails. Check the register before asking the visitor to submit again. Where supported, retry the notification associated with the existing record to avoid creating another enquiry.

4. Confirm the destination mailbox

In the authorised mailbox, search for the test marker in received messages and junk folders. Check filing rules, shared mailboxes and quarantine with the mail administrator when necessary. A provider’s “delivered” event does not prove placement in the main inbox or that someone has read the email.

For Microsoft 365, Exchange Online message trace can add evidence about receipt, rejection, deferral and filtering actions. Appropriate permissions are required. Compare timestamps in the same time zone before treating a time difference as a missing event.

5. Record the last confirmed step, then repeat the test

Keep a short record that the person maintaining the website can act on:

• Test: marker, environment, URL, language, device and timestamp with time zone.
• Browser: displayed message, HTTP status and returned identifier.
• Enquiry: record rechecked, fields matched or saved record not verified.
• Notification: internal reference, precise state and latest evidence inspected.
• Mailbox: message found, absent or mailbox not checked.
• Next step: last confirmed checkpoint, targeted fix, owner and retest result.

Illustrative example: a professional services firm finds TEST-FORM-01 in its administration screen with the correct fields. The notification logs show a failure, and no message is captured. The confirmed problem concerns notification. This does not establish that the entire form loses enquiries, or identify a specific SMTP fix without the failure reason.

After the authorised correction, run another test with a new marker. Include the languages and form variants your visitors actually use. Our user acceptance testing grid can help the team agree on pass criteria. A later transfer to a CRM is another step, covered in the ERP and CRM integration guide.

What we tested in an isolated demonstration

On October 25, 2026, a local demonstration used Python 3.9.6, an HTTP server on the same computer, a temporary SQLite file and an in-memory notification capture. Four synthetic submissions produced the expected results:

1. Success: HTTP 201, one enquiry read back through a new database connection and one notification captured locally.
2. Notification failure: HTTP 201, one retained enquiry and no captured notification.
3. Simulated false success: an interface success flag despite HTTP 500 and no stored record.
4. Acceptance only: HTTP 202 with no saved record in this deliberately incomplete scenario. This does not mean that all applications returning 202 omit storage.

All checks passed: four requests, two records read back and one local capture. No external email was sent. The interface flag was simulated; the demonstration did not test a real browser, WordPress, SMTP, an actual mailbox or GA4. It did not test crash recovery or measure performance. It demonstrates how to distinguish evidence, not the reliability of any production form.

Common mistakes and a final checklist

Avoid repeated unlabelled tests, changing several settings at once and sending enquiry content to Analytics. Receiving a message in one test mailbox does not guarantee the same result for every domain or recipient. Preserve consent and anti-spam controls; a delivery test is not a reason to remove them.

• The test has a unique marker and timestamp with time zone.
• The server response has been inspected.
• The enquiry has been read back from its intended destination, or that limitation is recorded.
• The notification has been traced separately.
• The controlled mailbox and relevant filters have been checked.
• The result, limitations and next action are written down.

If your team needs a more dependable enquiry journey, our website design service for Greater Montréal businesses can help define the website and form requirements. A retrievable enquiry and a clear follow-up process are practical acceptance criteria to discuss.

Technical sources checked on October 25, 2026.