How to set up a contact form that actually sends email reliably
A plain HTML form can't send email by itself — it needs a form-handling service to receive the submission and forward it to your inbox. Pick a provider, wire up spam filtering, and send a real test submission before launch, because a silently broken contact form is one of the most common ways small business sites lose leads.
Here's the detail that catches a lot of first-time template buyers off guard: an HTML `<form>` tag doesn't send email. It's just markup describing input fields and a submit button. Something has to receive that submission and actually deliver it somewhere — and on a static HTML/CSS site, there's no server-side code running to do that job.
This isn't a flaw in static sites. It's just a piece of infrastructure you add on purpose, and it's a genuinely easy piece to add. The mistake is assuming it works out of the box and not testing it until a real customer's message vanishes into nothing.
Why a static form needs outside help
On a WordPress or other server-rendered site, the form's submission is typically processed by server-side code (PHP, for example) that runs on your host and can send email directly. A static site has no equivalent running process — it's just files. So the form's data needs somewhere else to go: a third-party form-handling service that receives the submission via the form's `action` attribute and forwards it to your inbox, a spreadsheet, or a CRM.
How a form-handling service actually works
Nothing runs on your own server — the handling service does the work.
In practice, setup usually means pointing your form's `action` attribute at a URL the service gives you, or adding a small script tag, then verifying your email address with them so they know where to forward submissions. Most providers offer a free tier generous enough for a small business's typical volume, with paid tiers unlocking more submissions, file uploads, or advanced spam filtering.
| Factor | Why it matters |
|---|---|
| Free tier submission limit | Confirms you won't hit a wall during a normal month |
| Spam filtering approach | Honeypot fields and simple challenges keep bot noise out of your inbox |
| Notification routing | Can it email you, and also post to Slack or a spreadsheet if you need that later |
| File upload support | Relevant if you need attachments, like a resume or a quote request document |
| Setup complexity | Some are a single form attribute; others need a short script include |
Spam filtering: don't skip it
Any public form on the internet attracts automated spam within days of going live. A honeypot field — a hidden input real visitors never see or fill in, but bots often do — catches a large share of this with zero friction for real users. Most form-handling services include this or an equivalent option; turn it on before launch, not after your inbox fills up with junk and you start ignoring genuine leads along with it.
Setting it up, step by step
- 1Choose a form-handling providerPick one that fits your expected monthly volume and whether you need extras like file uploads.
- 2Point the form at the serviceUpdate the form's action attribute or add the script snippet the provider gives you.
- 3Verify your destination emailConfirm the address that submissions should be forwarded to, following the provider's verification step.
- 4Turn on spam filteringEnable the honeypot field or equivalent option before the form goes live.
- 5Send a real test submissionFill out the live form yourself and confirm the email actually lands in your inbox, not spam.
- 6Check your spam folder tooNew sending domains sometimes get filtered at first — confirm delivery, don't assume it.
Confirming the visitor's side too
A visitor who submits a form and sees nothing happen will assume it failed, even if the email arrived perfectly on your end. Always show a clear success message or redirect to a proper thank-you page after submission, and consider an autoresponder confirming "we got your message" if your provider supports it. The goal is that neither side is left wondering whether the form worked.
- ›Clear confirmation the message was received
- ›What happens next, and roughly when
- ›A way to reach you directly if it's urgent
A dedicated thank-you page removes any doubt that the submission worked.
Testing before launch, not after
The only real test is an end-to-end one: open the live form in a normal browser, fill it out as a stranger would, and confirm the email actually arrives — including checking spam folders and any team inbox filters that might quietly redirect it. Do this again any time you change hosting, redesign the form, or switch providers, because it's an easy step to silently break without any visible error.
- ✓A plain HTML form cannot send email by itself — it needs a form-handling service.
- ✓Pointing the form's action at the service is usually the entire integration.
- ✓Turn on spam filtering, ideally an invisible honeypot, before launch.
- ✓Show a clear confirmation so visitors know their message actually went through.
- ✓Always send a real end-to-end test submission before and after any changes.