Contact Form Submits but Email Never Arrives? Find the Failure Point

A contact form can display “Message sent” while the business receives nothing.

That is one of the more dangerous website failures because the page still looks healthy. Visitors may keep submitting enquiries. The owner may simply assume demand has slowed down.

If this is happening, do not begin by redesigning the contact page or changing the call to action. First trace the enquiry through the system.

The useful model is:

visitor submits → browser sends request → backend accepts it → enquiry is stored → notification is sent → email provider accepts it → receiving inbox accepts it → the right person sees it

The first broken boundary is the problem.

First, prove whether the form actually submitted

Open the live website rather than a local preview. Use the form as a customer would, preferably from a phone and with an email address outside your own domain.

Record what happens after you press Send:

• Does the button respond?
• Does validation reject a legitimate phone number or email address?
• Does a spinner run forever?
• Does the page show a success message immediately?
• Does the browser redirect to a thank-you page?
• Does an error appear only on mobile?

For a deeper check, open the browser’s Network panel and submit again. MDN’s form documentation explains that browser developer tools let you inspect the request and submitted payload: https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Sending_and_retrieving_form_data

You are trying to answer one question: did the browser actually send the request to the expected endpoint, and what response came back?

A polished success animation is not evidence of delivery if the frontend shows it before the server confirms the operation.

Separate lead capture from email notification

This is the architectural decision that prevents many silent losses.

For a commercially important enquiry form, I prefer this sequence where the stack allows it:

1. validate the submission on the server
2. save the enquiry durably
3. return a genuine success state
4. trigger notification email, CRM, Slack or other workflows
5. log whether those downstream notifications succeeded

That way, a temporary email failure does not automatically destroy the lead.

If the only thing the form does is call an email function, then a delivery problem can become a data-loss problem.

This matters especially for businesses where one enquiry could become a consulting engagement, property sale, hotel booking, admission, legal matter or substantial project. Email should be a notification channel, not necessarily the only database.

If the backend has the enquiry, stop blaming the form

Suppose your database, CMS or form provider contains the test submission, but no notification appears in the inbox.

The customer-facing form has done its main job. Now trace the mail layer.

Check:

• the configured recipient address
• the sender address
• provider/API logs
• whether the provider accepted or rejected the send request
• bounce or suppression status
• spam and junk folders
• forwarding rules
• mailbox rules
• whether the receiving mailbox still exists
• whether a recent domain or DNS change affected authentication

Modern transactional-email services expose logs precisely because “the API call ran” and “the human received the message” are different states. Resend, for example, documents detailed API logs and domain authentication using SPF and DKIM: https://resend.com/features/email-api and https://resend.com/

The same principle applies whichever reputable provider your website uses.

Do not spoof the visitor as the sender

A common form configuration tries to send the notification from the visitor’s email address so that it looks as if the visitor emailed the business directly.

That is usually the wrong mental model.

Your website’s mail service is not authorized to send mail on behalf of every Gmail, Outlook or company domain entered into a form field.

A cleaner pattern is:

• send from an authenticated address on a domain you control
• send to the business inbox
• set the visitor’s address as the reply-to value where appropriate

Then replying can still go to the visitor without pretending your server is their mail provider.

If your email service requires domain verification, complete it correctly. Resend’s current documentation describes SPF and DKIM as part of proving legitimate sender identity, and its domain setup uses DNS records for sending authentication. https://resend.com/blog/email-authentication-a-developers-guide

A 200 response is not the same as a delivered lead

This distinction is worth making explicit.

Your form endpoint can return a successful HTTP response because it accepted the submission. The email provider can separately accept a notification request. The receiving mail server can then accept, filter, defer or reject the message.

Those are different boundaries.

So when someone says, “The form works,” ask what they mean:

• The button works?
• The HTTP request succeeds?
• The submission is stored?
• The provider accepted the email?
• The inbox received it?
• The sales team saw it?

Until you know which statement is true, you are still guessing.

Check what changed just before enquiries disappeared

When a previously healthy form suddenly goes quiet, look for a recent change before rebuilding anything.

Useful suspects include:

• a new deployment
• a changed environment variable
• expired API credentials
• a changed recipient address
• DNS changes
• a new spam-protection rule
• a disconnected CRM or webhook
• a CMS/plugin update
• a form field renamed in the frontend but not the backend
• a new validation rule
• an email-provider quota or suppression event

The timing often narrows the investigation faster than staring at the form design.

Test the business outcome, not just the component

A developer can test that the form component submits and still miss the real failure.

The production test should follow the same journey as a customer:

open live page → complete form → submit → see accurate confirmation → verify durable record → verify notification → verify inbox/CRM destination → verify reply path

I use this boundary-by-boundary way of thinking across websites and MVPs because failures often happen between systems rather than inside the visible screen.

It is the same reason payment systems should distinguish “checkout opened,” “provider confirmed payment” and “customer access changed.” A green UI state is not the same as a completed business process.

Track submissions separately from button clicks

Analytics can also create false confidence.

If your conversion event fires when someone clicks Send, you may count a lead even when validation or the server request fails afterward.

Prefer tracking the meaningful success state: a confirmed server-side submission, a thank-you state reached only after acceptance, or another event tied to actual lead capture.

Then compare three numbers over time:

1. people who reach the enquiry step
2. successful submissions
3. leads that reach the business’s working destination

A large gap between 1 and 2 suggests conversion or technical friction. A gap between 2 and 3 suggests routing, notification or operational failure.

If your broader problem is traffic without enquiries rather than a technically broken form, use my guide on why a website gets traffic but no sales to diagnose the offer, trust and conversion journey separately.

When the form needs improvement rather than repair

Sometimes the system works end to end and people simply do not submit it.

That is a different problem.

Then review whether the form:

• asks for information you do not yet need
• explains what happens next
• gives a realistic response timeframe
• works comfortably on mobile
• has useful proof nearby
• matches the visitor’s buying stage
• offers the right alternative contact method

Do not confuse zero submissions because nobody wants to complete the form with missing enquiries because the delivery pipeline is broken. They require different fixes.

Build contact forms as revenue infrastructure

A business website is not finished because the contact page looks good.

The enquiry path is infrastructure. It deserves server-side validation, durable capture where appropriate, observable delivery, clear failure states and periodic production testing.

If you suspect your website is silently losing enquiries, I can audit the complete path rather than changing the design blindly. See my web design service or contact me with the page URL and what you currently observe.

The useful question is not “Does the form look like it works?”

It is “Can we prove where every serious enquiry goes after the customer presses Send?”