# SaaS Email Deliverability

> Keep product and marketing email in the inbox: subdomain split, SPF, DKIM, DMARC, one click unsubscribe, the 0.3 percent spam ceiling and a warmup plan.

Source: https://saas-marketing.net/guides/saas-email-deliverability/
Topic: SaaS Email Marketing
Type: guide
Published: 2026-09-11
Last updated: 2026-09-11
Publisher: SaaS Marketing (saas-marketing.net)
License: CC BY 4.0. Quote or republish with attribution and a link to https://saas-marketing.net/guides/saas-email-deliverability/

## Short answer

SaaS email deliverability depends on separating mail classes before reputation becomes a problem. Send product and transactional mail from one subdomain, lifecycle and marketing from a second, and cold outbound from a different root domain entirely. Authenticate all of them with SPF, DKIM and a DMARC record moved from p=none to p=reject over a quarter. Since February 2024 Google and Yahoo require authentication, RFC 8058 one click unsubscribe and a spam complaint rate under 0.3 percent from bulk senders, with 0.1 percent as the working target.

## Key takeaways

- Product email and marketing email must not share a sending subdomain, because one bad campaign can filter your password resets.
- Google and Yahoo have required SPF, DKIM, DMARC and one click unsubscribe from bulk senders since February 2024.
- Keep the Gmail spam complaint rate under 0.1 percent. The published 0.3 percent figure is the ceiling, not the target.
- Move DMARC from p=none to p=quarantine to p=reject over about 90 days, reading aggregate reports at every step.
- A new sending domain needs four to six weeks of graduated volume before it can carry a full campaign.
- Recovering from a blocklisting takes weeks of lost activation revenue. Splitting domains first costs an afternoon.

---

The worst deliverability incident in a SaaS company never starts in the marketing team's reports. It starts with a support ticket that says the password reset email never arrived, then three more, then a spike in failed logins, and two days later somebody works out that a 40,000 recipient campaign sent on Tuesday moved the whole domain's reputation and took the product mail with it. Activation stops. Nobody can sign up. The campaign performed fine.

## Why SaaS has a deliverability problem most senders do not

An ecommerce brand sends marketing email and order confirmations. If the marketing suffers, revenue suffers. A SaaS company sends marketing email and mail that is load bearing for the product: verification links, password resets, invite emails, payment failure notices, alerts, digests, two factor codes. When reputation degrades, the product stops working for new users, and the damage lands on activation rather than on a campaign report.

That coupling is what makes the ordinary advice insufficient. Cleaning your list and writing better subject lines is fine, but it does not address the structural issue, which is that two entirely different mail classes with entirely different engagement profiles are sharing one reputation. A password reset gets opened by 95 percent of recipients within minutes. A product update newsletter gets opened by 22 percent of recipients, and a slice of them mark it as spam. Averaged together on one domain, the newsletter drags the reset down.

The split between those classes and how to treat them differently is covered in [transactional vs marketing email](/comparisons/transactional-vs-marketing-email/). The rest of this page is the infrastructure that makes the split real rather than conceptual.

**0.3%** Gmail and Yahoo spam complaint ceiling for bulk senders since February 2024, with 0.1 percent as the practical working target

## The subdomain architecture: three mail classes, three reputations

Mailbox providers assess reputation substantially at the subdomain level, which means subdomains are the cheapest isolation you can buy. Three streams, three subdomains, and the root domain kept clean for human mail.

The DNS side is short. For a marketing subdomain on a typical ESP you publish a TXT record for SPF, one or two CNAMEs for DKIM signing, and a DMARC record at the subdomain or inherit the organisational one:

```
news.yourdomain.com. TXT "v=spf1 include:sendgrid.net ~all"
s1._domainkey.news CNAME s1.domainkey.u123.wl.sendgrid.net
s2._domainkey.news CNAME s2.domainkey.u123.wl.sendgrid.net
_dmarc.news TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s"
```

Two constraints catch people. SPF allows a maximum of 10 DNS lookups before it fails, per RFC 7208, and stacking four vendor includes on one record blows past that quickly; a single subdomain per vendor avoids the problem entirely. And the visible From address has to align with the authenticated domain, so sending as hello@yourdomain.com while authenticating news.yourdomain.com fails DMARC alignment under strict settings. Send as hello@news.yourdomain.com or relax alignment deliberately, not by accident.

Separating streams takes an afternoon of DNS work and a week of changing From addresses. Recovering a root domain after a blocklisting takes weeks, during which new signups cannot verify their email. Do this while nothing is wrong, because the fix is unavailable exactly when you need it most.

## SPF, DKIM and DMARC, and the move from p=none to enforcement

Authentication is three records doing three jobs. SPF says which servers may send for your domain. DKIM cryptographically signs each message so tampering is detectable. DMARC tells receivers what to do when one of the first two fails, and asks them to report what they saw.

**Getting to DMARC enforcement in about 90 days**

Two opinions worth stating. Get to p=reject rather than stopping at quarantine, because a SaaS domain that can be spoofed is a phishing surface aimed at your own customers, and support will eventually deal with the consequences. And treat BIMI as a later nicety: it needs DMARC at enforcement plus a verified mark certificate that costs over a thousand dollars a year, and the logo in the inbox is worth far less than the enforcement itself.

## What Google and Yahoo have required since February 2024

Both providers introduced bulk sender requirements in February 2024 that apply to anyone sending more than 5,000 messages a day to personal Gmail or Yahoo accounts. Microsoft followed with comparable requirements for consumer Outlook addresses in May 2025. The rules are not guidance.

| Requirement | What it means | How to verify |
|---|---|---|
| SPF and DKIM | Both must pass, not either | Send to a Gmail address, open show original, check both say PASS |
| DMARC record | At least p=none published on the sending domain | Query _dmarc.yourdomain.com with dig or an online checker |
| Domain alignment | The visible From domain matches the authenticated domain | Show original in Gmail lists the aligned domain explicitly |
| One click unsubscribe | List-Unsubscribe and List-Unsubscribe-Post headers per RFC 8058 | Gmail shows an unsubscribe link next to the sender name |
| Honour opt outs in 2 days | Removal processed within 48 hours | Test it yourself on a real address, not on a seed account |
| Valid forward and reverse DNS | The sending IP resolves both ways | Your ESP handles this on shared IPs; check it yourself on dedicated ones |
| Spam rate under 0.3 percent | Measured by Google, visible in Postmaster Tools | Google Postmaster Tools, checked weekly, not monthly |
| TLS in transit | Connections encrypted | Standard at every reputable ESP |

The one that catches SaaS teams is one click unsubscribe. RFC 8058 requires a header based unsubscribe that Gmail can action without the recipient visiting your site, and it is separate from the unsubscribe link in your footer. Most modern platforms set it automatically for marketing streams. Most homegrown product mailers do not set it at all, which is fine for genuinely transactional mail and a problem the moment a product digest crosses into promotional territory.

A weekly product digest with a feature announcement at the bottom is marketing mail wearing a transactional label. Give it a one click unsubscribe, send it from the marketing subdomain, and respect opt outs. The classification a provider applies is based on content, not on which system sent it.

## The 0.3 percent ceiling and why 0.1 percent is the number that matters

Google's published threshold is 0.3 percent, and treating that as a target is the most common misreading in the whole specification. Filtering tightens long before the ceiling. Practitioners watching Postmaster Tools consistently report visible inbox placement damage in the 0.15 to 0.25 percent band, which is why the working target should be under 0.1 percent.

The arithmetic makes the risk concrete. On a 50,000 recipient send, 0.3 percent is 150 complaints. Fifty complaints, one tenth of one percent, is the line you actually manage to. A single reactivation campaign to a list nobody has mailed in eight months can produce that from a few thousand recipients on its own.

| Segment being mailed | Realistic complaint rate | What to do about it |
|---|---|---|
| Active users, last 30 days | Under 0.02% | Mail freely, this is your reputation buffer |
| Inactive 90 to 180 days | 0.05% to 0.15% | Mail sparingly and separately, never in the same send as a launch |
| Inactive over 12 months | 0.2% to 1%+ | Do not mail. Suppress, or run a tiny re-permission test at a few hundred addresses |
| Purchased or scraped lists | Unbounded | Never on any domain connected to the product |

Two operational rules follow. Send the warmest segments first in any large campaign, because early positive engagement signals shape how the rest of the send is treated. And put a hard stop in the workflow: if complaints cross 0.1 percent during a send, pause the remaining batches rather than finishing and analysing afterwards. Bounce and complaint hygiene like this is what actually moves [sender reputation](/glossary/sender-reputation/), far more than copy or send time.

## Warming a new sending domain without torching it

A brand new subdomain has no reputation, which providers treat as suspicious rather than neutral. Volume ramps slowly and engagement quality matters more than the numbers.

| Week | Daily volume | Who to send to | Pause if |
|---|---|---|---|
| Week 1 | 50 to 200 | Users active in the last 7 days only | Bounce rate above 2% or any complaint cluster |
| Week 2 | 500 to 2,000 | Active in the last 30 days | Complaints above 0.1% on any single send |
| Week 3 | 5,000 to 10,000 | Active in the last 90 days | Open rates fall sharply against week 2 |
| Week 4 to 6 | Step to full volume | Full engaged list, still excluding dormant segments | Postmaster Tools domain reputation drops below High |

Four to six weeks is the realistic schedule for a marketing subdomain. Transactional streams warm considerably faster because the engagement is extreme: verification emails are opened almost universally within minutes, and that signal builds reputation quickly. This is why moving product mail to its own subdomain is low risk and moving marketing is the part that needs patience.

If you are migrating an existing programme rather than starting fresh, run both domains in parallel for two to three weeks, shifting a rising percentage of traffic, instead of cutting over on a Monday. And do not warm on a dedicated IP unless you can sustain the volume: below roughly 100,000 messages a month, a shared IP pool at a reputable ESP with clean domain hygiene beats a dedicated IP that goes quiet for six days between sends.

## The monitoring stack that tells you before support does

Three sources, checked on different cadences, cover almost everything.

**Monitoring that catches problems in days rather than weeks**

The synthetic transactional test is the one that separates a SaaS deliverability programme from a generic one. Password reset inbox placement is a production dependency, and a Gmail filtering change that pushes it to spam is an incident, not a marketing metric. Wire it to the same alerting as your uptime monitor and give it an owner in engineering.

Postmaster Tools has a real limitation worth knowing: it only reports on personal Gmail traffic, needs a few thousand daily messages to a domain before charts populate, and shows nothing at all about Microsoft 365 corporate tenants, which is where most B2B SaaS mail actually lands. Fill that gap with seed testing and with your own engagement data, since a sudden drop in open rate from one recipient domain is usually filtering, not disinterest.

## What this costs and what it does not fix

Budget a week of an engineer's time for the DNS and authentication work, plus a month of calendar time for the DMARC ramp, plus whatever your ESP charges. Tooling is modest: DMARC report parsing runs from free to about $200 a month at small scale, seed testing around $50 to $150 a month, and Postmaster Tools costs nothing. The expensive part is attention, and the reason it gets skipped is that nothing appears broken until it is badly broken.

Be clear about the limits. Perfect authentication does not get bad mail delivered. If your onboarding sequence sends six emails in four days to people who signed up for a free tool and never returned, complaints will rise no matter how clean the DNS is. Deliverability infrastructure protects good sending practice; it cannot substitute for it, which is why the behavioural targeting behind a [behavioral email trigger](/glossary/behavioral-email-trigger/) matters as much as the records.

Corporate filtering is the other blind spot. Mimecast, Proofpoint and Microsoft Defender make decisions on grounds that have little to do with SPF and DKIM, including link reputation, attachment policy and internal allowlists. B2B SaaS mail lands in those environments constantly and neither Postmaster Tools nor Gmail seed tests will tell you what happened. When a large customer reports missing notifications, the answer is usually their security gateway, and the fix is asking their IT team to allowlist your sending domain.

And none of this applies cleanly to cold outbound, which operates under different constraints on separate infrastructure. That is its own discipline, covered in [outbound email infrastructure and deliverability](/guides/outbound-email-deliverability/). Keep it off the domain that sends your [dunning email](/glossary/dunning-email/) and your password resets, permanently.

## The order to do this in

Do it in this sequence, because each step depends on the one before it and doing them out of order wastes the warmup.

Split the streams first. Move product mail to its own subdomain this week, and marketing to a second subdomain over the following month with a proper warmup. Authenticate everything with SPF and DKIM as you go, publish DMARC at p=none the same day, and read the aggregate reports before touching the policy. Get to p=reject within a quarter.

Then set the operating rules: one click unsubscribe on every marketing stream, a suppression list that no system can bypass, dormant segments excluded by default, and a hard pause at 0.1 percent complaints. The compliance side of that, including consent records and regional requirements, is laid out in the [SaaS email compliance checklist](/checklists/saas-email-compliance/).

Finally, measure what the inbox is worth to you. Inbox placement is upstream of every activation number in the programme, and the relationship between delivered lifecycle mail and conversion is quantified in the [trial conversion and email study](/research/trial-email-conversion-study/). The rest of the sequences that depend on all this plumbing sit in the [SaaS email marketing](/saas-email-marketing/) hub, including the upgrade flows in [freemium to paid upgrade emails](/playbooks/freemium-to-paid-upgrade-emails/), and none of them work if the mail does not arrive.

## Frequently asked questions

### Should SaaS companies use a subdomain for sending email?

Yes, and more than one. Transactional and product mail belongs on a dedicated subdomain such as mail.yourdomain.com, lifecycle and marketing on a second such as news.yourdomain.com, and cold outbound on a separate root domain entirely. Mailbox providers assess reputation largely at the subdomain level, so this contains damage from any single stream instead of spreading it across all of them.

### What are the Google and Yahoo bulk sender requirements?

Since February 2024, senders of more than 5,000 messages a day to personal Gmail or Yahoo accounts must authenticate with SPF and DKIM, publish a DMARC record with at least p=none, align the visible From domain with the authenticated domain, offer RFC 8058 one click unsubscribe honoured within two days, keep valid forward and reverse DNS, and hold spam complaints below 0.3 percent.

### What is a good spam complaint rate for SaaS email?

Under 0.1 percent as measured in Google Postmaster Tools. The 0.3 percent figure Google publishes is an enforcement threshold, and traffic gets filtered well before it is reached. A complaint rate that drifts above 0.1 percent on a single campaign is a signal to pause that segment rather than to argue about subject lines.

### How do you set up DMARC for a SaaS company?

Publish SPF and DKIM for every sending source first, including your ESP, your product mail service and any CRM that sends on your behalf. Then add a DMARC TXT record at _dmarc.yourdomain.com starting with p=none and an rua address for aggregate reports. Read those reports for two to four weeks, fix every failing legitimate source, then move to p=quarantine and finally p=reject.

### How long does it take to warm up a new email sending domain?

Four to six weeks for a marketing subdomain sending meaningful volume. Start at roughly 50 to 200 messages a day to your most engaged recipients, increase by about 50 percent every two or three days if complaint and bounce rates stay clean, and pause the ramp whenever they do not. Transactional streams warm faster because engagement is much higher.

### Can marketing email hurt transactional email deliverability?

Yes, and this is the specific risk SaaS carries. If a promotional campaign generates complaints on a shared sending domain, filtering tightens across everything sent from that domain, including password resets, invoices and payment failure notices. Users then cannot get into the product, support volume rises, and the cause is invisible from inside the marketing tool.

### What is the difference between domain reputation and IP reputation?

IP reputation attaches to the address the message was sent from and matters most on dedicated IPs at high volume. Domain reputation attaches to the sending domain and now carries more weight at most mailbox providers, which is why subdomain separation works. Below roughly 100,000 messages a month, shared IPs with good domain hygiene usually outperform a dedicated IP.