If your contact form says “sent” but no email arrives, first establish whether the website accepted and kept the enquiry. Then trace the notification separately. The screen message, a saved request, an email service accepting a send request and a colleague seeing the message are different events.

That distinction changes what you need to fix. A mailbox rule may be hiding a recoverable enquiry. A form may be showing success after a server error. Or an integration may have accepted the message without creating the CRM record your team expects. Replacing the form design before locating the break can leave the real problem untouched.

Follow one test enquiry from end to end

Use a clearly marked test message and a contact address you control. Record the page URL, language, device, exact time and the result shown on screen. Let the person who handles enquiries know you are testing. You need a traceable example, not several near-identical submissions that everyone later has to untangle.

Ask the website maintainer to find the same test in each relevant system. Where the application provides a request identifier, use it to connect the records. If a record is absent, note that rather than assuming the previous step completed.

Work through these branches:

  • No accepted request can be found: investigate the form's submission, validation and server response. The problem may occur before email is involved.
  • A saved request exists, but no email send attempt appears: inspect the notification configuration, destination and the connection between storage and sending.
  • The email service records an attempt: inspect its status and the receiving mailbox, including spam, quarantine, filters and forwarding.
  • The email arrives, but the CRM is empty: inspect the CRM connection and the rule that should create or update the record.
  • The record exists, but nobody responds: check assignment, access and the team's follow-up process.

Not every form saves submissions. Confirm what your particular implementation keeps and for how long. If nothing was retained, a successful test today cannot reconstruct earlier missing messages or establish how many there were.

Read “sent” and “delivered” carefully

Start with the configured recipient: is it the current, monitored address, or an old employee's mailbox? Search the whole mailbox for the test and inspect filtering rules. Then ask the maintainer for the email provider's event, not only a screenshot of the website's thank-you message.

For example, Resend distinguishes a successful sending API request from delivery to the recipient's mail server. It also records delayed delivery, permanent rejection and sending failures. Even acceptance by the receiving server does not establish that a colleague saw the message. Resend's event definitions.

Use the recorded error to choose the next investigation. A rejected destination, a sending configuration problem and a temporary delivery delay call for different actions. Check the provider's current account and domain requirements before changing settings; Resend, for example, requires a verified sending domain for sending from that domain. Resend's sending guidance.

Avoid changing several mail settings at once. Keep the original test details, record one change and repeat the test. Otherwise, a message arriving after a bundle of changes tells you little about which repair mattered.

Decide what should survive a notification failure

For a business that depends on website enquiries, I would normally ask for a durable record before the application confirms acceptance. That could be the form platform's submissions area, a database or a CRM, provided the team can actually retrieve it. The email notification then alerts someone to work that is already recorded.

The brief needs more than “save to database”. Agree who can read the record, where failed notifications appear, who checks them and how long records remain available. If CRM delivery happens later, retain enough status to distinguish “received by the website” from “available to the sales team”. A saved record that nobody can access is a poor fallback.

Also separate the business notification from any courtesy email to the visitor. In this website's contact handler, those are separate operations: if the email service accepts the business notification but the visitor's confirmation fails, the form does not ask the visitor to submit everything again. That is a specific error-handling choice; it is not proof of inbox delivery or a claim that all storage and recovery arrangements are identical across my products.

My MarciCRM work brings property enquiries, conversations, appointments and follow-up together. The relevant principle here is that a request needs an owner and a next action. It does not mean every small website needs a custom CRM; a usable submissions log and a monitored inbox may be enough.

Make retries safe and confirmations honest

A slow connection can leave a visitor unsure whether the first attempt worked. Ask the developer how the system recognises a retry of the same submission, and how it distinguishes a genuinely new enquiry. Repeated clicks should not silently create several sales tasks or notification emails for one request.

Email providers may offer part of this protection. Resend's idempotency keys allow the same send request to be retried without sending it again within a 24-hour retention window. That does not, by itself, deduplicate your website's database or CRM records. Resend's idempotency documentation.

The browser must also interpret the server response correctly. A JavaScript fetch() call can return a response even when the server reports an HTTP error, so the application has to check the result before showing success. MDN's Fetch guidance.

Write messages around what the application can confirm. If the request was not accepted, preserve the visitor's text where possible and explain how to retry or use another contact route. If it was accepted but a courtesy confirmation is unavailable, do not imply that the whole request disappeared. Error feedback should be understandable and accessible, following W3C's form-notification guidance.

Put these failure cases in the handover test

A single successful submission proves only that one route worked at that moment. Ask the developer to reproduce failures in a controlled test environment, then verify the ordinary journey on the published site. For each case, record the visitor's message, the stored or accepted request, the notification status and the action available to the responsible person.

  • Normal submission: the expected request and notification appear, with the correct language and destination.
  • Rejected input: the visitor receives a useful correction and the system does not report a successful enquiry.
  • Storage or acceptance failure: the interface does not claim that the business received a request it failed to accept.
  • Notification failure after storage: the record remains retrievable and the failure becomes visible to its owner.
  • Uncertain response followed by a retry: the same attempt does not become duplicate records, emails or follow-up tasks.
  • Visitor-confirmation failure: it is handled separately from the business's receipt of the enquiry.
  • CRM interruption, if connected: the pending transfer can be found and recovered without asking the visitor to re-enter the enquiry.

These are proposed acceptance tests, not claims that every platform offers all these features automatically. If an option cannot meet one, make the limitation and the operating workaround explicit before approving it.

For what to ask visitors, use the separate form-field guide. For how advertising should count accepted and qualified enquiries, use the conversion-goal guide. This test concerns whether the request reaches a usable business process.

Buy the repair that the evidence supports

Ask for a short diagnosis before a rebuild proposal. It should identify the failed step, show the evidence from the test and explain whether earlier requests are recoverable from retained records. Then separate the immediate repair from any improvement to storage, retries, monitoring or CRM integration.

A useful handover includes the destination of enquiries, the person responsible, the place to check failed processing, a repeatable test and instructions for a future maintainer. Monitoring should not depend solely on the same email route it is meant to detect failing. Agree on a practical check after changes to the website, email provider or connected tools, and on who investigates failures.

Once the flow works, you can assess whether the page attracts suitable enquiries and whether more traffic is worthwhile. An email delivery repair alone cannot establish a conversion-rate improvement, recover unrecorded history or guarantee that every future message will arrive.

If a form shows success but enquiries are missing, send me the page URL, when you last tested it and what you saw through the contact page, or email hello@davidbuka.com. Leave customer messages and account credentials out of the initial description. I can review the website, notification and follow-up connection and scope the repair.

Primary references checked on 24 October 2026. The cover is an original editorial illustration of a retained message and a separate notification, not client correspondence.