Building a Sending Pool Strategy for Mixed Traffic: 2026 IP Segmentation Patterns That Actually Work

A sending programme that mixes transactional, marketing, and behavioural traffic on a single IP pool conflates reputations that the receivers track separately. The transactional traffic accumulates strong engagement signals (recipients open password reset emails, click on order confirmation links, interact predictably and at high rates). The marketing traffic accumulates weaker engagement signals (recipients ignore most campaigns, complain about some, only a subset engage). Blending the two means the marketing complaints drag down the transactional reputation, and the transactional engagement props up the marketing pool to the point where the operator cannot see the marketing pool's real health.

This note covers how to design pool architecture for mixed-traffic programmes in 2026. The principles have been understood for over a decade, but the specifics around volume thresholds, engagement-based segmentation, and the over-segmentation trap have shifted as ML-driven receiver reputation has become more granular and as enforcement (Gmail, Yahoo, Microsoft since 2024-2025) has tightened. The piece is written for operators running infrastructure where the pool design is a real architectural decision, not for marketers reading platform guides about "best practices".

Why segment at all

Reputation attaches to identifiers. Multiple ones. Simultaneously.

Receivers attribute reputation to identifiers. The sending IP is one identifier. The From: domain is another. The DKIM signing domain, the bounce domain, the tracking domain in click URLs all contribute. Each of these identifiers accumulates reputation history over time based on how recipients react to messages bearing the identifier. A complaint on a marketing campaign attaches to the IP that sent it, the From: domain it came from, and the DKIM domain that signed it. A click on a transactional email attaches to the same identifiers if they happen to be shared with the marketing stream.

The conflation is the problem. ISPs cannot separate "this IP was sending transactional traffic that produced 12% click-through rate" from "this IP was sending marketing traffic that produced 0.4% complaint rate" if both traffic types went through the same IP. The receiver-side reputation engine sees the blended signal and treats the IP as a moderate-reputation sender, neither as good as the transactional stream alone would warrant nor as bad as the marketing stream alone would warrant. The downstream consequence: transactional messages sometimes route to spam folder, marketing messages sometimes deliver better than their underlying engagement deserves, and the operator has no visibility into which sub-stream is actually performing how.

Segmentation onto separate pools fixes the conflation. Each pool builds its own reputation. The transactional pool's strong engagement produces strong reputation. The marketing pool's weaker engagement produces appropriate reputation, with the operator able to see exactly how the marketing stream is performing. Crucially, a complaint spike on the marketing pool does not cascade into transactional deliverability problems, because the receiver-side reputation engines treat the two pools as independent senders.

Mail Streams and Reputation Realms

Two concepts from the deliverability literature deserve attention because they clarify how to think about segmentation.

A Mail Stream is a category of email that has substantively different content and mailing list from other categories. Transactional messages are one mail stream. Marketing campaigns are another. Behavioural triggers (cart abandonment, browse-and-buy reactivations, in-app event-triggered messages) often constitute a third. The defining characteristic of a mail stream is that an external observer looking at the messages would clearly see them as different things, not the same thing with different surface treatment. Password reset emails and product promotion emails are different mail streams. Newsletter A and newsletter B from the same sender to the same audience are usually the same mail stream.

A Reputation Realm is the architectural mechanism that maintains separate reputation for each mail stream. The reputation realm consists of the IP addresses sending the stream, the sending domain, the DKIM signing identifier, the tracking domain in URLs, and the reverse DNS configuration of the IPs. Separating two mail streams into two reputation realms means giving them different IPs, different sending domains (typically subdomains of the same root), different DKIM keys, different tracking domains, and ideally different reverse DNS hostnames. The stronger the realm separation, the cleaner the reputation isolation.

The 2026 receiver landscape rewards thorough realm separation more than it did five years ago. Receivers cross-reference IPs against sending domains against DKIM identifiers against tracking domains. Senders who isolate cleanly across all five dimensions produce sharper reputation signals than senders who segment IPs but share other identifiers across streams. The marginal complexity of full realm separation is small (it is mostly configuration work) and the deliverability benefit is meaningful.

The volume threshold that justifies segmentation

Segmentation is not free. Each additional pool requires its own warmup, its own monitoring, its own operational attention. The benefit of separation has to exceed the cost of additional pool management. The volume threshold below which segmentation does not pay for itself is roughly 50,000 messages per month on the smaller stream.

The volume-based decision framework looks roughly like this. Programmes under 10,000 messages per month should not attempt dedicated-IP segmentation at all; a reputable ESP shared pool outperforms anything the operator can build at that volume. Between 10,000 and 50,000 monthly, a single dedicated IP handling all traffic types is the appropriate posture, because no individual stream has enough volume to justify the operational burden of multiple pools. The 50,000 to 500,000 range is where the first meaningful segmentation appears: two pools, transactional separated from marketing, with each pool sustained above the minimum-volume floor. Between 500,000 and 5 million monthly, a third pool (behavioural traffic, or marketing-broad as a distinct sub-pool) becomes justifiable. The 5 million to 50 million range supports the full four-pool reference architecture with engagement-based marketing segmentation. Above 50 million, the architecture expands to include per-brand sub-pools, per-region sub-pools, or per-campaign-type sub-pools depending on the specific operational needs of the programme.

The principle behind the threshold: receivers require sustained sending volume to learn an IP's reputation. An IP that sends a thousand messages per week never establishes a stable reputation because the receiver-side learning signal is too sparse. A pool of two or three such IPs cannot produce useful reputation isolation; the IPs simply remain unknown to receivers, and unknown IPs default to neutral or slightly negative reputation treatment.

The practical floor for sustained reputation building is approximately 5,000 to 10,000 messages per IP per week. Below that, the IP is not generating enough signal to be learned reliably. Above it, the receiver-side reputation engines have enough data to build a stable picture. When designing a pool architecture, the operator should work backwards from this floor: how many IPs can the total volume support at the minimum sustained throughput, and how should those IPs be allocated across mail streams?

One exception applies. The asymmetric risk tolerance of transactional traffic sometimes justifies separation at lower volumes than the pure-volume math would suggest. If the transactional stream carries password resets, OTP codes, security alerts, or other messages where even brief deliverability degradation produces material business cost, separating it onto its own pool can be justified at much lower volumes than 50K monthly. The operator pays for a perpetually under-warmed transactional pool in exchange for not having marketing complaints affect transactional delivery. That trade is often worth it for high-value transactional streams.

Typical 2026 pool architecture for B2C senders

For a B2C sender at 5 to 50 million monthly volume, a workable architecture has four pools.

For a B2C sender at 5 to 50 million monthly volume, a workable architecture has four pools. They serve different functions and accumulate different reputations.

Pool 1: Transactional. Typically 10-25% of total volume. Handles password resets, receipts, security alerts, and similar critical messages. Throughput is consistent and flat (transactional messages do not have campaign-style spikes). Reputation is highest in the architecture because engagement signals are uniformly strong. The IPs do not rotate; the same IPs handle transactional traffic over time so receivers build a stable picture of the stream.

Pool 2: Marketing-engaged. Typically 35-50% of total volume. Sends campaigns to recipients who have demonstrated click engagement within the past 60-90 days. This is the "happy customers" stream that produces strong reputation because the audience is genuinely interested. Inbox placement on this pool consistently exceeds the marketing-broad pool by 5-15 percentage points.

Pool 3: Marketing-broad. Typically 20-40% of total volume. Sends campaigns to recipients without recent click engagement. Lower-engagement stream that absorbs the bulk of complaint and bounce risk. Isolating the broad pool from the engaged pool means that complaint events on broad campaigns do not contaminate the highly-engaged pool's reputation. Inbox placement is lower than the engaged pool by design.

Pool 4: Behavioural. Typically 5-15% of total volume. Handles cart abandonment messages, browse-and-buy reactivations, in-app event-triggered notifications, and similar behavioural messages. Often blended into the transactional pool if behavioural volume is low or kept separate when engagement patterns differ meaningfully from transactional traffic.

The four-pool architecture handles roughly 80% of B2C deployments we see in this volume range. Below 5M monthly, the architecture typically collapses to two or three pools (the engagement-based separation often disappears at lower volumes because the engaged pool does not have enough volume to sustain a separate IP at the minimum-volume floor). Above 50M monthly, the architecture expands to include per-brand sub-pools (for multi-brand senders), per-region sub-pools (for international programmes where European and North American volume can sustain separate IPs), or per-campaign-type sub-pools for specific campaign categories with materially different engagement patterns.

A B2B sender's typical architecture looks different. Lower total volume usually means fewer pools. The marketing-engaged versus marketing-broad split often disappears because the volume cannot support it. Behavioural traffic often blends into transactional. A two-pool architecture (transactional plus marketing) covers most B2B deployments through 5M monthly, with three pools (adding behavioural) appearing above that.

Transactional isolation as the non-negotiable

If you read nothing else from this note, read this section.

The single architectural decision that matters most across nearly all sending programmes is the isolation of transactional traffic from marketing traffic. If the sender does nothing else from this note, this one matters.

The reason is risk asymmetry. Marketing traffic can produce sudden complaint spikes, sudden bounce-rate increases from acquisition source issues, or sudden engagement drops from campaign content problems. Any of these can degrade IP reputation enough to push subsequent messages to spam folder for hours, days, or weeks. If transactional messages are on the same IP, the spam-folder routing also affects password resets, OTP codes, and receipt confirmations. Users who cannot receive their password reset in three minutes assume the service is broken; users whose receipt confirmation does not arrive call support. The business cost of transactional delivery problems is concrete and immediate, often exceeding the entire value of the marketing campaign that caused the reputation problem.

Transactional isolation through separate IPs, separate subdomains (typically transactional.brand.com versus marketing.brand.com or similar), separate DKIM keys, and separate tracking domains, eliminates this contamination path. A marketing complaint event still damages the marketing pool's reputation, but the transactional pool continues delivering normally because the receiver-side reputation engines treat the two pools as independent senders.

Engagement-based sub-pools

The next layer of segmentation. Worth doing only at scale.

Beyond the transactional versus marketing split, the next layer of segmentation that produces meaningful deliverability gains is engagement-based sub-pools within the marketing stream. The idea is to route messages to highly-engaged recipients through one IP set and messages to less-engaged recipients through a separate IP set.

The mechanism is straightforward. The highly-engaged pool sends to recipients who have clicked, converted, or replied within a recent window (typically 60-90 days). The less-engaged pool sends to recipients without recent engagement. The highly-engaged pool produces strong open, click, and engagement signals that build receiver-side reputation. The less-engaged pool produces weaker engagement signals that reflect the actual engagement quality of the audience segment, without contaminating the highly-engaged pool.

The pattern works when three conditions hold. First, the engagement signal used for segmentation must be reliable. Click-based segmentation works in the 2026 Apple MPP environment. Open-based segmentation does not (MPP-inflated opens make the engaged pool look engaged when it is not). Second, the volume on each sub-pool must sustain independent reputation, typically 10K+ messages per IP per week minimum. Third, the operator must be willing to act on the segmentation by reducing send frequency to less-engaged segments. The improved aggregate reputation comes partly from the segmentation itself and partly from the reduced send frequency to less-engaged contacts, which lowers the complaint rate on that sub-stream.

The deliverability improvement from engagement-based sub-pools is typically 5-15 percentage points of inbox placement on the highly-engaged pool versus the blended baseline, with the less-engaged pool falling 5-10 points below the blended baseline. The aggregate improvement is therefore modest in raw percentage terms, but the highly-engaged pool's improved placement disproportionately reaches the senders' best customers, which produces outsized business impact.

The over-segmentation trap

More pools is not better. Sometimes worse.

The mirror image of insufficient segmentation is over-segmentation: creating more pools than the volume supports, producing several under-warmed IPs that each fail to build proper reputation.

The symptoms are recognisable. Inconsistent deliverability across pools. IPs hovering at Low or Medium reputation in Google Postmaster Tools when the operator expected High. High variance in inbox placement that does not correlate with any obvious sending behaviour. New campaigns producing wildly different deliverability outcomes depending on which pool happened to handle them. All of these patterns indicate that the pools are not generating enough volume per IP to establish stable reputation.

The fix is consolidation. Combine pools that serve similar reputation profiles. Target the minimum-volume floor of 5,000 to 10,000 messages per IP per week as the architectural constraint, then design the pool count to satisfy it. Accept that a smaller number of healthy pools outperforms a larger number of marginal pools, even though the smaller architecture provides less granular isolation.

The "as many pools as we can justify" instinct is wrong. The correct instinct is "as few pools as the architecture requires". An operator with 1M monthly volume across two streams (transactional plus marketing) should run two pools, not four. The two-pool architecture provides clean isolation between the streams while keeping each pool above the volume floor. The four-pool architecture (transactional + marketing-engaged + marketing-broad + behavioural) would split the 1M across four IPs averaging 250K per pool per month, which is around 62K per IP per week, sustainable for sustained reputation building but with little margin for variance.

MTA configuration for pool routing

The pool architecture has to be enforced at the MTA layer, not just at the application layer. Application-layer logic that "should" route to the right pool sometimes does not, particularly under error conditions, retries, or unusual code paths. The MTA configuration provides the structural backstop.

In PowerMTA, each pool corresponds to a virtual MTA declaration with its own source IPs, DKIM signing, and delivery policies:

<virtual-mta transactional>
    smtp-source-host  198.51.100.10  trans.brand.com
    smtp-source-host  198.51.100.11  trans.brand.com
    domain-key        trans-2026, trans.brand.com, /etc/pmta/dkim/trans.key
</virtual-mta>

<virtual-mta mkt-engaged>
    smtp-source-host  198.51.100.20  mkt.brand.com
    smtp-source-host  198.51.100.21  mkt.brand.com
    domain-key        mkt-2026, mkt.brand.com, /etc/pmta/dkim/mkt.key
</virtual-mta>

<virtual-mta mkt-broad>
    smtp-source-host  198.51.100.30  mkt.brand.com
    domain-key        mkt-2026, mkt.brand.com, /etc/pmta/dkim/mkt.key
</virtual-mta>

The application submits each message with an x-virtual-mta header indicating the appropriate pool. PowerMTA routes the message through the named virtual MTA regardless of any error condition in the application layer. If the application fails to specify a virtual MTA, PowerMTA's default behaviour should be to fail the submission rather than falling back to a generic IP, so that submission errors are visible immediately.

Similar configuration patterns exist in KumoMTA and other modern MTAs. Postfix can implement equivalent routing through transport_maps and per-domain submission ports, though the configuration is less ergonomic than PowerMTA's virtual MTAs. The architectural principle is the same regardless of MTA: the pool routing has to be enforced at the MTA layer.

Per-pool monitoring

A pool architecture that does not include per-pool monitoring is incomplete. Aggregate metrics hide pool-level problems until they have already grown into deliverability incidents.

The per-pool metrics that matter at minimum:

• Google Postmaster Tools reputation per IP and per domain. Each pool should be visible separately in GPMT; check daily during warmup and weekly during steady-state.
• Per-pool complaint rate. Tracked against the 0.1% target (0.3% enforcement threshold). Per-pool view makes pool-level spikes visible immediately.
• Per-pool bounce rate. Hard bounces, soft bounces, and reason codes broken down by pool. Bounce patterns differ between transactional, marketing, and behavioural streams; per-pool view reveals which pool has list-quality issues.
• Per-pool delivery latency. Time from submission to acceptance, broken down by destination ISP and pool. Latency spikes on specific pool-ISP combinations indicate impending blocking before hard rejections appear.
• Per-pool engagement (click rate, conversion rate). Aggregated per pool to detect engagement-quality drift.

The dashboard discipline that works in production: per-pool views as the default, aggregate as the secondary. Operators who start their day looking at aggregate metrics miss the early signals that per-pool views surface. Operators who start with per-pool views see the developing patterns and act on them before they become incidents.

Pool strategy selector

The interactive selector below produces a pool architecture recommendation based on programme characteristics.