Why this matters
Signup confirmations, magic links, receipts, password resets, if these emails do not arrive, your product is broken in the user's eyes no matter how good the app is. Deliverability is earned through correct setup, and it is far easier to set up correctly now than to dig your domain out of spam folders later.
What "done" looks like
- A transactional email service connected (Resend, Postmark, SES, any reputable one)
- Your domain authenticated: SPF, DKIM, and DMARC records verified
- The critical emails implemented: welcome/confirmation, magic link or reset, receipt
- A test signup lands in the inbox, not spam, on Gmail and Outlook
How to do it
- Send from a subdomain (e.g.
mail.yourdomain.com) to help isolate transactional reputation from marketing experiments, while recognizing that domain and provider reputation can still interact. - Add the DNS records the provider gives you (SPF, DKIM) and a basic DMARC policy; verify until everything shows green.
- Implement the minimum set, auth emails and receipts. Plain, fast, clearly from you. Skip newsletters for now.
- Make templates boring and clear: your product name in the sender, one purpose per email, a plain-text feel.
- Test across providers (Gmail, Outlook, iCloud) and check the spam score before launch.
Common mistakes
- Sending auth emails from a personal Gmail or an unauthenticated domain
- Mixing marketing blasts and transactional mail on the same domain and IP reputation
- No receipt email, the fastest way to make a paying customer nervous
Real-world examples
- Resend is a developer-focused email API for transactional and product email, such as signup confirmations, password resets, and receipts. It pairs with its open-source React Email library for building templates. It has also added Audiences and Broadcasts for marketing email.
- Whichever provider you choose, start with a small set of plain, single-purpose templates and test each one across major inbox providers before launch.
- The general pattern for any app with logins or payments is to route these system emails through a dedicated API (Resend, Postmark, or SendGrid) rather than your own mail server, because deliverability, landing in the inbox, not spam, is a full-time problem you don't want to own.
From a founder's point of view
Transactional email is invisible when it works and a support nightmare when it doesn't, a password reset that never arrives is a user you've quietly lost. Founders underrate this because it isn't a feature anyone asks for, yet it sits on the critical path of signup and checkout. Reach for a dedicated sending API early, get your domain authentication right, and then stop thinking about it; this is infrastructure you want boring and reliable, not clever.
Rule of thumb
If password resets are taking more than a minute to arrive across many users or for a sustained period, investigate the delay as a potential production issue.
