Auto-welcome email on every signup form

A new subscriber will never be more interested in your product than the moment they hit Submit on your signup form. Until today, doing anything with that moment on SMTPfast meant wiring up a contact.subscribed webhook to your own service that then called the email API to send a follow-up. Useful if you have engineering time. Overkill if you just want a welcome email.

Now every signup form ships with a built-in auto-welcome email. Toggle it on, write a subject and a markdown body, save. Every new subscriber to that form gets the welcome the moment they confirm.

Why one extra email matters this much

Public 2026 benchmarks on welcome emails are striking enough that most SaaS teams underweight them:

A welcome email gets roughly 3 to 3.5 times the open rate of a regular broadcast to the same list. Click rates show the same effect, harder: ~14% on welcomes against ~3% on newsletters. About 70% of the opens and 85% of the clicks happen in the first 24 hours after delivery. The intent curve drops fast after that.

The cost to build this from scratch on top of a transactional API is real. The cost to enable it on SMTPfast is two text fields.

What it looks like

In the dashboard, open any signup form and you'll see a new Welcome email card above the existing settings:

• A toggle to enable or disable
• From address (must be on a verified sending domain)
• Subject, with variable substitution
• Body in markdown, with the same {{first_name|fallback}} syntax broadcasts use
• A row of stats: sent, delivered, opened, clicked, skipped (with a reason code)

A useful welcome looks roughly like this in the body field:

Hi {{first_name|there}},

Thanks for signing up to Acme. Here's the fastest way to get started:

- The quickstart at https://acme.dev/docs/quickstart
- Your dashboard at https://acme.dev/app
- Reply to this email if you get stuck. We read every reply.

The Acme team

The variables get substituted before the email is queued. The |fallback syntax is the bit that stops you sending "Hi ," to subscribers who left the first-name field blank.

When it fires

It depends on whether the form uses double opt-in:

• Double opt-in on: the welcome fires after the subscriber clicks the confirmation link. This is the recommended setup. It also means a hostile signup that never confirms will never trigger the welcome, which is the whole point of double opt-in.
• Double opt-in off: the welcome fires immediately on form submit, after the contact is created.

In both cases the welcome is idempotent. Each (form, contact) pair gets at most one welcome. Re-submission, double-clicks on the confirmation link, and webhook retries cannot produce duplicates.

What it does NOT do

Auto-welcome rides the same rails as every other send on SMTPfast. That means:

• It still counts against your monthly plan quota.
• It still goes through new-account warmup. A brand-new account that wires this up on day one will see the welcome skipped for the first hour of warmup. The skip count on the form's stats reads account_warmup so it is obvious why.
• It still respects the abuse auto-suspend. An account currently suspended for high bounces does not auto-send welcomes.
• The trusted-sender bypass admins can flip on user accounts skips warmup, but never the abuse rails. Welcome emails inherit the same posture.

These are deliberate. The most common abuser of public signup forms is exactly the operator who wants a "system" email path that bypasses the gates the rest of your sending uses. If the welcome cannot ride the same rails as a regular broadcast, it should not ride at all.

Variables you can use

Three for v1. All take the |fallback syntax:

• {{first_name|there}}
• {{last_name}}
• {{email}}

Anything beyond first name in a welcome email tends to feel uncanny rather than personal. Two variables earn their place: the subscriber's name and the product they signed up to. Anything else is decoration.

Skip reasons (and how to read them)

If a welcome did not go out, the form's stats card shows it under Skipped and the reason is stored on the delivery row. The codes:

• disabled: toggle is off, or the form is no longer active.
• missing_config: From, Subject, or Body is blank.
• no_verified_domain: the From address is on a domain you have not verified yet. Verify the domain on /domains.
• account_warmup: first-week warmup is blocking the send. Will resolve on its own.
• monthly_quota_exhausted: you've hit the email cap for this billing period.
• unsubscribed_contact: the contact previously unsubscribed and was re-added. Welcome is suppressed by design.
• spam_content: the rendered welcome read like prize or lottery spam next to a link on an anonymous page or URL shortener, usually because of what was typed into the name fields. Not sent; check the template and the contact.

A skipped count of zero is the right state once you've configured everything. If you see skips piling up under one code, that's the lever to pull.

What's not in v1

A few intentional gaps:

• No multi-step sequences. One email per form. v2 may add an optional second step a few days later, but keeping v1 to a single message is what made it ship today.
• No visual flow builder. Same reason. Most welcome emails are sent by people who would not use a flow builder if they had one.
• No A/B testing on the welcome subject line. Possible follow-up if the demand surfaces.

Auto-welcome is the highest-engagement message any product can send. If you have a signup form on SMTPfast and you do not have a welcome wired up, that is the next 60 seconds of work that pays back the most.

Open your forms →