Email marketing for SaaS: your product sends half of it.

Key takeaway

Email marketing for a SaaS product is the marketing mail a software company sends its own signups, trial users and customers, arranged around where each account sits in the product. The difference isn't the copy. The product emits its own mail, so two systems carry three streams, and the middle one, promotional mail fired by a product event, belongs to neither tool while sharing one domain reputation. I'd start at dunning: eight retries across two weeks.

What email marketing for a SaaS product actually covers.

Email marketing for a SaaS product is the marketing mail a software company sends its own signups, trial users, free users, and paying customers, arranged around where each account sits in the product rather than around a campaign calendar.

What it leaves out is that the copy isn't what makes SaaS email different. A SaaS product emits its own email. Half the program is triggered by an event in a database and the other half by somebody choosing a date, and the receiving mail server judges both halves as one sender on one domain.

I've watched a team ship a careful six-step onboarding sequence out of a marketing tool and then find password resets queued behind it, arriving forty minutes late to people sitting on a login screen. Both tools sent from the same domain, and the receiving side judges the domain rather than the tool: the campaign drew enough temporary failures that the password resets sat in their own tool's retry backoff behind it.

Every guide on the subject hands over an inventory of email types instead: welcome, trial expiring, upgrade, product education, re-engagement. The inventory is fine, and it's the easy half. It tells you nothing about which system sends which, and that's the decision this page is about.

Building the actual infrastructure for these campaigns requires serious engineering. The reality of developing marketing platforms is stark. The truth surfaced on QA Selling Online. I found that "the MVP bar turns out is much, much higher than you think" when writing this software. You cannot just throw together a basic tool.

The two systems, and the one reputation they share.

Most SaaS companies run two sending systems without ever deciding to. The transactional one came with the product, usually an API an engineer picked in week one. The marketing one arrived later, with the first marketer. Between them they carry three streams, not two.

The middle stream is triggered like transactional mail and reads like marketing, so it's the one both teams claim and neither owns.

The receiving side has already ruled on the question. Google's sender guidelines say messages of the same category should have the same From: email address, and give sales receipts, promotional content, and account notifications as three separate categories. The same document scopes one-click unsubscribe to marketing messages and subscribed messages, which is the line between the two streams drawn by the party that enforces it.

One-click unsubscribe itself is defined by RFC 8058: a List-Unsubscribe-Post header carrying List-Unsubscribe=One-Click, covered by the message's DKIM signature, so the receiver can tell it's really yours. The RFC says what the mechanism is. Google decides which of your messages owe it.

Separating the streams is a sending decision rather than a copy decision, and most teams make it once, by accident, when they pick their first tool. Once the newsletter and the receipt leave from the same address, they share a reputation, and a bad launch send is paid for by password resets three days later.

The program, by lifecycle stage.

Arrange the program by where the account is, not by what the email is called. Each stage has one job and one event that ends it, and a stage whose ending event you can't name is a newsletter with a theme on it. Five stages cover a normal SaaS, and the order is the order an account moves through them.

Four of those five stages start with something only your product knows: an account created, a feature used for the first time, a threshold crossed, a session that stopped happening. Acquisition is the one that begins outside the product, and it's the stage a marketing tool was actually designed for. That ratio is worth sitting with, because it's the whole argument about where a SaaS email program should live.

The list is the easy part. Which system sends each stage, and what happens when a stage's trigger is a payment event rather than a product event, is the hard part.

Behavioral data turns a generic broadcast into a relevant message. We proved this early on with our own custom software. The platform we outlined on SaaS District took in user actions to trigger specific campaigns. This basic setup quickly "became our second most valuable channel as a sales tool" for the business.

The dunning email, and why most SaaS teams get it wrong.

A dunning email is the message that goes out when a subscription payment fails. It recovers revenue somebody already agreed to pay.

A card expires or a bank declines, the charge fails, and an account that fully intended to keep paying becomes a churn event nobody chose. Recovering it isn't a campaign with a send time, because the deadline was set somewhere else. The billing system's retry schedule is that deadline.

In Stripe, invoice.payment_failed is the webhook that fires on the failure and again on each retry. Smart Retries can be spread over a week, two weeks, three weeks, a month, or two months, and Stripe's documentation on automated payment retries gives 8 tries within 2 weeks as the recommended default. When recovery fails, the subscription moves to canceled or unpaid, or stays past_due, according to a setting somebody chose long before the card broke.

Read that as a brief and the sequence writes itself. The first message goes near the first retry, while a stale card is still the only problem. The last goes before the status transition, because after it the account is a support ticket rather than a subscriber.

I've seen this fail the same way more than once, and it's never the copy. The dunning sequence lives in the marketing tool, the retries live in the billing system, and the two never speak. So the mail goes out on days two, five, and nine because somebody picked those days in a flow builder. Half of it lands after the subscription is already canceled, and the rest asks a customer to update a card that went through yesterday.

Can you put an upsell in a receipt?

Every SaaS asks this eventually, usually right after somebody looks at the open rates. Receipts get opened, so why not put the upgrade offer in one? The answer isn't a matter of taste, and two things decide it.

A mixed message is read as a promotion when either of these is true, and it's the reader doing the reading.

1. A recipient reasonably interpreting the subject line would conclude the message contains a commercial promotion.
2. The transactional content doesn't appear, in whole or in substantial part, at the beginning of the body of the message.

That test is precise enough to implement in a template, and the mailbox providers apply their own version of it: marketing mail is what needs a one-click unsubscribe header, and a receipt that reads as marketing is marketing. Two message types do most of the work for a software company and neither is a promotion: a notice about a change to the account's terms, features or standing, and delivery of something the customer already pays for.

So a receipt that also announces 20% off the higher tier has probably stopped being a receipt. One whose subject line is the invoice number, whose first screen is the charge, and which mentions further down a feature the customer just paid for, has not.

Getting it wrong costs you the full set of obligations a commercial message carries, and the expensive one is the working unsubscribe. You don't want an unsubscribe link on a password reset. The day somebody clicks it is the day they can't get into your product and can't be told why.

Measure the sequence on activation, not on opens.

Most senders need a benchmark because they can't see what happened after delivery. A SaaS company is the rare exception, because the outcome it cares about is an event in its own database. The onboarding sequence either moved the activation rate or it didn't, and you can settle it without knowing what a good open rate is for somebody else's audience.

Pick the event that means the product worked for that account: the first project created, the first teammate invited, the first API call from production, the first invoice sent. Then compare the accounts that got the sequence against the ones that didn't, or against the same cohort a month earlier. The number is yours, it's about your product, and nobody can quote a different one at you. I ran a version of this comparison once, on a personalized recommendation feature rather than onboarding, and it held up against the real number the same way: it accounted for more than 10% of revenue, not 10% of opens.

The usual alternative is softer than it looks. An open is a remote image loading, and Apple Mail's Protect Mail Activity downloads remote content in the background, regardless of whether you engage with the email. So part of your open rate is a machine, and that part moves with your audience's device mix rather than with anything you wrote. Clicks are firmer and replies firmer still, and both stand in for something you could measure directly.

Activation is only measurable if the product reports the event back to whatever sends the mail. Where the activation data sits in the product database and the sequence sits in a marketing tool that knows an email address and a signup date, the measurement becomes a quarterly export and a spreadsheet. That's a plumbing question rather than a marketing one, which is where all four of these arguments end up.

Revenue is the only metric that justifies the effort of sending these messages. We built our own dashboard to track this exact conversion. We looked at our own data on SaaS District and saw we were "getting 8% of our sales through email" as of September 2020. The goal is always to push that baseline higher.

Running both halves from one place.

Four arguments, one requirement. The streams have to be separated and are judged together, the sequences are triggered by product events, the dunning window is set by the billing system, and the metric lives in the product database. Every one of those asks the same thing twice: whatever sends the email has to see the event, and something other than a person clicking has to act on it. A dashboard-first tool can buy the first half with an integration. The second isn't something you add later, because the screen is the interface and every flow still ends at somebody's cursor.

Nitrosend specializes in email, and it's built the opposite way round from a dashboard with an API added later. It's MCP-first: every capability is an API endpoint and an MCP tool before it's a screen, so a campaign, a flow, or a segment is something an agent does rather than something a person clicks. The route from a product event to the mail is that agent rather than a native event pipeline: the same agent that can read your database or your billing system calls Nitrosend as a tool, so nothing has to be exported into a marketing platform first. BYO sending keys are available on Pro and above, covering Amazon SES, Resend, Postmark, Mailgun, and SendGrid, which matters if your transactional mail already leaves through one of them.

If your product emits its own email, the two halves already share a domain, and one of them is being run from a tool that can't see a single product event. Start on the free tier: 8,000 emails to get going, then 500 a month, unlimited contacts on every plan, and full MCP, API, and CLI access. No credit card.

Combining marketing and transactional sends into a single product looks easy on paper. We fell for this trap ourselves. Our initial timeline on Funny Business assumed a quick launch. The reality required "18 months of like hardcore dev later" before we had a functional product.

Related reading

• Email Deliverability Best Practices That Actually Matter
• Shipping Software With AI You Don't Trust
• Email Authentication Protocols: SPF, DKIM, DMARC, and BIMI
• How Do I Authenticate My Email? The Setup Steps

Sources

• Google, Email sender guidelines: messages of the same category should have the same From: email address, with sales receipts, promotional content, and account notifications given as separate categories; for senders above 5,000 messages a day, one-click unsubscribe on marketing and subscribed messages; and spam rates reported in Postmaster Tools kept below 0.10%, never reaching 0.30%.
• RFC 8058, one-click unsubscribe: the List-Unsubscribe-Post header carries the single pair List-Unsubscribe=One-Click, and both List-Unsubscribe headers must be covered by a valid DKIM signature.
• Stripe, Automate payment retries: invoice.payment_failed fires on a failed payment and on each retry, the recommended Smart Retries default is 8 tries within 2 weeks, and a subscription that isn't recovered transitions to canceled or unpaid, or stays past_due.
• Apple, Mail Privacy Protection: with Protect Mail Activity on, Mail downloads remote content in the background by default, regardless of whether the recipient engages with the email.

Common questions