Launch Email Checklist: List, Sender Setup, Message and Send Plan

Who is allowed to get this email?

The first check is about people, not code. A launch email works when it goes to someone who asked to hear about the product: a person on your waitlist, a tester, a customer, a reader who subscribed. It fails, and can harm your sending reputation, when it goes to people who never heard of you. Google’s sender guidelines make the same point for mailing lists: send email only to people who want to get messages from you, because those recipients are less likely to report your messages as spam.

• Include people who signed up for this product or your updates, and people who replied to you asking to be told.
• Leave out anyone you only met once, addresses you scraped or bought, and colleagues you are guessing might be interested.
• Remove old addresses that bounced or that have not engaged in a long time, since a pile of dead addresses drags down delivery.
• Keep a record of where each address came from, so that if someone asks why they received it, you can answer in a sentence.

If your list is thin, do not pad it. The waitlist to launch plan explains how to grow it honestly, and for a first reach with no list at all, the how to launch without an audience guide has other routes.

What does your sending setup have to prove?

Gmail publishes the rules it applies to senders, and the email sender guidelines were read on 13 November 2026. They separate all senders from those sending more than 5,000 messages a day to Gmail accounts. A new product’s list is usually far smaller, yet setting up the full list is the cheap, safe choice, because it protects every later message.

Most newsletter and email tools set up SPF and DKIM through a few DNS records they give you. The job is to add them to the domain you actually send from and wait for them to verify. Do this a week before launch, not on the day, because DNS changes take time to settle. If you send from a brand-new domain, send small, normal messages for a while first; a sudden large send from a new address is the pattern mailbox providers tend to distrust.

# SPF: one TXT record starting with v=spf1
dig TXT example.com +short

# DKIM: the selector comes from your email tool's setup page
dig TXT selector1._domainkey.example.com +short

# DMARC: the policy may be p=none while you monitor
dig TXT _dmarc.example.com +short

If a command prints nothing, the record is missing or has not spread yet.

What should the message itself look like?

1. Send from a person’s name and an address that accepts replies, because a “no-reply” sender discourages the answers you want most.
2. Write a subject line that says what happened in plain words, such as “[Product] is live”, since a clear subject beats a clever one for people who already know you.
3. Open with one sentence on why they are getting it: they asked about it, so remind them when and where.
4. Say what changed since they signed up and what you want them to do, in two or three short paragraphs.
5. Include exactly one main action, with a tagged link, so you can tell which email sent whom; the UTM tagging guide for launches shows a scheme.
6. Add a plain-text version and keep images light, because short, simple messages are less likely to be clipped or to look like bulk marketing.
7. Put a visible unsubscribe link in the footer and test it, since an unsubscribe that fails turns a polite reader into a spam report.
8. Sign it, and end with a real question you want answered, so replying feels natural.

For wording to start from, use the launch announcement email template or, for testers, the beta invite email template. This page is the check you run after you have written the message.

In what order should you send?

LIST
[ ] Everyone asked to hear from me about this product
[ ] Bounces and long-inactive addresses removed

SENDER
[ ] From name is a person; replies reach me
[ ] SPF and DKIM verified in my email tool
[ ] Unsubscribe link works (tested)

MESSAGE
[ ] Subject says what happened
[ ] One main action; link is tagged
[ ] Plain-text version exists
[ ] Links open on a phone; none points to localhost or a test address
[ ] Read aloud once; typos fixed

SEND
[ ] Test copies read in two providers
[ ] Small slice first, rest after two hours
[ ] I am free to reply for the next four hours

What should you read after it goes out?

Read replies first. A reply tells you what someone thought, which no counter can. Then read clicks on the tagged link, then the first actions inside the product. Open counts are the weakest signal, because some mail apps load images automatically, which can make an email look opened when nobody read it. If a few people say the email landed in spam, check your records and the unsubscribe path before you send anything else.

Put the result next to what the other channels did, as in launch metrics to track. If your product is not live yet, publish it first: you can launch your product free on this board and link the page in the email as the place to try it.

What can you skip, and what costs the most time?

• Skip split testing subject lines on a small list; the groups are too small to tell you anything.
• Skip heavy design. A plain message that looks like a note from a person is more likely to be read.
• Skip attachments. Link to what you want them to see.
• Mistake: a link pointing to a test address. Click every link in a received copy, not in your editor.
• Mistake: sending to everyone at once and then going out. If a problem appears, you cannot stop it.
• Mistake: no reply path. A launch email that cannot be answered wastes its best result.

If you need an idea of what other makers are building, the ideas board lists ideas that people posted and will not build, which can also be a source of readers who care about the same problems.