How to send form submissions to email without losing track of them

A form submission is the set of answers a browser sends when someone presses the submit button: each field's name paired with what was typed into it. Getting those submissions into an email inbox takes one of four routes: the notification setting in a hosted form builder, a form backend service that your HTML form posts to, a script on your own server, or a mailto: link. The first three work. The fourth mostly does not.

Choosing the route is the quick part. The part that decides whether submissions get answered is what happens after the email arrives, especially once more than one person reads the inbox. This guide covers both: how each route works, what the current free plans and limits are, and how teams keep track of submissions so nothing gets two replies or none. Vendor prices and limits below were checked on their own pages on 8 October 2026.

What happens when someone presses submit

An HTML form has two attributes that decide where the data goes. The action attribute holds a URL, and the method attribute is usually POST. When the visitor submits, the browser collects every field that has a name attribute and sends the pairs to that URL. MDN's guide to sending form data describes the two methods: with GET, the data is appended to the URL, and with POST, it travels in the body of the request, which is the right choice for anything personal or long.

<form action="https://example.com/submit" method="POST">
  <input type="text" name="name" required>
  <input type="email" name="email" required>
  <textarea name="message"></textarea>
  <button type="submit">Send</button>
</form>

Two consequences follow. First, a field without a name is silently dropped, which is the most common reason a field "goes missing" from submission emails. Second, something at the action URL has to receive the data and turn it into an email. A static site on its own has nothing there, which is why form backends exist.

The mailto: approach, where action points to an email address, skips the receiving end entirely and asks the visitor's own computer to open a mail program. On a phone or a computer without a configured mail app, nothing useful happens, and when it does work, the visitor sees a draft email full of raw field names. It is not a reliable way to collect submissions.

Four routes, compared

The decision usually comes down to who owns the form. If the form is already in a hosted builder such as Google Forms, the notification setting is the shortest path. If the form is part of a site's own HTML, a backend endpoint avoids writing server code. A custom script makes sense when submissions must go into an existing system, such as a CRM or ticketing tool, rather than only into an inbox.

Route one: the notification setting in a form builder

Most hosted form builders have a switch that emails the owner when a response arrives. In Google Forms, according to Google's help page on managing responses, it is under Responses, then the More menu, then Get email notifications for new responses. It is one switch, on or off, and it sends the alert to the form owner. Google's page points to the Form notifications add-on for more options, such as sending customised follow up emails to respondents.

The same page describes response receipts for the person who submitted. Under Settings, turn on Collect email addresses (either Verified, which uses the respondent's Google Account, or Responder input, where they type it), then under Responses set Send responders a copy of their response to When requested or Always. Google adds that receipts may not arrive in some cases because of spam filters or other counter abuse measures.

What this route gives is convenience. What it does not give is control over the email itself: the subject line, the layout and the sender are fixed. For a single person reading every alert, that is fine. When the alert goes to a team, the lack of a useful subject line, such as one that includes the enquiry type, makes sorting harder than it needs to be.

Route two: a form backend endpoint

A form backend gives your form an action URL. The browser posts the submission there, and the service emails it to you. No server code is required on your side, which is why these services are popular with static sites.

FormSubmit works with no account. Its homepage shows the setup: point the form's action at the service's URL followed by your email address, make sure every field has a name, and submit once. That first submission triggers an email asking you to confirm the address, and submissions arrive after that. Behaviour is controlled through hidden fields whose names start with an underscore:

• _replyto uses the submitter's email address as the Reply-To, so pressing Reply answers the visitor directly.
• _subject sets the email subject.
• _cc copies each submission to one or more additional addresses.
• _next sends the visitor to your own thank you page instead of the service's.
• _autoresponse sends the submitter a copy with your own message. The page notes this does not work for forms with reCAPTCHA disabled or forms submitted through AJAX.
• _template picks one of three email layouts, including a table.

Formspree uses an account and a dashboard. Its plans page listed these monthly submission allowances on 8 October 2026:

Yearly billing lowers the effective monthly price. Autoresponses start on the Professional plan, and custom email templates and sending from your own domain start on Business, according to the same page.

Spam protection differs between the two. FormSubmit shows a reCAPTCHA by default, lets it be switched off per form with a _captcha field, and recommends keeping it on. It also accepts a _blacklist field with comma separated phrases, and submissions containing them are discarded; the page suggests no more than 20 phrases. Formspree lists basic spam filtering and reCAPTCHA on every plan, including Free, with stronger controls on the paid tiers. On any public form, expect automated submissions within days of going live, and check the spam folder of the receiving inbox during the first week.

The monthly allowance is the number to check first. A contact form on a small site rarely reaches 50 submissions a month. A form that also collects newsletter signups or event registrations can pass it in a week.

Route three: your own script

A server side script receives the post, validates it, and hands it to a mail sending service. The upside is complete control: the subject can include the enquiry type, the email can be routed to the right person based on an answer, and the submission can be written to a database at the same time.

The downsides are the ones that tend to appear months later. The script needs spam protection, because public forms attract automated submissions within days. It needs a properly configured sending domain, or the notification emails land in spam. And it needs someone to maintain it when the mail service changes its API. If a developer is already maintaining the site, this is reasonable. If not, the first two routes cost less over a year.

Making the notification email worth opening

Whichever route is used, a few settings decide whether the email helps or just adds to the pile.

• Put the useful facts in the subject line. "New submission" tells the reader nothing. "Quote request: Office move, 40 desks" tells them whether to open it now.
• Set Reply-To to the submitter. With it, pressing Reply answers the visitor. Without it, replies go to the service's own address, or have to be copied by hand.
• Send to a shared address, not a personal one. When the person who set up the form leaves or goes on holiday, notifications to a personal inbox stop being read.
• Send the submitter an acknowledgement. One sentence stating when they can expect a reply cuts follow up emails asking whether the form worked.
• Test from outside. Submit the form from a phone on mobile data with an address on a different provider, and check that both the notification and the acknowledgement arrive, and where they land.

Why an inbox loses track of submissions

Every route above ends in the same place: an email in an inbox. That works while one person reads every submission and replies to each one. It starts to fail when two or three people share the work, and it fails in predictable ways.

Nobody owns a submission. Three people get the same notification. Each assumes one of the others will reply. Either nobody replies, or two people reply with different answers within the hour. The email itself has no field that says whose it is.

Nothing records the status. Is this one answered, waiting for the visitor, or finished? An inbox has read and unread, and maybe a label or two. Finding what is still open means scrolling back through weeks of notifications, and anyone who opened an email but did not reply has already turned it from unread to read.

The history is split. The submission is in one email, the reply is in someone's sent folder, and the visitor's follow up arrives as a new thread. When the same person writes again a month later, nobody can see what was promised the first time.

Teams usually patch this with a shared spreadsheet: one row per submission, with columns for Owner, Status and Date replied, filled in by hand. That holds up at a few dozen submissions a month. Past that, the columns stop being updated, and once nobody trusts them, nobody uses them.

The alternative is to stop treating the email as the record. A form tool with response management keeps each submission as an item with an owner and a status, and sends the reply from the same screen, so the reply is stored with the submission it answers. The notification email still goes out, but only as an alert; the record lives in the list. The features page shows that layout, and the demo lets you try it without signing up.

What to change first

Make sure every field has a name, set Reply-To to the submitter, and send notifications to a shared address rather than a personal one. If two or more people answer submissions, decide where each one's owner and status are recorded before the volume grows; Halict keeps both on each submission and is priced by the number of people using it.

Q1. What is a form submission?

It is the data a browser sends when someone presses a form's submit button. Each field that has a name attribute is sent as a name and value pair to the URL in the form's action attribute, usually with the POST method. Something at that URL then has to store it or email it.

Q2. How do I get form submissions sent to my email without a server?

Use a hosted form builder with email notifications, or point your HTML form's action at a form backend service such as FormSubmit or Formspree. Both email the submission to you. FormSubmit asks you to confirm your address on the first submission, and Formspree's free plan covered 50 submissions a month as of October 2026.

Q3. Why are some fields missing from my submission emails?

The most common cause is a field without a name attribute. Browsers only send fields that have a name, so a field with only an id is dropped. Check each input, select and textarea in the form's HTML.

Q4. Can I reply directly to the person who filled in the form?

Yes, if the notification email's Reply-To is set to the submitter's address. In FormSubmit this is done with a _replyto field, and most form builders have an equivalent setting. Without it, pressing Reply sends the answer to the service rather than the visitor.

Q5. How do I stop two people replying to the same submission?

Give every submission an owner as soon as it arrives, and record when it has been answered. A shared inbox cannot hold that on its own, so teams use either a spreadsheet with Owner and Status columns or a form tool that stores both with each submission and sends the reply from the same place.