How to Send an HTML Form to Your Email (Without PHP or SMTP)

An HTML form cannot send email on its own. It can only POST its fields to a URL, so the job is to put something at that URL that turns the submission into an email. The fastest way that works on any static host is a form endpoint: one action attribute, no PHP, no SMTP, no JavaScript. This guide covers that method, the JavaScript fetch() version, the serverless-plus-SMTP version for people who want to own the sending, and why mailto: and PHP mail() keep failing.

Full disclosure: ShipMyForm is our product and it is the form endpoint in the examples. Every other option below is described on its merits.

Every way to send an HTML form to email, compared

Send HTML form data to an email address without PHP

This is the whole thing. Point action at a form endpoint and give each input a name. The endpoint receives the POST, stores it, and emails you:

<form action="https://shipmyform.com/f/YOUR_FORM_ID" method="POST">
  <label>Your email <input type="email" name="email" required /></label>
  <label>Message <textarea name="message" required></textarea></label>
  <button type="submit">Send</button>
</form>

No fetch() wrapper, no keys in the page, no server. Because it is a standard form post it behaves identically whether the page is Astro, Hugo, Next.js, plain HTML, or something an AI builder produced. Add a hidden field named _subject to set the email subject, and _redirect to choose the thank-you page. If you want the markup generated for your own fields, the free contact form generator writes it, honeypot included.

Send HTML form data to email using JavaScript

Keep the same endpoint and post to it with fetch() when you want an inline "thanks" instead of a page change. The JavaScript is the browser half only; the email is still sent server-side, so there are no credentials to leak.

<form id="contact" action="https://shipmyform.com/f/YOUR_FORM_ID" method="POST">
  <input type="email" name="email" required />
  <textarea name="message" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  const form = document.getElementById("contact");
  form.addEventListener("submit", async (e) => {
    e.preventDefault();
    const res = await fetch(form.action, {
      method: "POST",
      body: new FormData(form),
      headers: { Accept: "application/json" },
    });
    form.outerHTML = res.ok
      ? "<p>Thanks, we'll be in touch.</p>"
      : "<p>Something went wrong. Please email us directly.</p>";
  });
</script>

The full pattern, with loading states and per-field validation errors from the JSON response, is in submit a form with fetch().

HTML form to email with SMTP, if you want to own the sending

You cannot speak SMTP from a browser, and you should not try: the credentials would be in the page. What you can do is put a small serverless function between the form and your mail provider. The form posts to the function, the function sends through a transactional email API with a verified sending domain.

// api/contact.js (Vercel or Netlify function)
export default async function handler(req, res) {
  const { email, message } = req.body;
  await fetch("https://api.your-email-provider.com/send", {
    method: "POST",
    headers: { Authorization: `Bearer ${process.env.EMAIL_API_KEY}` },
    body: JSON.stringify({
      from: "[email protected]",
      reply_to: email,
      to: "[email protected]",
      subject: "New contact form message",
      text: message,
    }),
  });
  res.status(200).json({ ok: true });
}

This is a correct answer if you already run email infrastructure. You also own the DNS records, bounce handling, spam filtering, rate limiting and retries. The Vercel contact form guide walks through what that costs in practice.

Why the popular shortcuts fail

mailto: does not send anything. It asks the visitor's browser to open their mail client with a draft they then have to send themselves. On a phone, a locked-down work machine, or a browser with no mail client configured, nothing happens. The data arrives as a URL-encoded blob, and you have published your address for every scraper. Fine as a plain "email us" link. Useless as a form.

PHP mail() assumes a server you do not have. Netlify, Vercel, GitHub Pages and Cloudflare Pages cannot run it. Even on a PHP host, bare mail() sends without authentication and lands in spam.

Email services called from JavaScript put your key in the page. Anyone can open dev tools, copy it, and send as you until you notice the bill or the blocklist. Acceptable for an internal tool behind a login. Risky for anything a stranger can load.

The part tutorials skip: making the email actually arrive

Getting the email sent is half the job. Getting it into the inbox rather than spam is the half nobody writes about, and three things decide it.

Send from a domain you control, not the visitor

The instinct is to make the notification come "from" the person who filled in the form. Do not. Mail providers check that the sender is allowed to send for that domain, through SPF and DKIM, and you cannot authenticate for someone else's address. Send from your own domain and put the visitor's address in Reply-To. The mail authenticates, and hitting reply still reaches them.

Publish SPF, DKIM and DMARC for the sending domain

Three DNS records that say "this server may send for my domain". Without them even a well-formed email is treated with suspicion. A transactional provider, or a form backend that uses one, gives you the exact records. Ten minutes, once.

Give it a real subject and reply path

A submission with a blank or generic subject is easy to miss and easy for filters to distrust. A clear subject plus a working Reply-To makes the notification a real email you can act on.

If your form mail is already going to spam, the fix is usually the first of these three. Why form emails land in spam walks through the diagnosis.

Do not forget the spam bots

The moment a form can email you, it can email you garbage; bots find public forms within days. You do not need a CAPTCHA for most of it: a hidden honeypot field plus server-side rate limiting blocks the bulk quietly. See how to stop form spam without reCAPTCHA.

Which should you use?

• A personal page, low stakes. A mailto: link, not a form, is honestly fine.
• An internal tool behind a login. A JavaScript email service will do.
• You already run email infrastructure. A serverless function and your provider.
• A real contact form on a public site. Post to a form endpoint. It stays static, keeps credentials safe, gets deliverability right, and is one attribute.

Email was never HTML's job. Hand it to something built for it, keep your form a plain <form>, and the message shows up where you expected it.

Next steps

• Want the code ready to paste? HTML contact form templates that email you
• Keep the visitor on the page: submit a form with fetch()
• Landing in the spam folder? Why form emails get filtered
• Build one now: add a contact form to an Astro site
• Understand what is doing the work: what is a form backend?
• Start free: email notifications on every plan, 250 submissions a month, no card required.