guides
Email deliverability for SaaS products
SPF, DKIM, DMARC — and why your transactional email is landing in spam even though you did everything the docs said.
Sending email is easy. Sending email that the recipient actually sees is not. Every new SaaS team ships their first signup flow and then spends two weeks debugging why nobody is getting the confirmation email.
The three DNS records#
- SPF (TXT record) says which servers are allowed to send for your domain.
- DKIM (TXT record) cryptographically signs outgoing messages.
- DMARC (TXT record) tells receivers what to do when the other two fail.
All three must be set up correctly. One of the three is not enough. Two of the three is not enough.
The from-address trap#
Gmail and Outlook get suspicious when your from-address domain differs from your DKIM signing domain. Sending as no-reply@your-app.com signed with a default your-provider.com key? That's a deliverability handicap. Set up a custom sending domain and sign with it.
Warm up the domain#
A new sending domain with no history sends its first 10k emails straight to spam. Warm it up: start low (100/day), double weekly, only ramp after seeing good open rates on a consistent basis. Dedicated IPs are worse — shared pools at Postmark, Resend, and AWS SES are better-warmed than anything you'll build in six months.
Separate transactional from marketing#
Different sending subdomains. mail.your-app.com for transactional (password resets, receipts). news.your-app.com for marketing. When your marketing team sends a newsletter that nobody reads, it shouldn't hurt the deliverability of critical password reset emails.
Test with mail-tester.com#
Send one email to their free address, get a 10-point report card on SPF, DKIM, DMARC, content, and authentication in 60 seconds. Faster feedback than any other tool in this space.