Coming Soon Page Email Capture — Where the Emails Go

Updated September 2026

Where do the emails from a coming soon page actually go?

Almost every free coming soon template ships with an email field. On most of them, that field does nothing. Not badly — literally nothing. The visitor types an address, the page says thank you, and the address is discarded before the animation finishes.

It is not sabotage. A downloaded .html file is a static document: it has no server, so there is no address to send the form to. Whoever made the template could not wire it up for you, because the endpoint has to be yours. What they could have done is say so.

Below: how to tell in thirty seconds whether yours works, the four ways to make it work, and what each one really costs.

First, check yours

Thirty seconds, no tools

A form that goes nowhere behaves exactly like one that works. Both clear the field and show a success message. There are two ways to know which one you have.

Read the markup

Open the file and find the <form> tag. If it has no action, or the action is #, the browser has nowhere to send anything.

<!-- Goes nowhere: no action attribute -->
<form>
  <input type="email" name="email">
  <button>Notify me</button>
</form>

<!-- Goes somewhere: an endpoint that is yours -->
<form action="https://your-endpoint" method="POST">
  <input type="email" name="email" required>
  <button>Notify me</button>
</form>

Submit it and watch

Open your browser's developer tools, go to the Network tab, and submit the form with your own address. A working form makes a request. A decorative one makes none — the tab stays empty while the page congratulates you.

Then do the part everybody skips: check that the address arrived wherever it was supposed to. A request that returns 200 to a mailbox nobody reads is the same as no request at all.

Making it work

Four routes, and what each actually costs

They are listed from least to most work. All four are legitimate; the right one depends on where you want the list to live when the launch is over.

01

A form endpoint service

Services like Formspree or Basin give you a URL to paste into the form’s action attribute. Each submission is forwarded to your inbox, and kept in a dashboard. Setup is one copy-paste and no code.

Good for
A static file you are hosting yourself and do not want to turn into an application.
The catch
Free tiers cap submissions per month, and your list ends up in a tool that is not your mail provider — you will be exporting and re-importing on launch day.
02

Your email provider’s embed

Mailchimp, ConvertKit, Buttondown and the rest all publish a hosted form you can paste in. The addresses land directly in the audience you will eventually send the launch email from.

Good for
When you already know which tool will send the launch email, and want zero migration later.
The catch
The embed brings its own styling and scripts, which rarely match a template you chose for its design. Expect to spend an evening making it look like it belongs.
03

A hosted coming soon page

The page and the form are one product, so nothing needs wiring. The addresses go into a list attached to the page, and you export when you need them elsewhere.

Good for
Launching quickly, or launching before the real site or CMS exists at all.
The catch
The page lives on someone else’s platform until you export it. Check you can get both the page and the list out before you rely on it.
04

Your own endpoint

A small serverless function, or a route in the app you are already building, that receives the POST and writes the address wherever you want it.

Good for
When the signups need to reach your own database, or trigger something the moment they arrive.
The catch
You now own spam filtering, rate limiting, duplicate handling and deliverability. It is a couple of hours you were not planning to spend on a page that exists for three weeks.

The form itself

One field. Resist the second one.

Every extra field costs signups, and on a page for something that does not exist yet you have no credit to spend. You do not need a first name to send one launch email. You do not need a company size for a product you have not built. Ask for the address, and ask for it once.

The two things worth adding are not fields. First, a success message that says what happens next — “one email, at launch” sets an expectation you can keep, where “thanks for subscribing!” promises a newsletter you may never write. Second, a real label on the input, not just a placeholder: placeholder text disappears the moment someone types, and screen readers treat it as a hint rather than a name.

On consent: if you are collecting addresses in the EU or the UK, the box you need is not a pre-ticked one. Say plainly what you will send and how often, next to the button. A launch list gathered on a clear promise is worth more than a bigger one gathered on a vague one — the second gets marked as spam on the day it finally matters.

Between now and launch

A list you never write to is a list that forgot you

The most common way a launch list fails is not a broken form. It is six months of silence followed by one email to people who no longer recognise the sender. Open rates collapse, complaints spike, and the domain you just started sending from gets its reputation set on the worst possible day.

If the gap will be longer than a month, send something short in between — one honest progress note is enough. It keeps the address warm and gives people an early chance to leave, which is far better than having them leave by marking you as spam.

And export the list somewhere you control before you need it. Whatever collects your signups, the addresses should exist as a file you own, not only inside a tool you might stop paying for.

The fourth route, in detail

If you would rather not wire anything

Every template in the gallery arrives with the field already connected — no endpoint to configure, no mail service to sign up for. Submit the form on any live demo and you will see exactly what your visitor sees. The addresses land in a list you can read and export.

The free plan keeps one live page and shows the first 50 addresses; the rest are kept and appear when you upgrade. We say the number because “unlimited” on a free plan usually means the limit is somewhere you have not found yet.

Questions

Straight answers

Does the email form in a free downloaded template work?

Almost never, and the template is not at fault. A static HTML file has no server to receive a submission, so the form has nothing to post to until you give it an address. Any template that promises working email capture in a .zip is describing something the format cannot do.

How do I know if mine is collecting anything?

Submit it yourself with a real address and watch the Network tab in developer tools. No request means no collection, whatever the success message says. Then confirm the address actually arrived at the other end — a request that succeeds into an unread mailbox is the same as none.

Should I ask for a name as well as an email?

On a launch page, no. Every extra field costs signups, and you do not need a first name to send one email about something going live. Collect the name later, when there is a product and a reason.

Do I need double opt-in on a coming soon page?

It is not legally required everywhere, but it is the difference between a list that opens your launch email and one that reports it. Confirming the address also removes typos, which on a launch list is a surprising share of it.

How long can I sit on the list before emailing?

Longer than a month and you should send something in between. People forget signing up, and the first email after six months of silence is the one that gets marked as spam — on the day your sending reputation matters most.

Can I move the addresses somewhere else later?

You should be able to, and you should check before you commit. Whatever collects your signups, make sure there is a plain CSV export. A list you cannot take with you is not really your list.