Signup Forms and Double Opt-In With an Interactive Confirm Email

Most signup forms hand off to a generic confirmation email the moment double opt-in is turned on. MailInApp's confirm step can be any studio project — a countdown to a limited-time welcome offer, a quick poll about why they signed up — so the very first interactive email a new subscriber gets is also the one that gets them onto your active list.

Subject

Confirm your subscription

A signup form collects new subscribers straight into a contacts list — inline on your own site, as a popup, or as a standalone hosted page — and where double opt-in matters, the confirmation email can be any interactive studio project, not a plain "click to confirm" line.

Before this, growing a MailInApp list meant a CSV import or an API call — no way to actually capture a signup on your own site. Signup forms close that gap, and because the confirmation step (when you need one) is a real studio project, the very first interactive email a new subscriber receives can also be the one that gets them onto your active list.

Three kinds of form

  • Inline — an embed snippet you drop wherever you want the form to render on your own page.
  • Popup — a full-page overlay triggered by a delay, scroll depth, or exit intent, with a cooldown so someone who dismisses it isn't shown it again right away.
  • Hosted — a standalone page at /f/<formId> with no embed step at all, for when you just need a link.

All three post to the same hardened public endpoint every other unauthenticated MailInApp route uses: a honeypot field, per-IP rate limiting, and Turnstile bot protection if you've configured it.

Double opt-in, and why it's per-form

Double opt-in is off by default, and turned on per form rather than account-wide — it's a legal requirement in some places (Germany and Austria, notably) and simply good hygiene elsewhere, but forcing it everywhere would cost list growth for accounts where it isn't required. Turn it on, pick a project to send as the confirmation, and a new submission is stored as a pending contact row — skipped by every send, manual, scheduled, or journey — until the confirm link is clicked.

The confirmation email doesn't have to be plain text

Because the confirm step is an ordinary studio project, it can carry a Countdown on a limited-time welcome offer, or a quick Poll asking why someone signed up — the first real interaction a new subscriber has with your brand, not a throwaway transactional message. Clicking the confirm link flips the row from pending to active; from that point on they're an ordinary contact, eligible for every future send.

Getting a form live

The Get code action on a form gives you a framework-free embed snippet — plain JavaScript that mounts the form into a page element, no MailInApp runtime required on your site — or the hosted link, both with copy-to-clipboard. A form can also collect up to 10 fields beyond the always-present email address, and let a new subscriber opt into specific mail topics if you've defined any, rather than an all-or-nothing subscription.

Getting started

Create a form from the Forms tab, pick a target contacts list, and decide whether you need double opt-in — check the box and pick a confirmation project if you do. See Signup forms & popups for the full field and embed reference, and landing pages if you'd rather build a whole page around the form instead of just embedding it.

A typical build-and-send sequence

  1. 1

    Create the form and pick a target list

    From the Signup Forms tab, choose inline, popup, or hosted, point it at a contacts list, and add up to 10 fields beyond the always-present email address.

  2. 2

    Turn on double opt-in where it's required

    Check Require double opt-in and pick which studio project sends as the confirmation — a new subscriber is stored as pending, skipped by every send, until they click through.

  3. 3

    Embed it or share the hosted link

    Get code gives you a framework-free embed snippet for inline or popup forms, or a standalone hosted page at /f/<formId> if you'd rather just link to it directly.

  4. 4

    Confirm turns them into an active contact

    Clicking the confirm link in the interactive project flips the row from pending to active — from that point on they're an ordinary contact, eligible for every future send, schedule, and journey.

Frequently asked questions

What actually happens to a submission before it's confirmed?

It's written as a real contact row with a pending status — visible in your contacts list, but automatically skipped by every send (manual, scheduled, or journey) until the double opt-in link is clicked, at which point it becomes an ordinary active contact.

Is double opt-in required, or optional per form?

It's off by default and set per form — required in some places (Germany and Austria, notably) and optional elsewhere, so you turn it on only for the forms where it actually matters rather than it being forced account-wide.

Can the confirmation email be more than a plain "click to confirm" message?

Yes — the confirm project can be any interactive studio project, so it can carry a Countdown on a welcome offer, a Poll about what brought them in, or anything else a normal email could, not just a bare confirmation link.

How is the popup form protected from bots and abuse?

The same way every other unauthenticated MailInApp endpoint is — a honeypot field, per-IP rate limiting, and Turnstile bot protection if you've configured it, on top of the CORS-permissive public submit endpoint the embed script posts to.

Can a subscriber opt into specific topics at signup instead of an all-or-nothing subscription?

Yes, if you've defined mail topics on your account — a form can show which ones a new subscriber opts into, and those choices are what later sends check before mailing that topic to them.

Build this in the studio

Start on the free plan — every interactive block and the full fallback engine are included on every tier.