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) so marketing experiments can never poison your transactional reputation. - 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 built specifically for transactional mail, signup confirmations, password resets, receipts, and pairs with its open-source React Email library so you build email templates the same way you build your app's UI.
- Resend's core strength is transactional and product email, "verify your email", "here's your receipt", with a clean API and its open-source React Email templates, so those system messages go live fast without heavier legacy tooling. (It has since added Audiences and Broadcasts for marketing email, but transactional is where most apps start.)
- 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 a password reset takes more than a minute to arrive in the inbox, treat it as a production outage.