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

• June 2021
• Engineering Memo · External Release

Email infrastructure serving multiple traffic types — cold outbound prospecting, permission-based promotional campaigns, and transactional system messages — is confronted with a fundamental reputation isolation challenge. Each traffic type generates different signal quality: transactional email (order confirmations, password resets) produces near-zero complaints and near-perfect engagement; promotional email produces higher complaint rates and moderate engagement; cold email produces the highest complaint rates and lowest engagement. When these traffic types share infrastructure, the lower-quality signals from cold or promotional email contaminate the reputation that transactional email depends on for reliable delivery.

This note documents the infrastructure architecture for separating these three traffic types — the specific IP pool, domain, and routing decisions that prevent the quality profile of one traffic type from degrading the delivery performance of another.

Why Each Traffic Type Requires Isolation

Transactional email is the highest-priority and most quality-sensitive traffic type. Recipients expect these messages (order confirmations, password resets, two-factor authentication codes, account alerts) and are least likely to mark them as spam. The complaint rate for well-configured transactional email is typically below 0.01% — substantially lower than promotional email from the same programme. Transactional email also has the strictest delivery timing requirements: a password reset that takes 45 minutes to arrive is a customer experience failure; a promotional newsletter that takes 3 hours is merely slower than ideal.

Promotional bulk email occupies the middle quality position. Permission-based promotional campaigns to engaged subscribers generate complaint rates of 0.02–0.05% for well-managed programmes, and engagement rates of 15–30%. These complaint rates, while acceptable for promotional standards, are substantially higher than transactional email produces. Sharing infrastructure with transactional email would allow promotional complaint signals to affect the IP reputation that transactional email depends on for immediate delivery.

Cold email (outbound prospecting to contacts who have not opted in) generates structurally higher complaint rates — typically 0.10–0.30% — because recipients who did not expect or request the email are more likely to mark it as spam. Cold email must be completely isolated from both promotional and transactional traffic, using dedicated IPs, a dedicated sending domain, and ideally a dedicated MTA instance or VMTA to prevent any signal contamination of the other traffic types.

The Domain Separation Requirement

Traffic type separation requires domain-level separation as well as IP-level separation. A transactional SMTP pool that uses the same signing domain as the promotional pool shares domain reputation — the promotional campaign's complaint signals are attributed to the same domain that signs transactional messages, affecting the domain reputation that transactional delivery depends on.

The domain structure for three-tier traffic separation: transactional email from mail.brand.com; promotional email from news.brand.com; cold email from a completely separate root domain (brand-reach.com or similar). The transactional and promotional subdomains share the root domain's overall reputation but maintain independent subdomain-level reputation signals at ISPs that track subdomain reputation separately (Gmail's Postmaster Tools can show per-subdomain spam rate if each is registered separately). The cold email domain must be entirely separate from the brand domain — cold email complaint signals attributed to a brand.com subdomain contaminate the root domain reputation that all brand.com sending depends on.

DKIM signing should be configured separately for each traffic tier, using selectors that identify the traffic type: tx selector for transactional, promo for promotional, cold for cold email. This naming convention makes the DKIM-Signature header in any message immediately identify which traffic tier the message belongs to — useful for debugging and for DMARC aggregate report analysis that shows per-selector authentication pass rates.

Routing Logic: Application-to-Infrastructure

The separation architecture requires routing logic in the application layer that directs each message type to the correct VMTA. The routing must be enforced at the application level — the infrastructure provides the isolated pools, but the application must correctly classify each outgoing message and route it to the appropriate pool. Routing errors (cold email injected into the transactional VMTA, or a bulk campaign sent through the transactional pool) defeat the separation architecture immediately and may produce reputation contamination before the error is detected.

The routing implementation in MailWizz: configure separate delivery servers for each traffic tier, each pointing to the correct SMTP port or VMTA binding on the PowerMTA instance. Transactional messages (sent via MailWizz's transactional API) route to the transactional delivery server; campaigns route to the promotional delivery server. Cold email uses its own dedicated MailWizz installation or campaign group configured to use only the cold email delivery server.

The application routing should be validated periodically — monthly check that each delivery server is receiving only its intended traffic type, by reviewing the accounting log virtual MTA distribution for each server. A routing validation that finds cold email messages in the promotional VMTA's accounting log indicates a configuration error that should be corrected immediately before the cold email's signal quality degrades the promotional pool's reputation.

Monitoring Each Tier Independently

Three-tier separation requires three-tier monitoring. Each traffic tier needs its own Postmaster Tools domain registration (to receive per-tier spam rate and domain reputation data), its own SNDS IP registration (to monitor each tier's IP pool separately), its own FBL registration (to receive per-tier complaint data attributable to the correct domain), and its own accounting log queries (to calculate per-tier delivery rate, deferral rate, and bounce rate).

Without per-tier monitoring, a problem in one tier is invisible in the aggregate metrics. A cold email pool generating elevated complaint rates at Gmail will produce a Postmaster Tools spam rate spike for the cold email domain — which is correctly contained to that domain and does not affect the promotional or transactional domain's Postmaster Tools data. Per-tier monitoring confirms this containment and allows the cold email issue to be investigated and resolved without conflating it with the promotional or transactional tier's data.

Implementation Sequence and Transition Planning

For programmes currently operating without traffic separation — all message types going through the same IP pool and domain — the transition to three-tier separation should be sequenced to minimise reputation disruption. The recommended sequence: first, carve out transactional traffic (highest priority, most quality-sensitive, safest to move first because its clean signals will only benefit the new transactional pool); second, separate cold email onto its own completely isolated infrastructure (most important to isolate, but may require new domain registration and warmup); third, confirm the remaining traffic is exclusively promotional and optimise the promotional pool configuration for its specific audience and quality profile.

The warmup requirement for new pools applies to each tier as it is separated. The transactional pool's new IPs need warmup using transactional volume (which is naturally high-quality). The cold email pool needs warmup using the cleanest available cold email segments. The promotional pool may already have established reputation if it is continuing to use existing IPs — only the domain separation change may require monitoring attention rather than full re-warmup.

Three-tier traffic separation is the foundational architecture decision that enables each traffic type to perform at its natural quality level — transactional email delivers immediately at near-perfect reliability, promotional email builds reputation based on the programme's actual engagement quality, and cold email operates in an isolated pool where its structurally higher complaint rates are contained. The architecture investment pays returns on every send of every traffic type, compounding over time as each tier builds independent reputation that reflects its specific quality profile.

The Cost of Not Separating

Programmes that operate without traffic type separation pay a reputation cost that manifests as inbox placement below what each traffic type's quality level should produce. A transactional email pool contaminated by promotional complaint signals may produce 92% inbox placement at Gmail when the transactional traffic's near-zero complaint rate should produce 99%+. That 7-percentage-point gap represents customer experience failures — password reset emails landing in spam, two-factor authentication codes missed, order confirmations not seen. The commercial cost of these failures (support volume, customer frustration, failed authentication attempts) is difficult to quantify precisely but is consistently higher than the infrastructure cost of the separate transactional pool that would have prevented them.

The promotional pool contaminated by cold email signals operates with an artificial reputation ceiling. A promotional programme with excellent list quality and low complaint rates that shares infrastructure with cold email is receiving the cold email's complaint signals as a reputation tax — paying a reputation penalty for the cold email's signal quality rather than receiving the full reputation benefit of the promotional programme's own quality. Separating the pools allows the promotional pool to build the reputation its quality deserves, without the cold email discount applied by shared infrastructure.

The cold email pool that shares infrastructure with promotional or transactional email is a reputational liability for both. A cold email campaign that generates elevated complaints on a shared promotional IP damages the promotional pool's reputation for days to weeks after the cold send. A single cold email event that triggers a Spamhaus listing affects all traffic types sharing that IP — including time-sensitive transactional messages that cannot wait for the delisting process. The separation architecture eliminates this cross-contamination, confining cold email's reputation consequences to the cold email pool where they belong.

Queue-Life Configuration Per Traffic Tier

The queue-life setting — how long PowerMTA retries message delivery before expiring the message — should differ by traffic tier. Transactional messages (password resets, authentication codes) have very short operational windows — a two-factor authentication code that arrives 4 hours after the authentication attempt is useless and confusing. The queue-life for transactional VMTAs should be set to 1–2 hours maximum: if a transactional message cannot be delivered within 2 hours, the triggering event (authentication attempt, purchase confirmation) has almost certainly expired or been superseded.

Promotional messages have longer acceptable delivery windows — a promotional campaign that delivers over 6 hours is still commercially valuable. Queue-life for promotional VMTAs should be set to 3–5 days, allowing sufficient retry time for messages deferred by ISP greylisting or throttle events while avoiding the indefinite accumulation of stale promotional messages that have missed their optimal engagement window.

Cold email queue-life should reflect the business context — prospecting emails that haven't delivered within 5 days are unlikely to generate useful pipeline and should be expired rather than continuing to generate retry traffic. A 3–5 day queue-life for cold email VMTAs is typically appropriate. The different queue-life settings per VMTA ensure that time-sensitive transactional messages are not held in queue beyond their useful life while allowing promotional and cold email messages the retry time their less time-sensitive nature warrants.

The Delivery Priority Hierarchy

When infrastructure resources are constrained — during a high-volume promotional campaign send that is consuming significant throughput — transactional messages should have delivery priority over promotional or cold email messages. PowerMTA supports message priority settings that allow the transactional VMTA's queue to be processed before the promotional VMTA's queue when they are competing for connection slots to the same destination ISP.

The priority hierarchy: transactional (highest priority), promotional (standard priority), cold email (lowest priority). This hierarchy ensures that a password reset request that arrives during a large promotional campaign delivery window is not delayed by the campaign's queue depth — the transactional VMTA's priority setting ensures it is processed ahead of the promotional queue. The cold email queue is processed with lowest priority, accepting that its delivery window may extend during periods of high promotional volume, which is commercially acceptable for prospecting email where a few hours of delivery delay has no meaningful business impact.

Traffic type separation at the infrastructure level is not merely a reputation management practice — it is the architecture that allows each traffic type to operate according to its specific delivery requirements, quality characteristics, and business value. The architecture investment produces compounding returns: transactional reliability improves as the pool is freed from promotional signals, promotional reputation improves as cold email signals are isolated, and the programme's overall deliverability performance reflects each traffic type's actual quality rather than the averaged quality of a co-mingled pool. Separate what needs to be separate; manage what you can measure independently; and let each tier's quality determine its own reputation trajectory without interference from the others.

ISP-Specific Configuration Differences by Traffic Type

Each traffic tier benefits from ISP domain block configurations calibrated to its specific delivery characteristics. Transactional email to Gmail does not need the same retry interval configuration as promotional email — transactional messages should retry more aggressively (shorter initial retry, more attempts before expiry) to meet the 1-2 hour queue-life requirement. Promotional email retries should use the standard exponential backoff that ISP throttle patterns require. Cold email retries should be gentler still, with longer intervals to avoid accelerating throttle responses from ISPs that are already treating cold email more cautiously.

The per-tier, per-ISP configuration matrix is more complex than single-tier infrastructure, but it produces more efficient delivery for each traffic type. A transactional email to Outlook that receives a greylisting deferral should retry in 2 minutes; a promotional email to the same destination can wait 10 minutes; a cold email can wait 20 minutes. The different retry intervals reflect the different delivery urgency of each traffic type and produce better outcomes — the transactional message clears the greylist window quickly, the promotional message retries at a pace that respects ISP rate limits, and the cold email retry load is minimised to reduce its footprint on shared ISP rate resources.

The infrastructure separation documentation should include the per-tier, per-ISP configuration matrix — which domain blocks are configured in each VMTA, with which retry settings, for which major ISPs. This documentation serves as both the operational reference for configuration changes and the audit record that confirms the separation architecture is correctly configured. Configuration drift — a domain block in the transactional VMTA that has reverted to global defaults rather than transactional-appropriate settings — is more likely to be caught and corrected when the documentation provides an explicit target configuration to compare against.

Reporting and Attribution in Three-Tier Infrastructure

Three-tier traffic separation enables attribution reporting that co-mingled infrastructure cannot provide: the delivery rate, inbox placement rate, and reputation status for each traffic type independently. Marketing leadership can see the promotional tier's performance; product leadership can see the transactional tier's reliability; sales leadership can see the cold email tier's deliverability. Each audience receives the metrics relevant to their operational context without the noise of other traffic types in the aggregate numbers.

The attribution reporting requires the accounting log brand and VMTA identifier fields described in the logging architecture note. With these fields, the daily and weekly monitoring queries can be filtered by VMTA to produce per-tier delivery rate, per-tier bounce rate, and per-tier deferral rate. The per-tier reports can be distributed to the relevant stakeholders for each tier rather than producing a single aggregate report that presents the average of three very different traffic quality profiles as if it were a single coherent performance story.

Infrastructure separation enables performance attribution, and performance attribution enables quality accountability. When the transactional tier's delivery rate declines, the investigation can immediately focus on what changed in the transactional tier — without having to disentangle it from promotional or cold email changes that might be occurring simultaneously. When the cold email tier's complaint rate rises, the containment is confirmed by showing that the promotional and transactional tiers' metrics are unaffected. This operational clarity is the management dividend of the separation architecture, paid out in faster incident diagnosis, cleaner accountability, and more confident infrastructure management across all three traffic tiers simultaneously.

Starting from Scratch vs Retrofitting Separation

Programmes implementing traffic separation for the first time face different challenges depending on whether they are building new infrastructure or retrofitting separation onto existing co-mingled infrastructure. New infrastructure builds are straightforward — design the three-tier architecture from the beginning, warm each pool for its intended traffic type, and deploy the routing logic before any production traffic is sent. There is no reputation history to protect or reconfigure.

Retrofitting separation onto existing co-mingled infrastructure requires more care. The transactional pool separation is highest priority: provision new transactional IPs, configure the transactional VMTA, verify the routing logic, and gradually shift transactional traffic to the new pool while monitoring delivery rate to confirm the new pool is performing acceptably. This transition can be completed in 2-3 weeks for a programme with low transactional volume, and 4-6 weeks for higher-volume transactional senders that require more careful warmup.

Cold email separation during a retrofit requires new domain registration, new IP provisioning, and a full warmup cycle before any cold email volume shifts to the new pool. The existing promotional pool continues to handle the current cold email volume during the cold email pool warmup period — which is the last phase of the retrofit, ensuring that the warmup occurs before the cold email is moved rather than after. The retrofit sequence: transactional separation first, cold email separation last, with the promotional pool as the stable centre of the transition.

The investment in traffic type separation — whether in new infrastructure or retrofitted to existing — pays returns immediately in transactional delivery quality, progressively in promotional reputation improvement, and definitively in cold email isolation that eliminates cross-contamination as a reputation risk. The architecture is the foundation that makes each traffic type's quality determine its own fate rather than bearing the reputation consequences of every other traffic type sharing the same infrastructure. Build it correctly, maintain the separation discipline through monitoring, and the three-tier infrastructure becomes the competitive advantage that enables each traffic type to deliver at its natural quality ceiling rather than at the average of a co-mingled pool.

Three-tier traffic separation is the infrastructure architecture decision that delivers the highest compound return of any single infrastructure design choice available to multi-traffic-type senders. Make it intentionally, make it correctly, and maintain it consistently.