Contact forms on a static site: how they work without a server
A static site has no server, yet its form delivers. The small function behind it, the spam protection around it, and where the message goes.
The short answer
A static site is a set of finished files with no server behind them, and yet its contact form delivers messages. The trick is a small serverless function: a piece of code hosted by the platform that runs only when a form is submitted, does its job in a fraction of a second, and stops. It validates the submission, filters spam, sends the message through a transactional email service and into a CRM if you have one, logs the event and returns a confirmation. Nothing runs between submissions, nothing is exposed to attackers on a permanent server, and the data path is short and under your control.
What happens when someone presses send
- The browser posts the form to the function’s address, over HTTPS.
- The function validates: required fields present, email shaped like an email, message within length, nothing that looks like injection.
- Spam checks run: a hidden honeypot field is empty, the rate limit for this source is not exceeded, a challenge token is valid if one was required.
- The message is sent onward: an email through a sending service with proper authentication, a record created in the CRM, or both.
- A confirmation is sent to the visitor if appropriate, from a no-reply address with the right authentication records.
- The event is logged: time, outcome, delivery identifiers, without storing more personal data than needed.
- The visitor sees a success message, or a clear error if something failed.
The pieces and who provides them
| Piece | Where it lives | Notes |
|---|---|---|
| The form | The static page | Plain HTML, accessible, works without JavaScript |
| The function | The hosting platform, in a chosen region | Your code, in your repository, deployed with the site |
| Spam protection | In the function, plus the network layer in front | Honeypot, rate limits, challenge only when suspicious |
| Email delivery | A transactional sending service | Its own authentication records on your domain |
| CRM or inbox | Your systems | The function writes to them via API |
| Logs and alerts | Platform logs, monitoring | Failures alert a person |
Why not a mail server or a plugin
A traditional site sends form email through the web server’s own mail function or a plugin. That server’s reputation is shared and usually poor, its authentication records are often missing, and it is a permanent target. The function approach sends through a service whose whole job is delivery, from a domain with correct records, and exposes nothing permanent. It is also easier to reason about: one small piece of code, one data path, one log.
What this means for you
A contact form on a static site is a small function, a sending service and a CRM connection, with spam protection in layers and logs that prove delivery. It costs almost nothing to run, exposes no permanent server and keeps personal data on a short, documented path. If your current form relies on a web server’s mail function or arrives in spam, this is the replacement, and it takes an afternoon.
Frequently asked questions
If the site is static, where does the form send its data?
To a function: a small piece of code hosted by the platform that runs on demand, in a chosen region, and does one job. It checks the submission, filters spam, sends the message through an email service and into a CRM if you have one, and returns a confirmation. It costs nothing when idle and fractions of a cent when used.
Can we use a third-party form service instead?
You can, and for very simple needs it is fine. The trade-offs are that your submissions, which are personal data, pass through and are stored by another company, that customisation is limited, and that you depend on the service's pricing and existence. A small function you own does the same job with the data path under your control.
How do we know the form still works?
Three ways: every submission is logged by the function; a monthly test submission is part of maintenance; and the sending service reports delivery failures. Forms that fail silently for months are a problem we find on inherited sites, and all three measures are cheap.