A site made of HTML and CSS can include a contact form, but an HTML file cannot receive data or store a message by itself. The browser needs an address to which it can send a POST. ZoraForms provides that address, stores accepted submissions in the dashboard, and lets you configure protection and follow-up without running your own server.
What static hosting provides—and what it does not
GitHub Pages, a CDN, or basic file hosting are excellent at serving HTML, images, and JavaScript. They do not create a form-receiving endpoint, a submissions queue, or server-side validation. The action attribute names a destination; it does not turn a directory of files into a backend application.
This distinction matters for email too. A mailto: link opens the visitor’s mail client and lets them abandon or edit the message. It cannot confirm sending, store a submission in your dashboard, or work smoothly for a visitor without a configured mail app. A POST form collects form data first; delivery can then be handled separately.
- Identify the public page where the form will live.
- Choose the few fields needed for a first reply.
- Use a POST receiver instead of expecting static hosting to receive mail.
Connect the form to ZoraForms
In the dashboard, add a website, create a form, and copy its current public address from Integration. Put it in action, set method to POST, and give every field that should appear in a submission a name. The public identifier is meant for HTML; never put a secret or password there.
The example below is a starting point for a form without extra protection. If you use CAPTCHA, a honeypot, or a minimum completion time, download the complete snippet from the dashboard after saving those settings. It includes the fields required for verification.
<form action="https://forms.example.com/f/YOUR_PUBLIC_ID" method="POST">
<label>Email <input name="email" type="email" required /></label>
<label>Message <textarea name="message" required></textarea></label>
<button type="submit">Send</button>
</form>Check the origin and first submission
Enter the page’s allowed origin in the form settings, for example https://example.com. An origin includes protocol and host, so https://www.example.com and https://example.com are different. This setting helps catch submissions from an unexpected site, but it does not replace spam protection or authenticate a user.
After publishing, complete the form as a normal visitor. Open Submissions in ZoraForms and check that the expected field names and protection result appear. If the form should redirect on success or show a message without a reload, use the generated HTML or fetch variant in Integration for the current configuration.
- Check the action address and method="POST".
- Check name attributes on email and message fields.
- Add the exact production-page origin.
- Send a test and find it in the dashboard.
Start simply, but watch the limit
The Free plan includes one website, one form, and up to 100 monthly submissions. Before it can accept submissions, you must prove control of a public domain with a DNS TXT record. You can prepare the website and form first, but new submissions are accepted only after the record is checked successfully.
After a working test, you can add CAPTCHA, UTM attribution, or a webhook. A protection change needs a fresh integration snippet, and a campaign deserves a check of current usage. ZoraForms does not provide file uploads or a shared team inbox; treat the form as an orderly channel for new submissions rather than a complete email-helpdesk system.