Your SaaS password-reset email doesn't land in spam because your product is broken. It lands there because three DNS records are missing.
I've set up email deliverability for BookBed — the booking platform on Flutter + Firebase + Stripe — and for Pizzeria Bestek, a React + Supabase system where the order confirmation is the product's entire post-purchase moment. Each time, the actual DNS record setup took an afternoon. What took longer was figuring out why it wasn't working — because nothing in your application logs tells you when your SPF record exceeds 10 DNS lookups. Nothing pings you when your DKIM selector is misconfigured. The email just disappears.
This post covers the full production setup: SPF, DKIM, DMARC, subdomain strategy, provider selection, and the inbox warmup math nobody includes in the setup guides.
Does your SaaS actually need all three — SPF, DKIM, and DMARC?
Yes, and the answer hasn't been ambiguous since February 2024.
Google's bulk sender requirements — enforced for senders of 5,000+ messages per day to Gmail addresses — require DKIM authentication, a DMARC policy, and alignment between your sending domain and From: header. Microsoft followed for Outlook, Hotmail, and Live in May 2025. Non-compliant mail gets rejected at the SMTP level. Not filtered. Rejected. The EasyDMARC 2026 DMARC Adoption Report, which analyzed 1.8 million domains, found that only 52.1% had any DMARC record at all — and just 9% had both an enforcement policy and aggregate reporting configured. Fortune 500 is at 95% adoption. The rest of the SaaS ecosystem is lagging significantly.
The three records divide up the work differently:
- SPF (Sender Policy Framework): publishes which IPs and services are authorized to send from your domain. Receiving servers check the envelope sender against this list at delivery time.
- DKIM (DomainKeys Identified Mail): adds a cryptographic signature to each email. Survives forwarding and relay. Tied to your From: domain via a DNS TXT record with a named selector.
- DMARC: sits above both. Tells receiving servers what to do when SPF or DKIM fails —
p=none(log and report, take no action),p=quarantine(mark as spam),p=reject(block at the server).
Start at p=none with a rua reporting address. You need at least two weeks of aggregate reports before you know whether all your legitimate senders are properly aligned. Jump straight to p=reject without that visibility and you will block your own emails. This happens — a SaaS I audited earlier this year had copied a "best practice" DMARC config from a blog post and deployed it to production without testing alignment on their transactional subdomain.
Actually, that understates the problem. A misaligned DKIM selector combined with p=reject means users never receive a password reset. No error in your app. No bounce in your logs. Gmail rejects the email and the user just waits.
The SPF 10-lookup limit will break your email silently
The SPF specification caps DNS lookups at 10 per validation attempt. Exceed that and receiving servers return a permerror, which DMARC treats as an authentication failure. Your emails fail.
This breaks silently. Add Resend for transactional sends, Mailchimp for campaigns, Google Workspace for internal email, Intercom for support, and a CRM — you're past 10 lookups. Nothing in your DNS panel warns you. The only signal appears in DMARC aggregate reports, which you haven't checked yet because you set up p=none and moved on.
Tuesday afternoon, 3pm. A user reports they never received their password reset. You check your sending provider dashboard — delivered. You check the spam folder — not there. Silence.
The Redsift SPF lookup guide covers the mechanics in detail. The practical fix for most SaaS teams:
- Check your current count with MXToolbox SPF checker. Delete includes for services you've stopped using — there are usually two or three dead ones.
- Move each sending stream to its own subdomain. Each subdomain gets its own SPF record with its own 10-lookup budget, solving the problem at the architecture level.
- If you genuinely need more than 10 includes under a single domain, use a dynamic SPF flattening service rather than a static one. Cloud providers rotate their sending IPs regularly, and a static flat record goes stale without warning.
The subdomain split also happens to solve a different, more common problem.
Why transactional and marketing email need different sending domains
A failed password reset is a support ticket. A spam complaint from a newsletter is a reputation event. Mixing them on the same sending domain means the reputation of your campaign sends drags down your transactional delivery.
| Subdomain | Use case | Provider |
|-----------|----------|----------|
| mail.yourdomain.com | Password resets, receipts, booking confirmations | Resend or Postmark |
| marketing.yourdomain.com | Campaigns, drip sequences, newsletters | Loops, Mailchimp, or Brevo |
| reply.yourdomain.com | Support inbound and outbound | Help desk tool |
Each subdomain gets its own SPF record, its own DKIM selector, and its own DMARC policy. The transactional subdomain reaches p=reject quickly because the sending stream is tightly controlled and the volume is predictable. The marketing subdomain stays at p=quarantine longer while you monitor complaint rates through Google Postmaster Tools.
On the Pizzeria Bestek build, order confirmations routed through mail.pizzeriabestek.com with a Resend API key scoped only to transactional sends. Campaign-adjacent sends used a separate key and domain. The order confirmation inbox placement never degraded because the reputation was isolated.
For teams under 500 users, a single transactional domain works until you add marketing sends. The moment you do — split them before the first campaign goes out. Reputation damage from a marketing send is hard to recover on a shared domain.
How to choose between Resend, Postmark, and SendGrid in 2026
Three providers handle most SaaS transactional email. They are not interchangeable.
| Provider | Best for | Free tier | Paid starts | Breaks down when | |----------|----------|-----------|-------------|------------------| | Resend | Next.js + React Email workflow | 3,000/month | $20/month for 50k | High volume on shared IPs without a dedicated IP add-on | | Postmark | Mission-critical delivery (bookings, payments, healthcare) | None | $15/month for 10k | You also need marketing sends from the same provider | | SendGrid | Transactional + marketing combined in one platform | 100/day | $19.95/month for 50k | Shared infrastructure and slow support response at scale |
Postmark's separation of transactional and broadcast infrastructure is why their inbox placement consistently stays above 99%. They refuse marketing senders on transactional IP pools. That's the architectural decision, not a marketing claim — and it's why a booking confirmation sent through Postmark lands in under 10 seconds on average.
For the SaaS MVP stack on Next.js + Supabase, Resend is the natural fit. The Next.js + Resend integration guide covers API key scoping, React Email component workflow, and connecting your sending logic to the rest of your event architecture. For projects where a missed email is a missed transaction — as it is on BookBed where a missing booking confirmation triggers a support request immediately — Postmark is worth the cost differential.
The BookBed case study covers the full architecture. Booking confirmations route through a dedicated sending domain with its own DKIM and DMARC configuration. An email provider degradation event doesn't take down the booking flow because the sending infrastructure and business logic are decoupled and separately monitored.
What list hygiene actually means before you send
A new sending domain has no reputation. Zero — not suspicious, just unknown to the filters.
Send 200 emails on day one and spam filters have no signal to evaluate you against. They guess conservatively. That means inbox placement rates well below what you'll see after six weeks of consistent, low-volume sending.
The warmup approach: ten to twenty emails in week one to addresses you control or that are known-good confirmed opt-ins. Increase volume by 30-40% per week. After six to eight weeks you have an established baseline the filters can work from.
Before any list import: run it through a validator. Hard bounces are the fastest path to a domain blacklist — email to an address that doesn't exist registers as a clear signal of bad list hygiene. Spam trap addresses look like real addresses; a hygiene pass before first send removes most of that risk.
Target steady-state: under 0.5% bounce rate, under 0.05% complaint rate. These are achievable from day one if you're only mailing people who confirmed their address. Google Postmaster Tools is free and surfaces domain reputation, spam rate, and authentication compliance in one place. Set it up before your first real send.
If you're building the full SaaS email stack — notifications, onboarding sequences, and receipt delivery — the SaaS MVP stack guide has the full picture of how these services connect to the rest of your architecture. Start there, then come back to tune deliverability once you have volume data.