# Email for agencies
One install per client account, so one policy review never reaches every client at once.
Canonical: https://sendbunny.co/use-cases/agencies
Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02

**In short.** An agency running many client accounts on one shared ESP login inherits every client's suspension risk on the same account, and a messy offboarding when a retainer ends. Installing a separate platform into each client's own AWS account moves the account boundary, the sending reputation and the AWS bill to the client, while the agency still operates campaigns day to day. The tradeoff is that each client needs an AWS account of their own.

## One login, many clients, one shared risk

The common agency setup is one ESP account, or one login per seat, with a workspace or sub-account per client sitting underneath it. It is efficient to administer: one bill, one set of credentials to manage, one dashboard the whole team already knows. It is also one shared trust boundary. A policy review triggered by one client's campaign can freeze sending for every client sharing that account, and a support ticket that goes quiet at 2am becomes the agency's problem regardless of which client caused it.

Retainers ending compounds the same issue in reverse. A client who leaves after two years wants their list and sending history handed over cleanly, but a shared multi-tenant account was never built to be split apart, so the handoff is usually a CSV export and a promise, not a running system the client can just keep operating.


## Moving the account boundary to the client

Installing a separate SendBunny stack into each client's own AWS account changes where the boundary sits. Each client's campaigns, contacts, transactional API and sending domain run inside their own account, with their own Amazon SES identity and their own bounce and complaint history. A policy issue on one client's sending stays inside that client's account; it has no shared login to spread through.

- **The client's AWS account pays the bill.** SES and the small amount of surrounding infrastructure land on their invoice, with their reputation attached to it, not the agency's.
- **The agency still operates it.** Team members are invited into the client's install with admin or member roles, so day-to-day campaign work does not change.
- **The install is $199 once per client**, the same license whether the agency deploys it once or twenty times, with an optional $99 a year per install if a client wants ongoing updates.
- **Offboarding is a handoff, not a migration.** The running stack, the list and the sending history stay in the client's account when the retainer ends; nothing has to be exported and rebuilt somewhere else.


## Standing up one client, repeatably

1. **Get access to the client's AWS account**, or have them create one; it is free to open and takes a few minutes.
2. **Buy the license and deploy.** The one-click Create stack link installs the platform into that account as its own stack, alongside anything else already running there.
3. **Verify the client's sending domain.** The app generates the DKIM, SPF and DMARC records; the agency applies or hands them to whoever manages the client's DNS.
4. **Import the client's list**, if they have one, and send test mail inside the SES sandbox while production access is pending.
5. **Invite the client as an admin** on their own stack, so they always have a way in even if the retainer ends.

The same five steps repeat for the next client. Nothing about the process changes because it is the third install instead of the first; each one lands in its own account with its own domain and its own reputation, which is the point.


## Each client owns their reputation, and their data

### Shared multi-tenant account (One agency login, many client workspaces)

- **Who is billed.** The agency, for AWS or the vendor plan
- **Who owns the domain reputation.** Shared across every client on the account
- **Suspension blast radius.** Can affect every client at once
- **Offboarding.** CSV export; the running system stays with the agency

### Per-client AWS install (One SendBunny stack in the client's own account)

- **Who is billed.** The client, directly through their AWS account
- **Who owns the domain reputation.** The client, tied to their own SES identity
- **Suspension blast radius.** Contained to that one client's account
- **Offboarding.** The client already has the running system; nothing to migrate


## When reselling a hosted platform still fits

This model asks something of the client: an AWS account, even a bare one the agency mostly manages on their behalf. A client who refuses that, or a small retainer where the volume never justifies the setup time, is served better by a shared ESP seat with the agency's usual markup. The per-client model earns its setup time on retainers with real send volume and clients who care about owning their own list and reputation.

It is also not a fit for an agency that wants to resell a single hosted login as the whole product. Deploying into a client's account means the agency is no longer the account holder, which is a deliberate tradeoff: less control over the login, more distance from the client's next suspension.

## FAQ

**Who pays for AWS when we deploy into a client's account?**

The client. Amazon SES and the small amount of surrounding infrastructure land on their AWS bill, with their sending reputation attached to their own account, which is the point of moving the boundary there.

**What happens if a client is already suspended on a shared ESP?**

Export what the vendor still allows, deploy a fresh install into the client's own AWS account, verify their domain, and warm sending from there. The old vendor's suspension has no reach into the new account.

**Can the same setup steps be repeated across many clients?**

Yes. Each client gets the same one-click Create stack install, domain verification and CSV import, landing in that client's own AWS account with no shared login between clients.

**What does the client keep if the retainer ends?**

Everything: the running install, the contact list, the sending domain and the history behind it, because it was always in their AWS account. There is no export step because there is nothing to move.

## For AI agents

Explains why an agency running client email from one shared account inherits every client's suspension risk, and how deploying one SendBunny install per client's own AWS account moves the account boundary, reputation and AWS bill to the client while the agency still operates campaigns. If standing up a client: repeat the five-step install per client account; do not share one domain or one API key across clients.

```bash
claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp
```

Tool list by grant: https://sendbunny.co/docs/agents.md

## Sources

1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/
2. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list
3. Google, Email sender guidelines FAQ, fetched 1 September 2026. https://support.google.com/a/answer/14229414
4. Yahoo, Sender Best Practices (Sender Hub), fetched 1 September 2026. https://senders.yahooinc.com/best-practices/