D-06 · REPUTATION · STREAM SPLIT
Splitting transactional and marketing reputation
One promotional spike should never delay a login code. This scenario defines the subdomain, stream, and suppression boundaries of a safe split.
Symptom
A Black-Friday-style campaign triggers bulk deferrals, and within hours users report late 2FA codes and missing receipts. Both message classes share one subdomain, one IP pool, and one suppression table. The provider throttles the degraded reputation wholesale, and transactional queues behind forty thousand promotional retries. Support tickets spike for a product problem caused entirely by a marketing decision.
The subtler symptom is preference corruption: a marketing unsubscribe suppresses transactional notifications because one global flag governs both, so users who opted out of newsletters stop receiving security alerts.
Cause
Mailbox providers and throttling systems score the sending identity — IP plus domain — not the marketer’s intent label. Shared identity means shared fate. Suppression conflation makes it worse: hard bounces, complaints, and unsubscribes each need different scope (global vs per-stream), but a single table applies the strictest rule everywhere or the loosest rule nowhere.
Template convergence adds content risk. Promotional design language (heavy images, link farms, urgency copy) leaking into transactional templates drags their fingerprint toward bulk classification even when reputation is technically separate.
Fix
Create three identities: transactional on its own subdomain and stream, marketing on another, and corporate correspondence untouched by either. Authenticate each independently with dedicated DKIM selectors and return-paths. In the vendor, use separate streams or subaccounts with independent suppression views: marketing unsubscribes never touch transactional; hard bounces and complaints suppress globally; transactional content stays plain, single-purpose, and minimally linked.
Backfill carefully: migrate transactional first during a quiet week, warm the new subdomain with live low-risk traffic (receipts, notifications), then move bulk. Dual-send nothing — duplicate identities confuse reputation history.
Prevention
Codify a message-classification table: every template declares its stream, subdomain, suppression scope, and SLA at creation. CI checks reject transactional templates with bulk fingerprints (excess links, image-only bodies, missing plain-text). Monitor per-stream bounce, complaint, and deferral SLAs independently, and review any proposal to “just send this promo from transactional for better opens” as a deliverability incident in advance — because that is what it is.
Worked example
An e-commerce sale sends 40,000 promotions in an hour from the same pool as order confirmations. Deferrals cascade, confirmations arrive six hours late, and “where is my order” tickets outnumber sale questions. Worse, a footer-unsubscribe click from the promo suppresses shipping notifications too, because one flag governs both streams.
The rebuild separates identities completely: confirmations on a transactional subdomain with plain templates and global-bounce-only suppression, promotions on a marketing subdomain with per-stream opt-outs, and a classification table enforced in CI. The next sale defers only its own stream — confirmations deliver in seconds throughout. Support ticket volume during sales drops by half, and marketing finally gets honest per-stream metrics instead of blended noise.