Why separating transactional and marketing email protects deliverability, and how to split streams by subdomain, IP pool, suppression scope and sending policy.
Pidgely teamPublished 5 min readMarkdown version
You should separate transactional and marketing email because they behave differently and mailbox providers judge them by reputation: marketing mail naturally produces more complaints, unsubscribes and bounces, and if it shares a domain and IP with your password resets and receipts, a bad campaign can push those critical messages into spam or delay them. The standard approach is to send each stream from its own subdomain, its own IP pool and its own return-path, with separate suppression scopes and sending policies. Separation does not hide anything from receivers; it lets them score each stream on its own behavior.
Transactional (or operational) messages are triggered by something the recipient did or by the state of their account:
Marketing (or bulk, promotional) messages go to a list:
A useful test: would the user be harmed or confused if the message did not arrive? If yes, it is transactional. Also, a receipt with a large promotional block becomes, in practice, marketing.
Mailbox providers build reputation on several identifiers: the sending IP, the From domain, the DKIM d= domain, the return-path domain, and increasingly the content itself. When all your mail shares these identifiers, the reputation is a blend.
Consider a typical week. Your product sends a steady flow of receipts and login codes that recipients open within seconds and almost never report. Then marketing sends a campaign to a list that includes people who signed up two years ago. Complaints spike, some addresses bounce, a few spam traps are hit. Gmail lowers the reputation of the domain and IP, and on Tuesday morning your two-factor codes arrive in spam or several minutes late. Support tickets follow.
The reverse problem exists too: high-engagement transactional mail can mask a marketing program with real issues, so you discover the problem only when it is serious.
Use distinct subdomains in the From address and DKIM signature:
Transactional: From: Example <no-reply@notify.example.com> DKIM d=notify.example.com
Marketing: From: Example <news@news.example.com> DKIM d=news.example.comSome teams keep transactional mail on the root domain (receipts@example.com) because recipients recognize it, and move marketing to a subdomain. Either works; what matters is that the two streams use different domains.
Each subdomain needs its own DKIM key and, if you want strict separation, its own DMARC record (otherwise it inherits the parent's sp= policy):
s1._domainkey.notify.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."
s1._domainkey.news.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."Remember that subdomains share the organizational domain. A spoofing or abuse problem on news.example.com still involves example.com, and, according to Google's sender guidelines, volume from all subdomains counts together toward the bulk sender threshold.
Give each stream its own envelope sender domain, aligned with its From domain:
Transactional: Return-Path: <b-4f1c@rp.notify.example.com>
Marketing: Return-Path: <b-9a2e@rp.news.example.com>This keeps SPF aligned under DMARC relaxed alignment, and lets you route and analyze bounces per stream.
Assign each stream its own IP or pool of IPs. If you send on shared infrastructure, make sure your provider uses different pools for transactional and promotional traffic. With dedicated IPs, each pool must have enough volume to keep a stable reputation; an IP that sends a few hundred messages a week is not better than a good shared pool.
The streams have different operational needs:
| Transactional | Marketing | |
|---|---|---|
| Latency | Seconds | Minutes to hours is fine |
| Throughput shape | Steady, follows user activity | Large bursts |
| Queue lifetime | Short for codes, longer for receipts | Longer |
| Priority | Highest | Can be throttled |
| Unsubscribe headers | Not required | Required (RFC 8058) |
A shared queue lets a one-million-recipient campaign sit in front of a login code. Separate queues, or at least strict priority, prevent that.
Track bounce rate, complaint rate, deferrals and inbox placement per stream. Verify each subdomain in Google Postmaster Tools so you see domain reputation per stream. If you only look at combined numbers, transactional volume will hide marketing problems.
Separation is not a way to escape a bad reputation. Rotating domains or IPs to avoid filtering ("snowshoeing") is a recognized spam tactic, and receivers connect related domains and infrastructure. M3AAWG's best practices treat that kind of evasion as abusive. The goal is fair isolation, so each stream earns its own reputation, not to hide one stream's problems.
In Pidgely, streams are a first-class concept: each stream sends from its own IP pool with automatic warm-up, so campaign traffic does not share IP reputation with your password resets, and bounces and complaints feed suppression lists automatically.
Transactional email is triggered by a user's action or account state, such as a password reset, receipt or security alert. Marketing email is sent to many recipients for promotional or editorial purposes, such as newsletters and campaigns.
Marketing mail generates more complaints and bounces. If both share an IP and domain, a bad campaign can delay or spam-folder critical messages like password resets and two-factor codes.
A subdomain gives each stream its own domain reputation signals, which matters a lot at providers like Gmail. Combined with separate IP pools, it isolates the streams well. Subdomains still share the organizational domain for DMARC and for Google's bulk-sender volume count.
Purely transactional messages are exempt from Google's and Yahoo's one-click unsubscribe requirement. Messages that mix transactional content with promotions are generally treated as marketing.
Pidgely team
Published
We build Pidgely, the email API that gets you to the inbox. We write about what we learn delivering email, citing the standards and mailbox provider guidelines behind every claim.
A practical IP warm-up guide: how to ramp volume on a new sending IP, which signals to watch at each mailbox provider, and the mistakes that reset reputation.
5 min read
Shared vs dedicated sending IPs explained: how reputation works on each, the volume you need for a dedicated IP, costs, risks and a simple decision framework.
5 min read
Should you run your own MTA or use an email API? A practical comparison of costs, deliverability work, control and vendor lock-in, plus how to stay portable.
6 min read