Guides / Prompting and shipping

How to Add a Contact Form to Your Website (That Actually Reaches You)

How to add a contact form that works: save messages, get email alerts, stop spam, and avoid the mistakes that silently lose enquiries. Prompts included.

Mythex Team · 2026-09-29 · 5 min read

To add a contact form that works, build a short form (name, email, message), send it to a server route that validates the input, saves the message to a database, and then emails you a notification through an email provider using a secret API key. Add a hidden honeypot field and rate limiting to stop most spam, show a clear success message, and test it end to end on the published site. Saving before emailing is the important part: if email ever fails, you still have the enquiry.

Your options

If your site already has a backend and database — which apps built with AI app builders often do — the last option is the most reliable and keeps enquiries where you can see them.

What a good contact form includes

• As few fields as possible. Name, email, message. Add a subject dropdown ("Sales", "Support", "Other") only if you'll route by it.
• Clear labels above each field, not just placeholder text that disappears.
• Helpful validation: "Enter a valid email address", shown next to the field.
• A success state that says what happens next: "Thanks — we reply within one working day."
• A privacy note saying how you'll use the details, linked to your privacy policy.
• A fallback such as your email address or phone number for people who prefer it.

Example prompts

The basic form:

Add a contact form on the Contact page with name, email and message (all required, message up to 2,000 characters). Submit to a server route that validates the input, saves it to a contact_messages table with the time received, and shows a success message: "Thanks, we'll reply within one working day." Show field errors inline. Make it work well on phones.

Email notifications:

When a contact message is saved, send me a notification email at hello@example.com using Resend with the key in RESEND_API_KEY. Set reply-to to the sender's email so I can reply directly. If sending fails, keep the saved message and log the error without exposing the key.

Spam protection:

Add spam protection to the contact form: a hidden honeypot field that must stay empty, a limit of 5 submissions per IP per hour on the server, and reject messages with more than 3 links. Silently drop honeypot submissions but still show success.

An inbox:

Add a password-protected admin page listing contact messages newest first, with a "handled" checkbox and a filter for unhandled messages.

Step by step

1. Decide where messages go: who receives notifications, and who replies.
2. Build the form with the fields above, accessible labels and mobile-friendly inputs (use the email input type so phones show the right keyboard).
3. Create the server route. It checks required fields, email format and length limits. Never trust browser-only validation.
4. Save to the database first. See how to add a database to your app.
5. Set up an email provider. Create an account, verify your sending domain, and store the API key as a secret. How to send emails from your app covers domain setup (SPF, DKIM) in detail.
6. Send the notification from the server after saving. Use your verified domain as the sender and the visitor's address as reply-to — don't send "from" the visitor's address, or it will likely be rejected as spoofing.
7. Optionally auto-reply to the visitor, but keep it short; auto-replies to spam addresses can hurt your sender reputation.
8. Add spam protection: honeypot, rate limiting, then a CAPTCHA-style check if needed.
9. Test on the published site: submit, check the database, check your inbox and spam folder, click reply.

Stopping spam

Contact forms attract bots within days of going live. Layer defences from least to most intrusive:

1. Honeypot field. A field hidden from humans; bots fill it in. Costs real visitors nothing.
2. Server-side rate limiting. Caps how many messages one address can send in a period.
3. Content rules. Reject messages stuffed with links, or with a message field that's empty or absurdly long.
4. A CAPTCHA-style check, such as Cloudflare Turnstile or Google reCAPTCHA. The token must be verified on your server; a check that only runs in the browser can be skipped.

Common mistakes

• Showing "Sent!" when nothing was sent. The UI says success before or regardless of the server response. Always wait for the server.
• Email only, no database. One misconfigured key and enquiries disappear for weeks without anyone noticing.
• API key in frontend code. Anyone can use it to send email as you.
• Unverified sending domain. Notifications land in spam or never arrive.
• Sending "from" the visitor's email. Use reply-to instead.
• No length limits. Bots paste huge blocks of text.
• Never testing the live site. Keys and domains often differ between preview and production.

Checklist

• Short form with visible labels and clear errors
• Server-side validation and length limits
• Every message saved to the database
• Notification email sent from a verified domain, with reply-to set
• Email API key stored only in server-side secrets
• Honeypot and rate limiting in place
• Success message appears only after the server confirms
• Privacy note links to your privacy policy
• Tested end to end on the published site, including the spam folder

Contact forms in Mythex

In Mythex, you can build the whole thing from chat. Ask for the form and a database in the same prompt (or type /database) so submissions persist. Mythex doesn't have a built-in email sending product, so for notifications you bring a provider such as Resend, SendGrid or Postmark, add its key with /secrets or project settings, and ask the agent to send from the server — see Send email from your app. Before you rely on it, run App Testing (/test) against the form in Preview, then publish and test on the live URL.

A contact form is a key part of most small business websites and landing pages. Check the security checklist before launch.