Transactional vs Marketing Email: Infrastructure Differences
How transactional and marketing email differ in triggers, consent, volume, and reputation, why they need separate sending identities, and how to run both on Amazon SES.
A password reset and a monthly newsletter both leave your systems as email, but they are different products with different infrastructure needs. Transactional mail is triggered by something the recipient did and must arrive within seconds. Marketing mail is sent to many people at once on your schedule and must respect consent, unsubscribe rules, and the reputation limits of mailbox providers. Mixing the two on one sending path is the most common way a startup damages the delivery of the mail its users actually depend on. This article sets out the differences and how to separate them on a service such as Amazon SES.
What counts as transactional and what counts as marketing
Transactional mail is one to one and expected. Signup confirmations, password resets, one time codes, order receipts, shipping updates, invoices, and alerts from a monitoring system all qualify. The recipient has a relationship with you and the message completes an action they started. Because of that, anti-spam laws generally treat it more leniently: it does not require prior marketing consent, though it must still carry accurate sender information and must not be misleading.
Marketing mail is one to many and promotional. Newsletters, product announcements, discount campaigns, re-engagement sequences, and event invitations all qualify. It requires that the recipient opted in, that every message carries a working unsubscribe mechanism and a valid postal address where the law requires one, and that unsubscribe requests are honoured promptly. The large mailbox providers additionally expect bulk senders to support one-click unsubscribe through the List-Unsubscribe header and to keep spam complaint rates low.
The grey area is the message that does both, such as a receipt with a promotional banner. Regulators usually judge by the primary purpose, so a receipt that is mostly advertising is marketing. The safe engineering rule is to keep promotional content out of transactional templates entirely.
Why the two streams need separate reputations
Mailbox providers score senders by domain and by IP address, and the score is built from complaints, bounces, engagement, and authentication results across everything that domain or IP sends. If a marketing campaign to a stale list produces a spike of complaints, the reputation hit lands on the same domain that sends your password resets, and those start landing in spam or being deferred. Users who cannot log in do not care that the campaign was the cause.
The fix is isolation. Send transactional mail from one subdomain, such as mail.yourdomain, and marketing from another, such as news.yourdomain, each with its own SPF, DKIM selector, and DMARC coverage so that reputation is tracked separately. On Amazon SES, each subdomain is verified as its own identity, and configuration sets let you attach separate event publishing, tracking options, and dedicated IP pools to each stream. High volume marketing senders often move to dedicated IPs so that their reputation is entirely their own, while transactional mail stays on the shared pool where volume is steady and complaints are rare.
Infrastructure differences in practice
The two streams differ in almost every layer, which is why many teams run them on different tools even when both end up on the same provider.
| Aspect | Transactional | Marketing |
|---|---|---|
| Trigger | A user or system event, sent immediately | A campaign schedule or an automation sequence |
| Volume pattern | Steady, grows with the user base | Bursts, often a large share of the month in one day |
| Integration | Application code calling the SES API or SMTP interface | Campaign tool with list management, segmentation, and templates |
| Content | Short, personal, mostly text, few or no images | Designed HTML, images, tracked links |
| Consent basis | The existing relationship and the action taken | Explicit opt-in recorded with time and source |
| Unsubscribe | Usually not required, though preference controls are good practice | Required, including one-click unsubscribe for bulk senders |
| Sending identity | Its own subdomain on a shared or dedicated pool | Its own subdomain, often a dedicated IP at scale |
| Warm-up need | Low, volume grows organically | High, new IPs and domains need gradual ramping |
| Key metric | Delivery latency and bounce rate | Complaint rate, unsubscribe rate, engagement |
Latency deserves emphasis. A one time code that arrives after the code expires is a failed login, so transactional sending should never sit in a queue behind a campaign. On SES this is a reason to keep the streams on separate identities and, where the account’s maximum send rate is a constraint, to throttle the marketing sender in your own queue rather than let it consume the rate the application needs.
Bounces, complaints, and suppression
Both streams must handle feedback, but the volumes differ. Hard bounces, where the address does not exist, should remove the address from all future sending immediately. Soft bounces, such as a full mailbox, can be retried a limited number of times before suppression. Complaints arrive through feedback loops when a recipient marks a message as spam, and the address must be suppressed at once; continuing to send to someone who complained is both a legal risk and the fastest route to a blocked domain.
Amazon SES publishes bounce and complaint events for each identity or configuration set to Amazon SNS, Amazon EventBridge, Kinesis Data Firehose, or CloudWatch, and maintains an account level suppression list that can be extended with your own entries. SES also monitors each account’s bounce and complaint rates and can place the account under review or pause sending if they climb too high; the thresholds are set by AWS and documented in the SES developer guide. Marketing lists need the additional discipline of list hygiene: remove addresses that never engage, never import purchased lists, and confirm addresses with a double opt-in where the law or the audience expects it.
Running both streams on Amazon SES
SES is built for both use cases, but the sandbox and quota model shape how you start. A new SES account is in the sandbox, which limits sending to verified addresses and to a low daily quota, and production access must be requested with a description of the use case, the type of mail, and how bounces, complaints, and unsubscribes are handled. Requests that describe transactional mail with clear consent are straightforward; requests that describe bulk marketing without list management detail are more likely to be questioned.
Once in production, the account has a sending quota per 24 hour period and a maximum send rate per second, both of which AWS raises over time based on sending quality or on request. For marketing, SES offers list and subscription management with contact lists and topics, which adds unsubscribe links and a subscription page without a separate tool, and the dedicated IP options with automatic warm-up. For transactional, the SMTP interface and the API are covered in SMTP versus API sending, and the sandbox and quota mechanics in more detail in Amazon SES explained.
Where to go next
The Amazon SES accounts page lists options labeled SMTP 50K Limits and SMTP 100K Limits, which state a sending limit level as labeled and nothing more. Any account is subject to the AWS service terms and the SES acceptable use policy, and both transactional and marketing mail must be permission based and comply with the anti-spam law that applies to you and your recipients.
Before sending a first campaign from a new identity, read email deliverability basics for the warm-up and reputation practices that marketing streams depend on, and SPF, DKIM, and DMARC setup to authenticate each subdomain. The complete email series is in the Cloud Library.