Operational Notes

• October 2025
• Engineering Memo · External Release

Separating Cold, Bulk, and Transactional Traffic at the Infrastructure Level

Infrastructure Configuration Principles

The configuration principles that address this operational pattern require understanding both the mechanism and the ISP response system. ISPs do not apply uniform treatment to all senders — they calibrate their response based on behavioral history, volume trends, authentication quality, and complaint signals. Configuration that works for one sender at one volume level may produce different results for another sender at the same volume level, because the underlying reputation history differs.

This means that configuration guidance must always be contextualized: the specific values recommended here are starting points for environments with established IP reputation and clean authentication. New IPs, freshly warmed infrastructure, and environments recovering from reputation events require more conservative starting values with gradual adjustment as reputation signals improve.

The Monitoring Discipline

Effective monitoring for the patterns described in this note requires a discipline that most email operations organizations do not yet have: daily review of ISP-specific metrics with trend awareness. Not weekly review — not "we check when something seems wrong" — but daily review with explicit comparison to the previous day's data and the seven-day rolling average. This level of attention reveals emerging patterns while they are still manageable.

The monitoring investment pays dividends that are difficult to quantify before an incident but obvious after one. Infrastructure teams that maintain this discipline consistently detect reputation events early, respond to them before they become severe, and recover from them faster. The alternative — detecting problems only when they affect aggregate delivery rates — means operating with a multi-week lag between problem onset and detection.

Most organizations sending email at scale operate with at least two categories of outbound traffic: marketing or bulk email, and transactional messages. Many also operate a third category: cold outreach. The common infrastructure pattern — routing all three through the same sending domain and IP addresses — creates a dependency structure where problems in any one category affect all others.

Why the Categories Require Separation

Each traffic category carries a different risk profile and is evaluated differently by ISP reputation systems. Cold outreach — messages sent to recipients who have not previously engaged with the sender — has the highest baseline reputation risk. Sending to contacts who have not opted in produces higher complaint rates by nature. ISPs apply more conservative evaluation to cold traffic, and a complaint spike from a cold campaign directly affects the sending domain's reputation.

Bulk marketing email to opted-in lists carries moderate reputation risk. Complaint rates should be low if list hygiene automation practices are maintained, but campaign-specific factors — frequency, content, segment selection — introduce variability. A poorly segmented campaign or a reactivation sequence to a dormant list can produce complaint patterns that affect domain reputation for subsequent campaigns.

Transactional messages — password resets, order confirmations, account notifications — carry low reputation risk and high delivery urgency. Recipients expect and want these messages. The problem is not the messages themselves; it is that they share infrastructure with higher-risk traffic categories. A domain that experiences reputation degradation from a bulk campaign will also deliver its transactional messages with degraded inbox placement.

What Separation Requires at the Infrastructure Level

Domain separation. Each traffic category should send from its own set of domains. Transactional messages send from the primary business domain (company.com). Bulk marketing sends from a dedicated marketing subdomain or separate domain. Cold outreach sends from purpose-built sending domains entirely separate from the primary domain. This ensures that reputation events on cold or bulk traffic domains do not affect the primary domain's evaluation by ISP reputation systems.

IP pool separation. Each traffic category routes through its own IP addresses. This prevents throttling decisions made by ISPs based on cold or bulk traffic behavior from affecting transactional delivery. It also enables per-category reputation monitoring — understanding the reputation state of each IP pool independently rather than evaluating a mixed signal across all traffic.

MTA routing separation. At the MTA layer, routing rules ensure that each message category is directed to the appropriate IP pool for its traffic type. Applications route to SMTP endpoints designated for their traffic category. This configuration is maintained by the engineering team and not subject to application-level changes that could accidentally cross traffic into the wrong pool.

The Operational Cost of Mixing Traffic

Organizations that discover they need traffic separation typically do so after a reputation event has already affected their primary domain. Rebuilding separation after the fact requires creating new sending domains, warming new IP addresses, and migrating traffic — all while the primary domain recovers. The timeline for full separation with proper warming is measured in weeks. The cost of building the separation before it is urgently needed is the same effort applied before the event rather than during it.

Operational Implications and Production Guidance

The operational principles behind this pattern apply across a wide range of infrastructure configurations and volume levels. The specific thresholds and timing may differ, but the underlying logic is consistent: ISP reputation systems respond to behavior patterns over time, not to individual sending events. Managing behavior patterns — not just individual sends — is the fundamental discipline of production email infrastructure operations.

Practically, this means that every configuration decision should be evaluated not just for its immediate effect but for its effect on the long-term behavior pattern that ISP reputation systems observe. A configuration that produces optimal throughput today at the cost of a behavior pattern that degrades reputation over three months is not an optimal configuration — it is a delayed problem. The evaluation horizon for configuration decisions should extend at least 4-8 weeks beyond the immediate operational need.

Monitoring and Early Detection

The monitoring infrastructure required to detect this pattern early is not complex, but it requires consistent attention. The core requirement is ISP-specific high deferral rate diagnosis tracking at hourly granularity, with trend analysis extending over rolling 7-day and 30-day windows. This provides the temporal context that separates normal variation from meaningful degradation trends.

Secondary monitoring for bounce rate by destination ISP and FBL complaint rate by sending segment provides additional signal dimensions. When multiple metrics move simultaneously in the same direction at the same ISP, the probability that the movement reflects a genuine reputation change — rather than random variation — increases substantially.

Recovery and Long-Term Management

Managing email infrastructure for sustained performance requires treating reputation as a long-term asset rather than a short-term operational condition. The infrastructure decisions that preserve reputation — correct authentication, appropriate throttle configuration, high-quality list hygiene, careful IP warming — have cumulative positive effects that compound over months and years. Infrastructure operated with these disciplines consistently outperforms infrastructure that addresses problems reactively, even if the reactive approach succeeds in the short term.

The Cloud Server for Email infrastructure team applies these principles across all managed environments. The operational notes series documents the specific patterns and mechanisms we observe most frequently, with the intention that operators across the industry can apply the same discipline to their own infrastructure without having to discover each pattern through trial and error.