# From waitlist to launch day email

> Email your waitlist on launch day without landing in spam: clean list, authenticated domain, batched sends.

Canonical: https://abacklaunch.com/prompts/waitlist-launch-email
Last updated: 2026-10-26

Version 1.0.

People signed up to hear when the production site launches. On launch day I want to email all of them once, have it arrive in the inbox, and know who clicked. Set this up with the email provider this project already uses (or tell me the options if there is none), using the domain's authentication properly, sending in batches, and with a working unsubscribe.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Send any email to the real list. I run the send myself.
- Change DNS records.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Find the list and how it was collected

Find where waitlist signups are stored and what each record has (email, date, source, consent). Count them, and count duplicates and obviously invalid addresses. Tell me whether people were told they would get a launch email; if not, the email must say why they are receiving it.

### 2. Check the sending domain

List the DNS records the provider needs: SPF (one `v=spf1` record that includes the provider), DKIM (the provider's CNAME or TXT keys) and DMARC (a `_dmarc` TXT record, at least `v=DMARC1; p=none; rua=...` to start). You cannot change DNS, so write the exact records for me and how to confirm each one. Send from an address on the site's domain, not a free mailbox.

### 3. Write the email with me

Draft a plain, short launch email: what launched, the one thing it does, one link (with `utm_source=waitlist&utm_medium=email&utm_campaign=launch`), and a reply-to that reaches me. Plain text plus a simple HTML version. Show me the draft before building anything around it.

### 4. Send safely

- Build a one-off script or admin action that sends through the email provider this project already uses (or tell me the options if there is none), in batches with a pause between them (respect the provider's rate limits), and records who was sent to, so a re-run never emails anyone twice.
- Every email carries a one-click unsubscribe (`List-Unsubscribe` and `List-Unsubscribe-Post` headers) and a visible unsubscribe link that works; unsubscribed addresses are never emailed again.
- Include a dry-run mode that prints who would get the email, and a test mode that sends only to me.

## Done means

- [ ] The waitlist is de-duplicated and invalid addresses are excluded.
- [ ] I have the exact SPF, DKIM and DMARC records to add, and how to check them.
- [ ] The send script batches, records each send, and can be re-run without duplicates.
- [ ] Every email has a working unsubscribe link and List-Unsubscribe headers.
- [ ] A dry run and a test send to me both work.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.

## Related

- [Analytics and UTM attribution for launch day](https://abacklaunch.com/prompts/launch-analytics-attribution)
- [Get ready for a launch day traffic spike](https://abacklaunch.com/prompts/launch-day-traffic-readiness)
- [Pre-launch audit with a prioritised fix list](https://abacklaunch.com/prompts/pre-launch-audit)