How to handle email deliverability for SaaS
How to handle email deliverability for SaaS
Email deliverability for SaaS is an engineering problem, not a marketing one. Split transactional and marketing mail onto separate sending subdomains, warm new IPs on a scripted ramp from 50/day to your steady-state volume over 4 to 6 weeks, and hold spam complaints under 0.1% with engagement-based segmentation and aggressive list hygiene. Everything else is downstream of those three decisions.
Why deliverability is now an engineering problem in 2026
Two years ago, deliverability lived inside the marketing tool. Someone in growth would notice open rates dipping, file a ticket, and an engineer would check DNS records. Those days are over.
In February 2024, Gmail and Yahoo published bulk-sender rules with a 0.3% hard complaint cap, mandatory SPF, DKIM, and DMARC, and a one-click List-Unsubscribe header on promotional mail. The 5,000-emails-per-day threshold to personal Gmail or Yahoo accounts is the trigger.
In November 2025, Gmail flipped the enforcement switch. What used to be a 4xx soft-deferral (try again, your mail might still arrive) became a 5xx hard rejection. Microsoft followed in May 2025 with the now-familiar 550 5.7.515 bounce. Drift in your sending posture no longer means "your open rate dipped." It means your password reset emails are bouncing.
That is a code path. It belongs to engineering.
The default approach (and why it breaks at scale)
Most early-stage SaaS apps wire one ESP (usually Postmark, SendGrid, or Resend) to one shared IP, send everything through one verified domain, and call it done. It works.
Until it doesn't. The failure mode is reliable: a marketing campaign goes out with a stale list, complaints spike, the shared IP's reputation drops, and now password resets are landing in spam. Latency to inbox climbs from under a minute to 5 to 20 minutes. Support tickets pile up. Whoever runs growth is sure something is wrong with the platform; whoever runs the platform is sure something is wrong with growth.
Both are right. The single shared IP collapsed two workloads with very different risk profiles into one reputation score.
Split transactional from marketing on separate sending domains
The first non-trivial decision is domain segmentation. Don't send everything from noreply@yourapp.com.
Use a pattern like:
mail.yourapp.comfor transactional: receipts, password resets, account notifications, shipping confirmations, magic links.news.yourapp.comfor marketing: product updates, drip campaigns, weekly digests, re-engagement flows.
Each subdomain gets its own DKIM selector (so a key compromise on one doesn't taint the other), its own SPF record, and ideally its own ESP account or at least its own IP pool. Your DMARC policy on the apex domain stays at p=quarantine or p=reject; the subdomains inherit alignment.
In practice, this looks like Postmark for transactional (their architecture is biased toward speed and reputation isolation) and SendGrid, Customer.io, or Loops for marketing. Two ESPs cost more in dollars but cost less in 3am pages. If you're still picking your stack, our breakdown of the best email service for SaaS compares the major vendors on transactional latency, marketing tooling, and reputation isolation.
This separation is the single most-important architectural choice for deliverability. Everything else is tuning.
Run the IP warm-up as a cron, not a calendar reminder
Whether you're rolling out a new dedicated IP or moving onto a fresh ESP after an outage, the warm-up schedule is non-negotiable.
The standard ramp:
| Week | Daily volume range | Daily ramp | Audience |
|---|---|---|---|
| 1 | 50 to 500 | ~30-50% | Last-30-day engaged only |
| 2 | 500 to 2,000 | ~30-50% | Last-60-day engaged |
| 3 | 2,000 to 7,000 | ~30-50% | Last-90-day engaged |
| 4 | 7,000 to 30,000 | ~30-50% | Full verified list |
| 5-6 | 30,000+ | Settle | Steady-state |
Two non-obvious rules. First, split the daily volume across all major ISPs (Gmail, Yahoo, Microsoft, Apple, Comcast). Don't warm up Gmail Monday and Yahoo Tuesday; spread evenly. Each ISP scores you independently. Second, never double overnight. A 30-50% daily increase is the ceiling.
This belongs in code, not a Notion doc. A simple cron that reads from a warmup_schedule table, picks today's target, queries your engaged-user view, and feeds the batch to your ESP's send API will outperform any human running the ramp manually. If you hit a soft-bounce wall (4xx responses spike past 5%), the cron should hold yesterday's volume for 48 hours rather than push through.
When you're moving from MVP traffic to production-grade volumes, the warm-up cron is one of those small pieces of infrastructure that pays for itself the first time it saves you from a bounce storm. The same lessons from scaling an MVP to production-ready apply here: instrument before you scale.
Dedicated vs shared IP: when each makes sense
The question every founder asks at the wrong time. Quick rule:
| Volume per month | IP strategy | ESP examples | Monthly cost |
|---|---|---|---|
| Under 100k | Shared | Postmark, Resend | $10-50 |
| 100k to 500k | Shared, reserved pool | SendGrid Pro, Mailgun | $80-300 |
| 500k to 5M | Dedicated, single | SendGrid, Mailgun, Postmark | $300-1,500 |
| 5M+ | Multiple dedicated, txn/marketing split | SendGrid Premier, AWS SES | $1,500+ |
Under 100,000 sends a month, a dedicated IP hurts more than it helps. A cold dedicated IP has no reputation. Shared IPs at reputable ESPs ride on the reputation of all the other senders, most of which are well-behaved. You inherit their good standing for free.
Above 500k a month and you start to compete with other senders on the same shared pool for throughput. Above 5M, dedicated is mandatory and you should split transactional and marketing onto different dedicated IPs from day one.
Dedicated IP cost is small ($30 to $200/month at most ESPs). The real cost is the warm-up time. Plan it.
List hygiene as a continuous job, not a quarterly cleanup
Bounce processing has to happen on the webhook, not on a Friday cleanup script. Every ESP fires events: bounce.hard, bounce.soft, complaint, unsubscribe. Your app needs to consume those, write to a email_suppression table, and refuse to send to suppressed addresses. The whole loop should close in under 60 seconds.
Three rules that catch most issues:
- Hard-bounce once = permanent suppression. Don't retry. The address doesn't exist.
- Soft-bounce 5 times in 14 days = suppression. Distinguish "mailbox full" from "domain doesn't accept mail" if the ESP gives you that signal.
- Complaint = permanent suppression. No re-add ever. The recipient told a major ISP your mail is spam. Believe them.
Sunset policy is the next layer. A 90/180/365 cadence works for most SaaS:
- 90 days no engagement: drop from regular cadence, send a re-engagement campaign.
- 180 days no engagement: drop from marketing entirely, transactional only.
- 365 days no engagement: full suppression.
Bounce rate target under 2%. Complaint rate under 0.1%. If you can't hit those numbers, the list is the problem; no amount of authentication will save you.
Instrument what mailbox providers see
You can't fix what you can't measure. Three free tools every SaaS sender should wire up on day one:
- Google Postmaster Tools v2. Daily domain reputation, IP reputation, spam rate, authentication pass rate, encryption rate. The v2 API gives you JSON; pipe it into a daily cron, write to your DB, and alert in Slack on any metric crossing a threshold.
- Yahoo Sender Hub. Yahoo's equivalent, less polished, similar data. Worth the 30 minutes to set up if you have any Yahoo volume.
- Microsoft SNDS. Smart Network Data Services. Required if you send to Outlook, Hotmail, or Live addresses.
Inside your own database, track a 7-day rolling complaint rate per sending domain. That's your early-warning system. Mailbox providers update reputation slowly; your internal view sees the spike first.
The Postmaster v2 API has a generous quota (around 1,000 requests per day, far more than any SaaS needs). Build the integration once and it runs forever.
This is the kind of work an E2E test suite in Playwright doesn't cover, because the failure surface is your DNS, your ESP, and Google's spam filters, all moving independently. A weekly synthetic test (send a known message to a known mailbox, assert it lands in inbox not spam) catches drift that nothing else will.
BIMI, ARC, and the rest of the new alphabet
Three more acronyms worth knowing in 2026.
BIMI (Brand Indicators for Message Identification) puts your verified logo next to your name in the inbox at supporting providers (Gmail, Yahoo, Apple Mail). Real lift on open rates for B2C brands. Requires a Verified Mark Certificate (VMC) from DigiCert or Entrust at around $1,500/year, plus DMARC at p=quarantine or stricter. Worth it post-PMF if you have brand recognition. Skip pre-PMF.
ARC (Authenticated Received Chain) preserves authentication results across forwarding paths (Google Groups, university aliases, mailing lists). If a meaningful slice of your audience uses forwarding addresses, your DMARC failures will drop noticeably once your ESP supports ARC. Most major ESPs do by default in 2026; verify yours.
MTA-STS (and the related TLS-RPT) enforce TLS on the transport layer between mail servers. Cheap to deploy, takes an afternoon, signals technical maturity to receivers. Not a deliverability silver bullet but a hygiene checkbox.
When you can skip most of this
Be honest about your scope. If your SaaS is pre-launch sending under 500 emails a day from one IP, you do not need a warm-up cron, dedicated IPs, or BIMI. You need correct SPF, DKIM, DMARC at p=none initially moving to p=quarantine once your reports are clean, and a noreply@yourapp.com from address.
If you're transactional-only (no marketing list), the playbook collapses to: get authentication right, suppress hard bounces, monitor Postmaster Tools weekly, sleep at night. The aggressive list-hygiene and segmentation rules above target apps with real marketing volume.
If you're B2B with named contacts and personal outreach (think: an account executive emailing 30 prospects a day from firstname@yourapp.com), inbox placement is a relationship problem more than a reputation problem. The bulk-sender rules don't bite at that scale.
For everyone in between, the playbook above is the floor.
What to do this week
A concrete checklist, in priority order:
- Audit your sending domains. List every From: address your app emits. Group by transactional vs marketing.
- Verify SPF, DKIM, and DMARC. Use
digor a tool like MXToolbox. Move DMARC fromp=noneto at leastp=quarantine. (Our DKIM, SPF, and DMARC setup guide walks the DNS records line by line.) - Set up Google Postmaster Tools, Yahoo Sender Hub, and Microsoft SNDS. Verify ownership for every active sending domain.
- If you're at meaningful volume and still on a single shared IP for everything, plan the split: transactional on one ESP or pool, marketing on another. This is the single highest-impact architectural change you can make.
- Decide who owns the on-call alert. Deliverability without an owner becomes nobody's problem until it's everyone's.
This work isn't glamorous. But the half-life of a great onboarding flow drops to zero the day your password reset emails start landing in spam. A senior engineer can usually deliver the full audit, separation, and instrumentation rollout in one to two weeks. If you'd rather hand the whole rollout off, every engineer on Cadence is AI-native by default and the senior tier ($1,500/week) is sized exactly for this kind of two-week scoped infrastructure project. If you want a sanity check before scoping the work, run your stack through Ship or Skip for an honest grade on what to keep, replace, or rebuild.
Trying to ship deliverability fixes this sprint without pulling a backend engineer off product? Book a senior Cadence engineer for one week ($1,500), use the 48-hour free trial to scope the audit, and decide on Friday whether to extend. Replace the engineer next week with no notice if they're not landing it.
FAQ
How long does an IP warm-up take?
Four to six weeks for most SaaS apps reaching 30,000 to 100,000 sends per day. Eight weeks if you need 500,000+/day or you're moving to a previously-cold dedicated IP from a hot shared pool. Compress at your peril; mailbox providers score new IPs slowly on purpose.
Do transactional emails count toward Gmail's 5,000/day bulk-sender threshold?
Yes for the volume count, but transactional messages (password resets, receipts, shipping notifications, account alerts) are exempt from the one-click unsubscribe requirement. Authentication rules (SPF, DKIM, DMARC alignment) apply to all mail regardless of type.
Is BIMI worth the money?
Only if you have brand recognition recipients would notice in their inbox. The $1,500/year VMC plus the requirement to run DMARC at p=quarantine or stricter is not worth it for a pre-Series-A SaaS. Revisit post-PMF when brand recall actually moves open rates.
What spam complaint rate gets us blocked?
Gmail and Yahoo enforce a 0.3% hard cap. Stay below 0.1% to keep inbox placement reliable across providers. A single bad campaign can spike you above 0.3% for a weekly window, and Gmail's November 2025 enforcement change means that spike now produces 5xx hard rejections, not soft-deferrals you can sleep through.
Should we self-host email or use an ESP?
Use an ESP. Self-hosting requires reverse DNS, IP reputation management, an abuse desk, 24/7 incident response, and a relationship with each major ISP's postmaster team. The economics only work above roughly 10 million sends per month, and even then you still need a deliverability-focused engineer on staff.