Email for SaaS foundersSignup mail and campaigns in the AWS account you already run.

The day a founder wires the first POST /signup handler, the email requirements show up fast: a welcome message, a verification link, a password reset a week later, and by month two a founder update that is not really transactional at all. Most teams start with a transactional API for the first three and a separate marketing tool for the fourth, because that is what the tutorials show.

The split works until the two tools need to agree on something: a shared unsubscribe and suppression list so a churned user does not get a win-back campaign the day after their card fails, one domain so DKIM and SPF are not fighting two providers, or a support reply landing in a mailbox neither tool touches. None of that is exotic. It is what a signup flow needs by the time there are real users behind it.

A SaaS product needs some mix of five pieces, and the decision point is not which vendor has the nicest editor, it is whether the account behind the sending domain is one you administer or one you rent.

• Transactional API for verification links, password resets and receipts, called from your backend with fixed recipients.
• Campaigns for the founder update, the changelog digest, or a launch announcement to the whole list.
• Automation for the onboarding sequence that fires a few days after signup if a user has not activated.
• Shared inbox for the support@ or hello@ address a signup flow inevitably generates replies to.
• Analytics to see bounce and complaint rates before AWS does, not after a warning email.

A rented ESP account bundles most of this behind a monthly plan tied to contact count. An install into your own AWS account keeps the same five pieces, but the account, the domain identity and the suppression list all sit under your control, and the sending itself runs on Amazon SES rather than the vendor's own infrastructure.

1. Pay once, then deploy. SendBunny's license is $199 paid a single time. Checkout produces a pre-filled CloudFormation link; clicking Create stack installs the platform into your AWS account as its own stack, alongside whatever else already runs there.
2. Add your sending domain. The app generates the DKIM, SPF and DMARC records for authenticated sending. If your DNS runs on Route 53 in the same account, one click applies them; otherwise copy them to your provider and the app confirms verification once AWS sees them.
3. Send inside the SES sandbox first. A new AWS account starts in the sandbox, which only delivers to verified addresses. That is enough to send the welcome email and the reset link to your own test accounts while you finish the app integration.
4. Request production access. The app links to AWS's own production-access form, which mostly asks for a website URL. Approval is a routine review, not a negotiation, and until it clears you can build and test against verified addresses.
5. Point the app at the API. Create a key scoped to email:send for the transactional path, and a second, wider key for anything that touches campaigns or the audience later.

Early-stage tools are fine right up until signup volume makes the monthly bill uncomfortable, or until a policy review on the marketing side pauses the account that also happens to send the verification email. A rented platform that bundles transactional and marketing sending under one login means a complaint on a campaign can stall the password reset flow too, because both share the account the vendor is reviewing.

That coupling is the actual risk, more than price. An account you administer on your own AWS still answers to AWS's rules for SES, and a bad complaint rate still gets throttled there too. The difference is who is making the call and on what basis: your own bounce and complaint dashboard, checked against thresholds you can see, rather than a support queue you cannot see into.

The license is $199 once, with an optional $99 a year if you want one-click updates after the first year; sending itself is billed by AWS through SES, not by contact count. A quiet staging environment costs essentially nothing beyond that license. A launch week that sends to every user costs whatever SES bills for the volume, and nothing more, because there is no per-contact ladder to climb.

None of this is the right call for every stage. A weekend prototype with a handful of test users has no reason to touch AWS at all; a hosted free tier gets the first emails out faster. A founder who does not want an AWS account, and has no plan to open one, is better served by a rented tool with its own support line, even with the contact-tier bill that comes with it.

The same is true if the product needs a fully managed sender warm-up service, a hosted signup form with drag-and-drop building, or deliverability consulting bundled into the plan. Those are real features of some rented platforms and are not part of what an owned install provides on its own; you get the API, the dashboard, and the account, and you run the launch.