Transactional vs Marketing Email: Why Mailchimp Should Never Send Your Password Resets

A SaaS founder once asked me, in the politest possible way, why his developers kept rejecting his "obviously simple" request to send password reset emails through the same Mailchimp account that handled the company's monthly newsletter. "We already pay for Mailchimp. The templates look great. Why should I pay AWS for SES on top of that?"

The honest answer is: because if a customer can't reset their password, the business stops working. And Mailchimp — which is excellent at what it does — was not designed to be the hot path for "user clicks 'forgot password' and needs to receive an email within ten seconds."

This conflation is everywhere. Engineers and founders use "email" as one category. The infrastructure community has known for fifteen years that there are at least two categories with different requirements. The cost of getting it wrong is paid in deliverability, reliability, audit, and occasionally compliance.

Here's the distinction, why it matters, and where the boundary actually sits.

Working definitions

Transactional email is email triggered by a specific user action or system event, sent to an individual user, with content that is functionally part of the system. The user expects the email. Failure to receive it has functional consequences — they can't reset their password, they don't know their card was charged, they miss a security alert.

Examples: password resets, MFA codes, login alerts, invoice notifications, billing receipts, account confirmations, invitations, magic links, file-share notifications, build-finished alerts.

Marketing email is email pushed to many recipients, often segmented by behavior or attributes, with content intended to inform, persuade, or convert. The recipient may or may not have specifically asked for this particular send. Failure to receive it has commercial consequences for the sender, not functional consequences for the receiver.

Examples: newsletters, product announcements, promotional offers, drip campaigns, re-engagement emails, abandoned-cart emails, win-back emails.

There is a fuzzy middle. Trial expiry warnings, usage-based notifications, "we noticed you tried X" prompts. These are sometimes classified as transactional (they're triggered by user behavior in a system) and sometimes as marketing (their purpose is commercial). The pragmatic test: does the user expect this specific email because of something they did, or are you sending it to drive an outcome you want? If the latter, treat it as marketing.

Why the requirements diverge

The two categories have different requirements at almost every layer of the stack. Mixing them forces you to over-build one and under-build the other.

Latency. Password reset emails need to arrive within seconds, every time. Marketing emails sent to a million recipients can take an hour to deliver and nobody complains. The infrastructure for "send 1 email in 2 seconds with 99.9% reliability" is different from "send 1 million emails in 60 minutes with 99% reliability." Tools optimized for the second case (campaign blasters) are usually slower and less reliable for the first case.

Reliability and reputation. Transactional emails go to single recipients, individually. Bounce rates and complaint rates from this traffic are almost always low — the recipient signed up, the address is real. Marketing emails go to large lists with varying engagement. Bounce and complaint rates are higher. Mixing them on the same sender reputation drags down deliverability for the transactional traffic, which is the traffic where deliverability matters most.

Audit and retention. Transactional emails often carry security-sensitive content — password resets, MFA codes, financial communications. SOC 2, HIPAA, PCI scopes can all touch these. Marketing emails generally don't. Putting them on the same infrastructure means your marketing tool inherits compliance scope it doesn't need, or your transactional tool loses controls it does need.

Opt-out semantics. Marketing email is subject to opt-out laws (CAN-SPAM in the US, GDPR in the EU, equivalents elsewhere). Transactional email is generally exempt — you can't unsubscribe from your own password reset, and the law recognizes this. Mixing them creates messy questions: does the unsubscribe link on a newsletter also stop transactional sends? Legally and ethically, no. Operationally, if both flow through one tool with one suppression list, yes.

Sender identity. Best practice is noreply@acme.com or notifications@acme.com for transactional, hello@acme.com or newsletter@acme.com for marketing — and ideally on different subdomains. This isolates reputation and signals intent to spam filters. Tools designed for one type of sending often make the multi-domain setup awkward.

Volume and pricing models. Marketing tools price per contact in your audience. Transactional tools price per email sent. For a SaaS with 100,000 customers and 200,000 transactional sends per month, those models produce wildly different bills. Misusing one for the other is expensive.

Sender reputation, in detail

This is the deliverability point and it deserves its own section because most teams underestimate it.

Email providers — Gmail, Microsoft, Apple, Yahoo — score senders on reputation. The score is per-domain and per-IP, with components for bounce rate, complaint rate, engagement (opens, replies, archives), and content patterns. Bad reputation lands you in spam folders. Catastrophic reputation gets you blocked.

Marketing email is structurally riskier for reputation. Larger lists, lower engagement on a per-recipient basis, more spam complaints from people who forgot they signed up.

Transactional email is structurally low-risk. Recipients open it because they were just looking for it. Bounce rates are low because the addresses are recently validated.

When you send both from the same domain and IP, the marketing risk pollutes the transactional reputation. A bad newsletter campaign can land your password reset emails in spam for two weeks. The fix is structural separation:

• Different subdomains. mail.acme.com for transactional, marketing.acme.com for marketing.
• Different DKIM keys for each subdomain.
• Different sending infrastructure if possible — at minimum, different SES configuration sets with different IP pools, ideally different vendors.
• Different SPF records that don't overlap unnecessarily.

The one-domain shortcut feels simpler. It costs you measurable deliverability the moment your marketing list does anything spicy.

The right tool for each job

For transactional email on AWS, Amazon SES is the boring correct answer. Cheap per-email pricing, predictable performance, integrates with the rest of your AWS stack, supports the audit and security primitives you need.

Other production-grade transactional services: Postmark, Resend, SendGrid's transactional API. Postmark is well-regarded for its strict transactional-only stance and its delivery times. Resend has the cleanest developer experience of any transactional service launched recently. SendGrid is everywhere and works fine but is the legacy default rather than the best choice.

For marketing email, the right tools are different. Mailchimp, Customer.io, HubSpot, Klaviyo, Iterable — these are designed for segmentation, scheduled campaigns, behavioral triggering, A/B testing of subject lines, dashboards your CMO actually wants to look at.

Some tools straddle. SendGrid has both transactional and marketing products. Customer.io and Iterable can do both. The straddling tools work, but they encourage the conflation this post is arguing against. The cleaner architecture is two separate tools, even when one vendor offers both.

For SaaS specifically, the common pattern is: SES (or Postmark, or Resend) for transactional, paired with a marketing tool that holds the customer list and handles campaigns. Application code calls SES directly for transactional. The marketing tool gets a feed of customer events from your data warehouse or product analytics.

What goes wrong when teams mix them

A short tour of incidents I've seen.

The newsletter that took down password resets. A SaaS sent both newsletters and password resets through SendGrid on the same subdomain. A newsletter campaign got an unusually bad spam-complaint rate from one segment. SendGrid temporarily throttled the subdomain. Password reset delivery dropped from minutes to hours for two days while the team scrambled to set up a separate sending domain.

The marketing tool that retained PII it shouldn't have. A team set up Mailchimp to send security alerts because "we already have it." Mailchimp dutifully retained the alert content, including IP addresses and last-login timestamps, in its audit logs. The team's SOC 2 auditor, reasonably, asked about this and concluded that Mailchimp was now in scope for security control review. Migrating those sends to SES took a quarter.

The unsubscribe that stopped MFA codes. A user clicked "unsubscribe from all emails" on a marketing email. The integration's suppression list was shared between marketing and the transactional tool. The user couldn't log in for a week because every MFA code attempt was suppressed. Customer support eventually figured it out.

The trial-expiry race condition. A team used a marketing automation tool to send trial-expiry warnings. The tool ran its sends on a daily batch at midnight UTC. A customer who upgraded at 11:55pm UTC still got the "your trial is expiring tomorrow" email at 12:01am, because the marketing tool's view of customer state was a stale daily export. Customer was annoyed, contacted support, and the team had to explain why their billing system and their email said different things.

These incidents share a structural cause: marketing tools have correct-for-marketing assumptions about latency, suppression, retention, and data freshness that are wrong for transactional use cases.

Compliance and legal angles

Briefly, since this is post is technical and not a law substitute:

CAN-SPAM (US) requires unsubscribe links and physical addresses in commercial emails but exempts transactional and relationship messages. Sending password resets without an unsubscribe link is fine. Sending newsletters without one is illegal.

GDPR (EU) requires lawful basis for sending. Transactional emails sent to fulfill a contract (your customer needs them to use the service) have a clear lawful basis. Marketing emails generally require consent. Mixing them on the same infrastructure muddies the consent record.

HIPAA (US healthcare) treats any email containing PHI as in-scope. Sending PHI-bearing alerts through a marketing tool that doesn't sign a BAA is a violation. Sending non-PHI marketing through the same tool is fine.

Industry-specific rules (financial, healthcare, education) often require audit trails on customer-facing communications, which transactional tooling provides and marketing tooling generally does not.

The pattern: transactional infrastructure is operating under stricter audit and reliability requirements; marketing infrastructure is operating under stricter consent and opt-out requirements. Each has the controls it needs. Neither has the controls of the other. Mixing forces one of them to grow controls it shouldn't need or the other to skip controls it must have.

A short decision tree

When in doubt about classifying a specific email type, run it through these questions in order.

1. Does the user expect this email because of something they specifically did? If yes, it's likely transactional. (Password reset, account confirmation, invoice.) If no, lean marketing.

2. Does the email functionally enable the user to use the system? If yes, transactional. (Magic link, MFA code.) If no, lean marketing.

3. Does the email contain content that would be in scope for a security audit? If yes, transactional, and your sender needs the controls.

4. Could the user reasonably opt out without breaking the system? If yes, marketing. If no, transactional.

5. Is the email triggered by user state changing or by a marketing decision? State change = transactional. Marketing decision = marketing.

For most B2B SaaS, the resulting list is short on the transactional side and long on the marketing side, which is correct. Transactional is a few high-stakes message types that the application sends. Marketing is everything else.

Where Sovy fits

Sovy is positioned in the transactional half of the world. It is a control layer for Amazon SES templates — the templates that send password resets, billing notifications, and account confirmations. Sovy is explicitly not a marketing tool. It does not have campaign management, segmentation, A/B testing of subject lines, or behavioral triggering. Those are the right features for a marketing tool, and Sovy is not trying to be one.

What Sovy does is treat transactional templates as the production artifacts they are: with version history, role-based access, audit logs, environment separation, and safe publishing. The category is "operational control over Amazon SES" and the audience is engineering teams, not marketing teams.

If you're building on AWS and you've concluded that SES is the right transactional backbone, the next question is how the humans on your team safely change those templates. That's the question Sovy is built for.

---

Sovy is a control layer for Amazon SES templates. It is for transactional email — the kind your application has to send for the product to work. If you've ever wished your password reset templates had the same change controls as your application code, we'd like to hear from you.