KoltrixLaunch Day Email Checklist for a Small SaaS Team
Launch day is a bad time to discover your signup email lands in spam. A checklist for small SaaS teams covering DNS, testing, support staffing and replies.
On this page(5 sections)
On launch day, a lot of new people try your product in a short window, and almost every one of them depends on an email arriving: a confirmation link, a welcome message, a password reset when they forget what they typed an hour ago. If those emails are slow, broken or filtered as spam, the launch goes worse no matter how good the product is.
This checklist is organized by when to do each item: a week before, the day before, launch day itself, and the day after. Work through it with whoever owns your email setup.
One week before
Authentication and DNS
- SPF record published for every domain you send from, including all services that send as you (app, support tool, newsletter tool).
- SPF under the 10 DNS lookup limit. Each
include:can add lookups. Too many and SPF fails. - DKIM published and signing for each sending service. Send a test and confirm
dkim=passin the headers. - DMARC published, at least at
p=nonewith a reporting address, so you can see who's sending as your domain. - MX records correct for any address customers will write to.
The DMARC checker and MX lookup will confirm the records are visible from outside. If DNS was recently changed, allow time for propagation.
Your sending setup
- Know your sending limits. Check your provider's daily and monthly caps and rate limits. If launch could push you past them, upgrade or ask for a temporary increase now, not when sends start failing.
- API keys in production are the live keys, not test keys, and they're stored as secrets.
- Bounce and complaint handling is automatic. Hard-bounced addresses should be suppressed without anyone having to intervene.
- Delivery webhooks (if your provider offers them) are connected to logging or alerting so failures are visible.
Templates
- Every launch-critical email reviewed: signup confirmation, welcome, password reset, team invite, trial-started.
- Links point to production, not staging or localhost.
- Plain-text part included alongside HTML.
- Sender name and address are consistent and recognizable.
The day before
Test on real inboxes
Create fresh test accounts at the major mailbox providers your users are likely to use, typically Gmail, Outlook and Yahoo, plus Apple's mail service if you have many iPhone users. Then run through the real signup flow on production with each one.
| Check | Gmail | Outlook | Yahoo |
|---|---|---|---|
| Confirmation arrived within a minute | |||
| Landed in inbox, not spam | |||
| Links work on desktop | |||
| Links work on mobile | |||
| Renders in dark mode | |||
| Password reset arrives and works |
If something lands in spam, check the authentication results in the message headers first. A header analyzer shows SPF, DKIM and DMARC results quickly. Content and reputation matter too, but broken authentication is the most common and most fixable cause.
Replies and support
- Replies to automated emails go somewhere monitored. A launch brings questions, and many people will simply hit reply on the welcome email. If it comes from
noreply@, those questions disappear. -
support@is staffed for launch day and the following few days, with names and hours written down. - Canned answers drafted for the questions you expect: pricing, how to get started, known limitations, how to cancel.
- Escalation path agreed for bugs: who triages, who fixes, how customers are updated.
The announcement email
If you're emailing a waitlist or existing users about the launch:
- Recipients consented to hear from you.
- Unsubscribe link included.
- Sending spread out rather than all at once. Large bursts from a domain that normally sends little can trigger throttling by mailbox providers. Batches over a few hours are gentler, and they spread the support load too.
- Test send to the team first.
Launch day
- Watch delivery in real time. Keep your email provider's logs or dashboard open. Look for bounces, deferrals and API errors.
- Watch volume against limits. If you're approaching a cap, decide quickly whether to upgrade or pace announcement sends.
- Sign up yourself, again, a few hours in. Confirm the confirmation email still arrives promptly under load.
- Read the shared inbox frequently. Fast answers on launch day are disproportionately valuable.
- Log every issue in one place, with the time and the fix, so the day-after review is easy.
If something breaks
| Symptom | First thing to check |
|---|---|
| Confirmation emails not arriving at all | API errors in your app logs; expired or test API key |
| Emails arriving in spam at one provider | Authentication results in the headers for that provider |
| Emails arriving slowly | Provider status page; rate limits; your own job queue |
| Spike in bounces | Signup form validation; typos; bot signups |
| Users report broken links | Template environment variables pointing to staging |
The day after
- Review bounce and complaint rates from launch day.
- Clear the shared inbox and follow up on anything left open.
- Check for bot signups that may be creating bounces and hurting your reputation. Add protection to the signup form if needed.
- Read the replies to your welcome and announcement emails for patterns. They're unfiltered first impressions.
- Write down what broke and what you'd do differently.
Key takeaways
- Authentication (SPF, DKIM, DMARC) and sending limits should be sorted a week ahead, not on the morning.
- Test the real signup flow on real inboxes at the major providers the day before.
- Make sure replies reach a staffed inbox, and spread announcement sends over a few hours.
- Watch delivery live on launch day, and review bounces, complaints and replies the day after.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
