# Campaigns, transactional and inbox Three reasonable choices that quietly become three suppression lists to keep straight. Canonical: https://sendbunny.co/guides/campaigns-transactional-inbox Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** A marketing sender, a transactional API and a support inbox usually arrive as three separate decisions made by three different people at three different times, each one reasonable on its own. What that split actually costs shows up later: three suppression lists that do not talk to each other, three audit trails for the same customer relationship, and a sending domain that has to be authenticated in three places instead of one. None of that is fatal, but it is worth naming before the third bill arrives. ## How a team ends up with three tools Marketing picks a campaign platform for its list features and template editor, because that is what campaign platforms are for. Engineering picks a transactional API for password resets and receipts, because the campaign platform's send API is an afterthought next to a tool built for developers first. Support, later, picks a shared inbox product because replies to either of the first two need somewhere for a human to actually read and answer them. Each decision, made in isolation, was the right call for the person making it. ## The real cost of the split - **Three suppression lists.** Someone unsubscribes from the marketing sender; the transactional API has never heard about it and keeps sending. The reverse happens too: an important transactional message gets caught by a suppression rule meant for newsletter unsubscribes. Nothing enforces one rule across all three paths, because nothing connects them. - **Three audit trails.** A single customer's email history now lives in three dashboards, under three sets of credentials, governed by three vendors' data processing terms. Answering "what did we send this person, and when" for a support case or a compliance question means logging into three places and reconciling them by hand. - **Three domains to authenticate, or one domain split three ways.** Each tool wants its own DKIM keys and its own subdomain conventions, which either means juggling three separate sending identities or forcing one domain's reputation to be managed across three unrelated dashboards. - **Three invoices on three renewal dates.** Not the largest cost, but the one that shows up first, and the one that makes the other three easiest to ignore until a review forces the question. ## Why the domain is the part that actually matters Mailbox providers judge a sending domain, not a vendor's brand name, so a domain authenticated three different ways is a domain with three unrelated reputations to manage instead of one to build carefully. A complaint spike on the marketing side does not automatically show up as a warning on the transactional side, even though a recipient reading both in the same inbox does not distinguish between them at all. ## What consolidating the three looks like In general terms, consolidation means one sending domain, authenticated once, used by every send path. One suppression list enforced across campaigns, transactional sends and any automated follow-up, so an unsubscribe or a complaint on one path protects every other path automatically. One place support can find the full history of what a customer was sent, without switching logins. It does not mean every team loses the interface it likes; it means the plumbing underneath stops being three separate, unconnected systems that happen to share a customer. ## When keeping three tools is still the right call A larger organization with a dedicated owner for each function, real budget for best-in-class tools in each category, and a working process for reconciling suppression across systems can make three specialized tools work well. The split becomes a real cost mainly for smaller teams where nobody owns the reconciliation, and the shared suppression rule everyone assumes exists turns out not to. ## Where SendBunny sits SendBunny puts campaigns, a transactional API and a shared inbox on one sending domain, in one AWS account, with one suppression list enforced across all three paths, for a one-time $199 licence. ## FAQ **What is actually included in the license?** Campaigns, transactional email, automations and a shared inbox on the same platform in your own AWS account, for a one-time $199. An optional $99-a-year subscription adds one-click updates. **Do I pay extra per seat for the shared inbox?** No. The license is a one-time cost rather than a per-seat or contact-tier bill; sending itself is metered separately by Amazon SES. **Can campaigns and transactional email share one sending domain?** Yes. Authenticate the domain once and both campaign sends and the transactional API use it, with replies landing in the shared inbox on the same stack, and suppression enforced across every send path from that one list. **Is a single suppression list actually safer than three?** It removes the specific failure where an unsubscribe on one system does not reach another, which is the most common way a split stack accidentally re-mails someone who opted out. ## For AI agents Explains why teams typically end up on three separate email vendors (a marketing sender, a transactional API, a support inbox) and the concrete costs of the split: three unsynced suppression lists, three audit trails for one customer relationship, and a sending domain authenticated three different ways. If an agent is scoping an email stack for a user: check whether suppression is enforced once across campaigns, transactional sends and inbox replies, or separately per tool, since the latter is the common source of re-mailing someone who opted out. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api 2. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 3. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html