A green success message proves only what the browser was told to display. It does not prove that the server stored the enquiry, the mail provider accepted the notification, the recipient mailbox delivered it, or the CRM created a lead. Diagnose the chain from the visitor outward.
Six states to check
| State | Evidence | Common failure |
|---|---|---|
| Browser submitted | Network request and response status | JavaScript shows success before awaiting the response |
| Server accepted | Request ID and validated payload | Validation or rate limiting rejects the request |
| Enquiry persisted | Database, queue, or durable event ID | Email is the only copy and sending fails |
| Notification sent | Provider message ID and delivery event | Sender authentication or provider rejection |
| Mailbox received | Inbox, spam, quarantine, routing log | Filtering, forwarding, full mailbox |
| CRM recorded | Lead ID and assignment | Integration mapping or permission failure |
Forms send data to a server endpoint; the HTML interface alone does not deliver an email. MDN’s form guide makes this client/server boundary explicit.
Reproduce with a traceable test
Use a synthetic enquiry that contains no personal data, such as FORM-QA-20260812-01. Record the time, page URL, environment, consent state, and browser. Then:
- inspect the request URL, method, status, and returned request ID;
- confirm the server stored or queued the same test ID;
- locate the mail provider event and message ID;
- check inbox, spam, quarantine, aliases, and forwarding;
- confirm the CRM record and assignment rule;
- compare the analytics event with the server’s accepted count.
Do not place real customer details in screenshots or issue trackers. Redact addresses, message bodies, tokens, and provider credentials.
Fix the success contract
The browser should say “sent” only after the system reaches the state promised to the user. A safe pattern is:
- server validates and durably accepts the enquiry;
- server returns a request ID;
- notification runs asynchronously;
- delivery failures alert the operator and can be retried;
- the user sees an honest confirmation and a fallback contact route.
If the business cannot store messages, the confirmation must not imply guaranteed staff receipt. State that submission was accepted and provide a response window and alternative channel.
Email authentication is only one layer
SPF defines which servers may send for a domain, but a valid SPF result does not guarantee inbox placement. Check DKIM, DMARC, sender alignment, provider suppression lists, recipient filtering, and mailbox routing using the current provider documentation. Avoid changing DNS records blindly: an incorrect record can affect every sender using the domain.
Measure without inflating conversions
Track at least two separate events:
form_submit_attemptwhen the visitor initiates submission;form_submit_acceptedonly after the server accepts it.
Operationally compare accepted requests, persisted enquiries, notification deliveries, and CRM leads. Analytics is useful for funnels, but the server or CRM should be the source of truth for received enquiries.
The form is fixed when a test can be traced end to end, failures are observable, and staff have a recovery path—not when one test email happens to arrive.
Need a clearer first step for your website?
Start with the situation and outcome. We will help define the scope and next step.