--- title: Transactional and marketing email in one API metaTitle: Transactional and marketing email in one API description: Running both kinds of mail through one vendor is fine. Running them through one sending reputation is not. Here is what has to be shared and what has to be kept apart. date: 2026-07-30 author: emails.sh tags: Architecture --- Most teams end up with two email vendors: an API for the mail their code sends, and a marketing tool for the mail a person writes. Two bills, two suppression lists, two sets of DNS records, and two answers to the question "did this customer get anything from us this week". You can have one vendor. What you cannot safely have is one sending reputation, and the difference between those two statements is most of what this post is about. ## What must be shared **The suppression list.** Somebody who marked your newsletter as spam should not then receive a receipt at the same address, and somebody whose address hard bounced on a receipt should not stay on a campaign list. With two vendors this is a synchronisation job you will write badly once and then never look at again. With one it is a fact of the system. **The verified domains.** DKIM, SPF and DMARC on one domain, published once, checked once. Two vendors means two sets of records and two things to get wrong. **The delivery log.** "Did this customer receive anything from us" should be one lookup. When a support conversation is about an email, being able to see the campaign and the password reset in the same timeline is the difference between an answer and a guess. **Consent.** A subscription topic is a kind of mail, not a list. If the same person can be reached by both halves of your product, their preference has to be resolved by one rule in both, or you will eventually mail somebody who told you not to. ## What must be kept apart **The sending reputation.** This is the one that costs money when you get it wrong. Marketing mail generates complaints, because some proportion of people who agreed to hear from you will change their minds by clicking the spam button. That is a normal, healthy rate of a fraction of a percent, and it is still enormously higher than the complaint rate on a password reset, which is approximately zero. If both kinds of mail share an IP pool and a sending identity, the complaint rate that receiving servers see for your transactional mail is the blended rate. A campaign having a bad week starts pushing verification links into spam, and verification links landing in spam is a signup funnel quietly failing while every dashboard you own says the mail was delivered. Here the separation is enforced rather than configured: marketing mail runs through its own configuration set and its own IP pool, and the send path refuses to send a broadcast if the two would collide. A refusal is an annoying failure. Silently blending the pools is a failure you find out about six weeks later from a support ticket. **The pricing.** These are different shapes of work and pricing them the same way makes one of them absurd. Transactional volume scales with your user count: a product with 200,000 users sends 200,000 password resets and receipts without any of those people being a "contact" in a marketing sense. Charging per contact stored for that is charging rent on your user table. Campaign volume scales with your list, and charging per email sent for it punishes you for mailing the people you are already paying to store. So it is two prices. Transactional is per email sent and counts no contacts. Marketing is per contact stored, in tiers, with no per-email charge on sends to your own audiences. Neither plan requires the other. A product with 200,000 users and a 4,000-person announcement list pays for 4,000 contacts. ## The subdomain question Even with the pools separated, sending campaigns and transactional mail from different subdomains is worth doing. `mail.acme.com` for the mail your code sends and `news.acme.com` for the mail a person writes. Each publishes its own DKIM records, each gets its own SPF lookup budget, and a complaint attaches to the subdomain that earned it. This costs you two DNS setups instead of one and it is the cheapest deliverability insurance available. ## What one vendor does not fix It does not make you good at marketing email. There is no A/B testing here, no drag-and-drop layout tool, no signup form builder, and the merge syntax is `{{ variable }}` with no conditionals. If the person writing the email is not the person writing the code, a dedicated marketing tool will serve them better and you should keep it, run it from a separate subdomain, and use the one API for the transactional half. The case for consolidating is strongest when a developer owns both jobs, which is most small teams and quite a few large ones. ## Questions ### Should I use one vendor for both? If a developer owns both, yes: shared suppression, shared domains and one log are real operational wins. If a marketing team owns the campaigns, keep their tool and separate the subdomains. ### Does a campaign bounce affect my transactional sending? The address is suppressed for both, which is what you want. The sending reputation is not shared, because the pools are separate and the separation is enforced in code rather than being a setting somebody can get wrong. ### How do unsubscribes work across the two? A broadcast carries a per-membership unsubscribe token and the RFC 8058 one-click headers on every copy. Transactional mail is a different mechanism, workspace-wide, because there is no list to leave. Subscription topics sit across both and are resolved by one rule: suppression blocks first, a required topic always passes, an explicit preference is obeyed, and silence falls back to the topic's default. ### Is marketing mail counted against my transactional allowance? No. Sends to your own audiences carry no per-email charge and draw on no transactional plan. ## Related - [How to migrate from SendGrid without changing your code](/blog/migrate-sendgrid-without-changing-code) - [Transactional vs marketing email](/blog/transactional-vs-marketing-email) - [Broadcasts](/features/broadcasts) - [Pricing](/pricing)