A Reliability Checklist for Transactional Email

When was the last time anyone on your team owned transactional email end-to-end?

In most B2B SaaS companies, the answer is "nobody." Email got set up by whoever was free during the original infrastructure build. It mostly works. When it breaks — a customer can't reset their password, an invoice fails to send, deliverability tanks for a week — the engineer on call digs in, fixes the immediate problem, and moves on. The next time it breaks, somebody else does the same.

This is fine until your customer base hits a size where transactional email failures become support tickets in volume, or until an auditor or enterprise prospect asks "what's your change control process for security-relevant communications?" and you don't have a confident answer.

The good news is that "production-grade transactional email" is not exotic. It is a small number of well-understood concerns, each with a defined right answer, that most teams haven't worked through systematically. This checklist is meant to be that systematic walk-through. Spend an afternoon on it. Score yourself honestly. Pick the lowest-scoring section and invest there next quarter.

1. Sending domain hygiene

The foundation. If your domain isn't authenticated correctly, nothing else matters because your emails are landing in spam.

SPF. Your domain has a single, valid SPF record covering Amazon SES (include:amazonses.com) and any other senders you use. Multiple SPF records or oversized records (more than ten lookups) silently fail.

DKIM. Easy DKIM enabled on your SES sending domain. AWS publishes the CNAME records; you add them to DNS. Verify they're propagated and SES shows the domain as DKIM-verified.

DMARC. A DMARC record exists and is at minimum p=none with reporting addresses (rua=). Long-term, you want p=quarantine or p=reject once you're confident in alignment.

BIMI. Optional. Improves visual brand presentation in supporting clients. Requires a verified mark certificate (VMC). Worth it if your brand visibility in inbox matters.

Subdomain separation. Transactional sends from a dedicated subdomain (mail.acme.com or notifications.acme.com), separate from your primary corporate domain and from any marketing domain. Reputation damage on one doesn't bleed to others.

Score: how many of the above can you confidently confirm right now, without asking?

2. Bounce and complaint handling

Bounces and complaints are not just deliverability concerns — they're indicators that your sending behavior may not survive AWS's account-level review.

Event destinations configured. SES configuration sets have event destinations that route bounces and complaints to a queue or topic you process.

Automated suppression on hard bounce. Hard bounces (Permanent bounce types) trigger automatic suppression at the application layer. The address never receives another send.

Automated suppression on complaint. Complaints (recipient marked as spam) trigger automatic suppression. This is non-negotiable — continuing to send to complainers is the fastest way to lose your sender reputation and your SES account.

Soft bounce backoff. Soft bounces (transient failures) retry with backoff, not infinite immediate retry. Three retries over 24 hours, then escalate to suppression if no success.

Bounce rate alarm. CloudWatch alarm on bounce rate above 5%. AWS pauses your account at 10%; you want to know at 5%, when you can still respond.

Complaint rate alarm. Alarm on complaint rate above 0.1%. AWS pauses your account at 0.5%; the threshold for "this is a real problem" is much lower than the threshold AWS acts on.

Score: do you know your current bounce and complaint rates without checking? Are they alarmed?

3. Suppression list management

The suppression list determines what doesn't get sent. If it's wrong, you either send to bad addresses (deliverability tax) or fail to send to good ones (customer support incidents).

Application-layer suppression list. Your application maintains its own suppression list, populated from SES events. Sends check this list before calling SES.

Per-environment scoping. Staging suppression and production suppression are separate. A staging hard bounce does not suppress that address in production.

Per-tenant scoping (multi-tenant only). A user who unsubscribed from one tenant does not get suppressed across all tenants.

Audit and recovery. A way to look up "why is this address suppressed" and, when justified, to remove it. Suppressing the wrong address creates a customer support incident; you need a clean recovery path.

Quarterly review. Once a quarter, check the size of the suppression list against the size of your customer base. Anomalies (a sudden spike in suppression) often indicate a sending bug or a list-cleaning regression.

Score: can you, in five minutes, answer why a specific address is or isn't suppressed?

4. Template change control

This is where the previous posts in this series live. The summary:

Source of truth. Templates exist in a system with version history — Git, IaC, or a control layer.

Review before publish. Every template change is reviewed by a second human before reaching production. Security templates are reviewed by security; billing templates by finance.

Pre-publish render check. New templates are rendered (against real or representative email clients) before going to production. The Console preview is not enough.

Environment promotion. Staging is deployed first, production after staging stability is confirmed.

One-click rollback. Rolling back a bad template is fast and doesn't require reading docs.

Audit trail. Every change records who, what, when, and why. Retained for the audit period plus typical lookback.

Console editing locked down. Production SES Console is read-only for everyone except a small list of break-glass principals. Hot fixes go through the same pipeline as planned changes, with documented exceptions.

Score: how many of these are real for your team?

5. Regional resilience

Disaster recovery for SES is the longer version. The checklist version:

Primary region documented. Your team knows which region is primary and why.

Secondary region prepared. A secondary region has verified domains, raised quotas, and templates synced. It is not "the place we'll set up if things go wrong" — it is set up now.

Application-layer failover. Application code can fail over to the secondary region, either automatically (a wrapper that detects primary errors) or via a runbook.

Tested failover. A real failover drill has run within the last 12 months. The runbook reflects what was learned from it.

Suppression list parity. The application-layer suppression list is consulted regardless of region.

Quotas in DR region. The secondary region's quota is sufficient for full production traffic, not just the sandbox 200/day.

Score: if us-east-1 (or your primary) had a 6-hour SES outage starting now, how long before you're sending fully through the secondary?

6. Observability and SLOs

You cannot improve what you don't measure. The minimum measurement set:

Send latency SLI. Time from application call to SES accepting the send. Track p50, p95, p99.

Delivery latency SLI. Time from send to delivery (where derivable from event destinations). Track per recipient domain — Gmail vs. Outlook vs. Yahoo each have different baselines.

Bounce rate SLI. Hard bounces as a fraction of sends, per environment, per template if possible.

Complaint rate SLI. Complaints as a fraction of sends, same dimensions.

Send volume SLI. Sends per minute, alarmed for unusual spikes (which often indicate a runaway loop) and unusual drops (which often indicate a stopped worker).

SLOs. Defined targets — for example, password reset send latency p99 < 5 seconds; bounce rate < 2%; complaint rate < 0.05%. Documented, alarmed, reviewed.

Dashboard. A single dashboard that shows the above. A new engineer onboarding can find it. A founder can read it.

Score: do you have SLOs for transactional email, and have you reviewed them in the last six months?

7. Compliance posture

For B2B SaaS, transactional email touches several compliance regimes. The minimum:

Data residency. You know which regions your transactional emails are sent through. For EU customers, your sending is in EU regions. Documented.

Retention. Email metadata (event destination logs) are retained for the period your compliance regime requires — typically 12 months minimum, often longer.

Audit logs. Template changes, IAM changes, and configuration changes have an immutable audit trail. Exportable to your auditor on request.

Access control. Who can edit production templates is documented. Access is reviewed quarterly. Departed employees are removed promptly.

Vendor review. Every email-adjacent vendor (your monitoring tool, your control layer, your render-check service) has a security review and, where relevant, a signed DPA or BAA.

Incident response. Email-related incidents (a bad template, a breach involving email content, a failure to send a security notice) have a documented response procedure. Not the same procedure as application incidents — email has its own twists, like "the email contained PII and was sent to the wrong address."

Score: if your security or compliance team asked for an SES posture review, what would they find?

8. Cost and capacity

Often forgotten in reliability discussions, but worth checking.

SES pricing visibility. You know roughly what you spend on SES per month and how it scales with customer growth. SES is cheap per email — fractions of a cent — but for high-volume senders the bill can be material.

Quota headroom. Your account quota is at least 2x current peak send rate. Quota increases require AWS approval; running close to your quota leaves no room for spikes.

Reserved capacity for spikes. If your traffic has predictable spikes (end of month, end of quarter), the quota covers them.

Cost alerts. Billing alarms on unexpected SES cost increases. A bug that fires off a million emails costs money and damages reputation; you want to know early.

Score: when did you last review your SES spend and quota?

9. Documentation and runbooks

The unsexy but essential piece.

Architecture document. A current document describes how transactional email works in your system: which sending domains, which regions, which configuration sets, which templates exist, who owns each.

Runbook for common incidents. Documented procedures for: bounce rate spike, complaint rate spike, template hotfix needed, regional failover, suppression list correction, account-paused-by-AWS.

Onboarding doc. A new engineer can read a single document and understand how transactional email works in your system.

Owner. A specific named person (or rotating role) owns transactional email. They get the alerts. They run the quarterly review. They are accountable.

Score: if the original engineer who set up SES left tomorrow, what would the next person have to figure out from scratch?

A scoring rubric

For each of the nine sections, score 0 to 3:

• 0: We don't do this.
• 1: We do this informally or partially.
• 2: We do this consistently but it's not documented or could be improved.
• 3: We do this well, with documentation, ownership, and regular review.

Total possible: 27.

A 27/27 means you've thought through transactional email more rigorously than 95% of B2B SaaS. Most teams I've worked with score in the 8–14 range on first pass. The point isn't to score high right now. The point is to know where you actually are.

Take the lowest-scoring section. Pick one or two items from it. Make those a quarterly priority. Re-score in three months.

Where Sovy fits in this checklist

Sovy directly addresses sections 4 (template change control) and 5 (regional resilience) end-to-end, and contributes to section 7 (compliance — audit logs) and section 9 (documentation — operational ownership of templates).

It does not solve sections 1 (DNS hygiene), 2 (bounce handling), 3 (suppression management), 6 (observability and SLOs), or 8 (cost). Those are your application's concerns, your AWS configuration's concerns, or both.

The honest summary: Sovy is the right answer for "how do we control template changes safely across environments and regions, with audit and role-based access?" It is not the right answer for "we have a 6% bounce rate." Different problems, different tools.

If you've worked through this checklist and the lowest-scoring section is template change control or regional resilience, we'd like to hear from you. If it's something else, fix that first — Sovy will be more valuable once the foundation is there.

---

The reframe

The reason most teams underinvest in transactional email reliability is that the cost of underinvestment is invisible until it isn't. Customers don't email you to say their password reset arrived in 3 seconds instead of 30. They email you when it doesn't arrive at all, and at that point the cost is paid in trust, not just in support tickets.

Production-grade transactional email is mostly about treating it as production. The tooling for application code is mature; the tooling for transactional email is catching up; the discipline that connects them is yours.

Walk through the checklist. Pick a section. Improve it. Repeat next quarter. In two cycles you'll have moved from "whoever set this up originally" to "this is a tracked, owned, monitored part of our system." Every B2B SaaS that's been around long enough to have this story figured out got there exactly that way.

---

Sovy is a control layer for Amazon SES templates that addresses the change-control and regional-resilience pieces of this checklist. If your reliability checklist score is low because of those specifically, we'd like to hear from you.