Form not sending e-mails: where the problem usually is

A website form can look completely functional: the fields fill in, the button responds, a “sent” message appears. But the e-mail never reaches the owner. For a business, that is more dangerous than a visible error. When a form shows a red warning, at least the problem gets noticed. When everything looks successful, enquiries can go missing for weeks.

The problem is not always the form itself. More often, the delivery chain breaks somewhere along the way: the site received the data, but the e-mail never made it through the server, the SMTP, the DNS, the spam filter, or the recipient’s inbox. So the right question is not “why doesn’t the form work”, but “at which stage does the enquiry disappear”.

Why this affects any website

This is not a problem specific to one CMS, one plugin, or one platform. The same situation can happen on a site with a custom-built form, on an old CMS, on a website builder, on an online shop, on a landing page, or on a booking form.

The only difference is where the visibility sits. On some sites you can check the sending log, the saved enquiries and the SMTP settings. On others, the owner only sees the visual editor and the e-mail in their inbox. That is why diagnosis always starts with understanding the platform: what the site actually stores, how it sends e-mails, and whether there is any technical trace of the enquiry to look at.

Google’s own Workspace documentation notes that the form itself is usually not the main cause. The problem is more often how the message is sent and verified by the mail system: SPF, SMTP relay, DKIM and sender settings. That is an important point. The “Send” button can work perfectly, and the mail provider can still reject the e-mail as suspicious.

Where the chain breaks most often

An enquiry goes through several stages.

1. The client fills in the form.
2. The site checks the fields and spam protection.
3. The site builds the e-mail.
4. The server or SMTP service tries to send it.
5. The domain’s DNS records confirm the sender is allowed to send this e-mail.
6. Gmail, Outlook or another mail service checks the message.
7. The e-mail lands in the inbox, in spam, or gets rejected.
8. If the site has enquiry storage switched on, a record stays in the admin area, the database, or a CRM.

Each stage can fail in its own way.

The most common causes:

• the form sends the e-mail through plain PHP mail with no proper authentication
• SMTP is not configured, or the SMTP password has changed
• From is set to the client’s e-mail instead of the site’s domain address
• Reply-To is not configured, so replies do not go to the client
• SPF does not include the server or service that actually sends the e-mail
• DKIM is not enabled, or broke after a mail migration
• DMARC is too strict for the current sending setup
• the e-mail looks like spoofing, meaning a faked sender address
• the mailbox is full, or a filter is routing messages to spam
• the captcha or anti-spam tool is blocking genuine clients
• caching or an optimisation setting interferes with the form submission
• after an update, the fields, the e-mail template or the form endpoint changed
• the site does not store enquiries, so a lost e-mail cannot be recovered

Why From and Reply-To matter so much

One of the most common mistakes is sending the e-mail as if it came directly from the client.

For example, the client enters client@gmail.com, and the site tries to send the e-mail from its own server with a From header of client@gmail.com. To a mail service, that looks suspicious: the e-mail is not coming from Gmail’s servers, yet claims to be from Gmail. That is exactly how spoofing risk, spam filtering, or outright rejection happens.

The better approach is:

• From: a technical address on the site’s own domain, such as no-reply@domain.co.uk or contact@domain.co.uk
• Reply-To: the client’s e-mail address from the form
• To: the owner’s or sales team’s working address

With that setup, the mail system sees a coherent picture: the site is sending a service e-mail from its own domain, and the owner can hit Reply and write straight back to the client. This does not fix everything automatically, but it removes one of the most common causes of blocking.

Why SMTP usually beats sending straight from hosting

An ordinary website is not meant to be a full mail system. Hosting is good at serving pages, but not always good at sending e-mail. On shared hosting there can be limits, a poor IP reputation, blocked ports, or sending caps.

SMTP solves part of that problem. The site connects to a mail service with a login and password, or via an API, and the e-mail goes out through a system built for delivery. That could be domain mail, Google Workspace, Microsoft 365, SendGrid, Mailgun, Brevo, Postmark, or another service.

But SMTP also needs to be set up correctly:

• choose the right port and encryption type
• check the login and password
• configure the sender address
• add SPF, DKIM and DMARC where needed
• send a test e-mail
• check delivery to Gmail, Outlook and the domain mailbox
• check whether the e-mail lands in spam

Simply installing an SMTP plugin or module without checking the result can leave the problem in place. The owner will see “sent successfully” while the mail system keeps filtering the messages.

It helps a lot when enquiries are also saved on the site

The ideal setup: an enquiry is not only sent by e-mail, but also saved on the site, in a database, a CRM, or a dedicated log. Then, if the e-mail lands in spam or gets rejected, opening the admin area still shows that the client did get in touch.

That matters especially for a business running ads, taking bookings, or receiving expensive leads. If the click has already been paid for, a lost form submission is not a technical detail; it is money lost directly.

But it is worth being honest: this is not set up on every site, and it is not always easy to switch on.

The limits vary:

• a closed website builder does not give proper access to the database
• the form is provided by an external service and only keeps data on its own end
• an old site sends e-mails directly and saves nothing
• the platform’s plan does not include an enquiry history
• the site has no CRM, webhook, or logging module
• there are legal requirements around personal data and how long it can be kept
• the database may have been wiped after a hack or an incident

That is why a form audit needs to check not just e-mail delivery, but also one specific question: where does a record of the enquiry actually stay. Without a clear answer, the business depends entirely on the inbox.

A real example: the enquiries existed, but the owner never saw them

A typical scenario for a local service business. The owner had launched an ad campaign, people were landing on the page, and the form showed a success message. The inbox stayed quiet. The first conclusion was simple: the ads were not working, there was no demand.

Checking further showed something else. After the domain’s mail had been switched over, the old sending setup had been left in place. The site was trying to send notifications from the client’s address entered in the form, rather than from the site’s own domain address. To Gmail and Outlook, that looked like suspicious sender spoofing: the e-mail technically arrived from the site’s server, but the header claimed it came from an external address belonging to the client.

Some of the e-mails went to spam, others were rejected with no visible notice to the owner. On screen, the form looked like it was working, because the user saw “sent”. The problem was not the form’s design; it was delivery.

In this case, there was a stroke of luck: enquiries were being saved in the site’s admin area. The log made it possible to find several enquiries from recent days, and to check the sending time, the page, the phone number and the client’s e-mail. Some of those clients could still be reached by phone or e-mail. Without that stored record, recovering them would have been almost impossible; all that would have been left were indirect traces: ad clicks, page visits, analytics events, but not the clients’ actual contact details.

The fix was not “install a different form”. The setup was corrected first:

• From was changed to an address on the site’s own domain
• Reply-To was linked to the client’s e-mail
• sending was switched to run through SMTP
• SPF and DKIM were checked
• a basic DMARC record was added in relaxed mode
• a sending log was switched on
• tests were sent to several different mailboxes
• the mobile scenario was checked

After that, it became clear the site was actually receiving enquiries, the e-mails were arriving, and the owner could check the history if doubts came up again.

What you can check yourself

A basic check can be done without touching any code.

1. Open the form as a client would, not from the admin area.
2. Send a test from a computer.
3. Send a test from a phone.
4. Use a different e-mail address, not the one that normally receives enquiries.
5. Check the inbox, spam, promotions, updates, and “All mail”.
6. Click Reply on the received e-mail and check who the reply would go to.
7. Check whether an auto-reply reaches the client, if one is supposed to.
8. Check whether the enquiry is saved in the admin area, a CRM, or a spreadsheet.
9. Note the exact time of the test, the page, and the sender’s e-mail.
10. Do not change five settings at once, or you will not know afterwards what helped or what broke something.

Testing the form before an ad campaign matters especially. If ads are already sending people to the page while the form silently loses e-mails, the budget disappears into nothing. The owner might wrongly conclude the offer is not appealing, when the real problem is enquiry delivery.

When the problem is not about e-mail at all

Sometimes the e-mail is never even created. In that case, SMTP and DNS will not help.

That happens if:

• the button does not respond on a phone
• a required field is broken
• the captcha blocks everyone indiscriminately
• a JavaScript error occurs after submission
• the form sits inside a popup, and the popup script conflicts with caching
• a theme or template file is not passing the form data through
• the form’s endpoint is blocked by security software or a firewall
• the multilingual version sends the enquiry to a form that does not exist

That is why diagnosis should never start with e-mail alone. It means walking the client’s entire journey: open the page, fill in the form, submit it, see the result, check the e-mail, check the log, and check whether the enquiry was saved.

When it is worth going through Zen Webmaster

If a form matters for enquiries, bookings, quotes or sales, it cannot run on a “set it up once and forget it” basis. It needs ongoing checks.

Zen Webmaster can check:

• whether the form works on desktop and mobile
• whether a popup, caching, a captcha or scripts are getting in the way
• whether From and Reply-To are configured correctly
• whether SMTP is in place with the right access
• whether SPF, DKIM and DMARC pass
• whether e-mails land in spam
• whether enquiries are saved in the admin area, a CRM, or logs
• whether missed enquiries can still be recovered
• which forms exist on the site and whether they all work
• what is worth testing regularly after each update

After the check, a simple monitoring routine can be put in place: a test enquiry once a month, a check after every update, a check before running ads, a sending log, and enquiry storage wherever it is possible. It is dull technical routine, but it is exactly what protects a business from the situation of “clients wrote in, and we received nothing”.

The main point

A website’s form is not just a set of fields. It is the front door of the business. If it breaks, the owner does not just lose an e-mail; they lose a client, the ad budget behind that click, and trust in their own website.

A good setup does not promise magic. It makes the system checkable: you can see that the client submitted the enquiry, you can see whether the e-mail actually went out, you know where a reply should go, and there is a real chance of recovering missed contacts. Without that, a site can look like it is working perfectly while quietly losing money.