Contents
- Why separation matters in 2026
- How cold and bulk differ operationally
- VMTA pool design for separation
- IP allocation per stream
- Domain and subdomain separation
- SPF, DKIM, DMARC alignment per stream
- Throttling differences between streams
- smtp-source-host configuration per pool
- Complaint rate ceilings per stream
- Multi-tenant patterns for agencies and ESPs
Why separation matters in 2026
The 2026 deliverability environment makes separation between cold email and bulk marketing email more important than at any previous point. Gmail and Yahoo's bulk sender requirements (in effect since February 2024) impose specific compliance obligations on senders exceeding 5000 messages per day, complaint rate ceilings of 0.3% with hard cutoff at 0.5%, mandatory DMARC alignment, mandatory one-click unsubscribe. Cold email by its nature carries higher complaint rates than opt-in marketing because recipients did not consent to receive it. Mixing both streams through the same infrastructure means cold email's complaint pressure pushes the combined sender above the 0.3% threshold, triggering throttling on the entire infrastructure including the legitimate marketing traffic.
The architectural answer is separation at every layer where reputation accumulates: separate IPs, separate sending domains, separate VMTAs in PowerMTA, separate authentication paths. Done properly, the marketing stream maintains its reputation regardless of how cold email reputation evolves; cold email gets its own reputation budget that can absorb the inevitable complaint pressure without contaminating other streams.
This guide exists because the integration between cold email operations and bulk marketing operations is where many ESPs and agencies make architectural decisions that prove expensive later. Operators frequently start with combined infrastructure to save money or complexity, then discover during a complaint spike that the separation they should have built upfront would have prevented a deliverability crisis. The structure of this guide: the operational differences between streams, VMTA pool design patterns, IP allocation calculations, domain separation, authentication alignment, throttling differences, smtp-source-host configuration per pool, complaint rate ceilings that differ by stream, multi-tenant patterns when running this for multiple customers.
How cold and bulk differ operationally
The operational profiles of the two streams differ in ways that justify architectural separation:
| Attribute | Bulk marketing | Cold email |
|---|---|---|
| Recipient consent | Opted in | No prior relationship |
| Complaint rate typical | 0.01-0.15% | 0.3-2%+ |
| Inbox placement target | 92%+ | 50-70% realistic |
| Sends per IP per day | 1000s-100000s | 30-50 per inbox/IP combo |
| Engagement (open rate) | 15-30% | 20-40% (smaller list) |
| Engagement (reply rate) | Low, automation focus | 1-5% target |
| Domain reputation evolution | Builds steadily with hygiene | Deteriorates eventually, plan for rotation |
| Subscriber lifecycle | Long-term retention | Single-message or short sequence |
| Content patterns | Designed templates with images, CTAs | Plain text, personalized, conversational |
| List source | Owned signups | Scraped or purchased prospect data |
The complaint rate difference alone justifies architectural separation. Bulk marketing at 0.1% complaint rate operates well within Gmail/Yahoo's 0.3% safe threshold; cold email at 1% complaint rate would immediately push combined infrastructure above the 0.5% hard cutoff causing immediate throttling. Separation keeps each stream within its own compliance envelope.
VMTA pool design for separation
The PowerMTA architectural pattern for stream separation: separate virtual-mta-pool definitions for each stream, with explicit VMTAs bound to dedicated source IPs per stream.
# Marketing pool - 4 IPs for bulk opt-in marketing
<virtual-mta marketing-vmta-1>
smtp-source-host 203.0.113.42 mta1.marketing.example.com
domain-key key1,marketing.example.com,/etc/pmta/keys/marketing.pem
</virtual-mta>
<virtual-mta marketing-vmta-2>
smtp-source-host 203.0.113.43 mta2.marketing.example.com
domain-key key1,marketing.example.com,/etc/pmta/keys/marketing.pem
</virtual-mta>
<virtual-mta marketing-vmta-3>
smtp-source-host 203.0.113.44 mta3.marketing.example.com
domain-key key1,marketing.example.com,/etc/pmta/keys/marketing.pem
</virtual-mta>
<virtual-mta marketing-vmta-4>
smtp-source-host 203.0.113.45 mta4.marketing.example.com
domain-key key1,marketing.example.com,/etc/pmta/keys/marketing.pem
</virtual-mta>
<virtual-mta-pool marketing-pool>
virtual-mta marketing-vmta-1
virtual-mta marketing-vmta-2
virtual-mta marketing-vmta-3
virtual-mta marketing-vmta-4
</virtual-mta-pool>
# Cold pool - 20 IPs for outbound prospecting
<virtual-mta cold-vmta-1>
smtp-source-host 198.51.100.10 mta1.outreach-co.com
domain-key cold1,outreach-co.com,/etc/pmta/keys/cold1.pem
</virtual-mta>
<virtual-mta cold-vmta-2>
smtp-source-host 198.51.100.11 mta2.outreach-co.com
domain-key cold1,outreach-co.com,/etc/pmta/keys/cold1.pem
</virtual-mta>
# ... cold-vmta-3 through cold-vmta-20 ...
<virtual-mta-pool cold-pool>
virtual-mta cold-vmta-1
virtual-mta cold-vmta-2
# ... through cold-vmta-20 ...
</virtual-mta-pool>
# Transactional pool - 1-2 IPs for critical messages
<virtual-mta transactional-vmta-1>
smtp-source-host 203.0.113.50 mta-tx.example.com
domain-key key1,example.com,/etc/pmta/keys/transactional.pem
</virtual-mta>
<virtual-mta-pool transactional-pool>
virtual-mta transactional-vmta-1
</virtual-mta-pool>The substantive points: each VMTA has its own source IP and EHLO hostname matching that IP's rDNS; marketing and cold VMTAs use different domain-keys with different sending domains; pools group VMTAs that should share reputation while keeping separation between pools.
Applications inject X-Virtual-MTA headers pointing to the appropriate pool: marketing campaigns inject X-Virtual-MTA: marketing-pool, cold sequences inject X-Virtual-MTA: cold-pool, transactional API calls inject X-Virtual-MTA: transactional-pool. PowerMTA routes accordingly with the per-pool throttling, IP rotation, and reputation isolation maintained automatically.
IP allocation per stream
IP allocation calculations differ significantly between streams.
Marketing IPs. The benchmark is 1 IP per 100K-500K monthly sends with proper warmup. A team sending 2M monthly newsletter messages might use 4-8 IPs with concentrated reputation building. Marketing IPs benefit from sending volume because volume signals legitimate engaged subscriber base to receiving MTAs.
| Marketing monthly volume | IPs recommended | Per-IP daily volume target |
|---|---|---|
| Under 100K | 1 | 3000-5000 |
| 100K-500K | 1-2 | 5000-15000 |
| 500K-2M | 2-4 | 10000-30000 |
| 2M-10M | 4-8 | 20000-50000 |
| 10M+ | 8-20+ | 30000-100000+ |
Cold email IPs. The calculation is fundamentally different. Standard cold email infrastructure uses 1 inbox plus 1 IP per 30-50 daily cold emails, which means cold email volume requires many IPs. The 1:1 IP-to-inbox ratio is now standard in cold email space for 2026 because shared pools expose senders to each other's deliverability issues.
| Cold email daily volume | IPs/inboxes recommended | Per-IP daily volume |
|---|---|---|
| 50 per day | 1-2 | 30-50 |
| 200 per day | 4-6 | 30-50 |
| 500 per day | 10-15 | 30-50 |
| 1000 per day | 20-30 | 30-50 |
| 2000+ per day | 40+ | 30-50 |
The cold IP count scales linearly with volume because each IP needs limited daily exposure to maintain even moderate reputation. Pushing higher per-IP volume triggers immediate throttling.
For an operator running both streams: typical mid-range allocation might be 4-8 marketing IPs handling 2M monthly newsletters plus 20-30 cold IPs handling 500 daily prospect messages. Total infrastructure: 30-40 IPs distributed across separate pools with strict reputation isolation.
Domain and subdomain separation
Domain separation matters even more than IP separation in 2026 because domain reputation increasingly dominates ranking decisions post bulk sender requirements.
Primary brand domain (example.com). Use for transactional email exclusively. Build the strongest possible reputation with rigorous DMARC enforcement (p=reject), DKIM signing, SPF alignment. This is your trust anchor.
Marketing subdomain (news.example.com or marketing.example.com). Use for opted-in bulk marketing. Inherit parent domain authority while isolating marketing reputation events from the primary brand. DMARC at p=quarantine initially, progressing to p=reject as alignment proves reliable.
Cold email domains (example-co.com, example-team.com). Use exclusively for outbound prospecting. Separate top-level domains specifically purchased for cold outreach. Considered disposable when reputation eventually deteriorates from complaint pressure. Multiple domains in rotation typical for high-volume cold operations (2-5 cold domains per cold pool). Authentication setup mirrors primary domain pattern but operates independently.
| Stream | Domain example | DMARC policy | Lifecycle expectation |
|---|---|---|---|
| Transactional | example.com | p=reject | Permanent, protect at all costs |
| Marketing | news.example.com | p=quarantine to p=reject | Long-term, maintain reputation |
| Cold email primary | example-co.com | p=quarantine | 1-3 years before rotation |
| Cold email secondary | example-team.com | p=quarantine | 1-3 years before rotation |
The cost of additional domains is negligible ($10-15 per domain annually) compared to the deliverability cost of unified domain reputation. An operator running 5 cold domains across cold pools spends $50-75 annually on domain registration to maintain separation from primary brand reputation.
SPF, DKIM, DMARC alignment per stream
Each stream requires complete authentication setup independent of other streams.
Marketing stream SPF. The SPF record at news.example.com authorizes only the marketing pool IPs:
news.example.com TXT "v=spf1 ip4:203.0.113.42 ip4:203.0.113.43 ip4:203.0.113.44 ip4:203.0.113.45 -all"Marketing stream DKIM. Generate a DKIM keypair for news.example.com, publish the public key as TXT at selector._domainkey.news.example.com, configure PowerMTA to sign with the private key:
# PowerMTA domain-key directive
<virtual-mta marketing-vmta-1>
smtp-source-host 203.0.113.42 mta1.news.example.com
domain-key key1,news.example.com,/etc/pmta/keys/news_marketing.pem
</virtual-mta>Marketing stream DMARC. Publish DMARC at _dmarc.news.example.com:
_dmarc.news.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100;"Cold stream authentication mirrors this pattern using the cold domain throughout:
# SPF
example-co.com TXT "v=spf1 ip4:198.51.100.10 ip4:198.51.100.11 ... -all"
# DKIM TXT record at cold1._domainkey.example-co.com
# DMARC at _dmarc.example-co.com
_dmarc.example-co.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100;"The cold pool VMTAs sign with the cold-domain key:
<virtual-mta cold-vmta-1>
smtp-source-host 198.51.100.10 mta1.outreach-co.com
domain-key cold1,outreach-co.com,/etc/pmta/keys/cold1.pem
</virtual-mta>The substantive operational point: each stream's SPF includes only its own pool IPs; each stream's DKIM signs with its own key; each stream's DMARC policy enforces alignment for its own domain. Cross-stream contamination is prevented at the authentication layer because cold email cannot sign with marketing's DKIM key and marketing's SPF does not authorize cold pool IPs.
Throttling differences between streams
Throttling per stream reflects the different operational profiles.
Marketing pool throttling (per-VMTA in PowerMTA):
domain gmail.com {
max-msg-rate 3000/h # Generous for warm marketing IPs
max-conn-rate 20/m
max-smtp-out 15
retry-sequence 5m,10m,15m,30m,1h,4h
backoff-retry 30m
backoff-after 10 errors
}Cold pool throttling (much more conservative per-VMTA):
domain gmail.com {
max-msg-rate 30/h # Match cold email per-IP daily budget
max-conn-rate 2/m
max-smtp-out 2
retry-sequence 15m,30m,1h,4h
backoff-retry 2h
backoff-after 3 errors # Strict because cold reputation is fragile
}The cold pool throttling enforces the 30-50 daily cold email per IP budget at the PowerMTA level rather than relying on the application to send at appropriate pace. If the application accidentally sends more, PowerMTA throttles automatically rather than producing a reputation incident.
PowerMTA processes throttling per VMTA, so when the marketing pool and cold pool both have domain blocks for gmail.com, each pool's throttling applies independently. Marketing pool sends at 3000/h, cold pool sends at 30/h per IP, neither stream pressures the other.
smtp-source-host configuration per pool
The smtp-source-host directive in each VMTA sets two things: the outbound source IP for delivery (PowerMTA binds to this IP for outbound TCP) and the EHLO hostname presented to receiving MTAs.
<virtual-mta marketing-vmta-1>
smtp-source-host 203.0.113.42 mta1.news.example.com
</virtual-mta>Reading the directive: outbound deliveries from this VMTA come from IP 203.0.113.42; EHLO presents mta1.news.example.com as the hostname. Receiving MTAs check that the EHLO hostname's forward DNS resolves to the source IP and that the IP's reverse DNS (rDNS) resolves back to the EHLO hostname. Failed forward-confirmed reverse DNS (FCrDNS) check produces immediate reputation impact and frequently 5xx rejections from strict receivers.
Per-pool configuration ensures the EHLO domain matches the stream's intent: marketing VMTAs present marketing-domain EHLO, cold VMTAs present cold-domain EHLO. The pattern is critical because if a cold pool IP presents a marketing-domain EHLO, the cold complaints accrue to the marketing domain reputation, defeating the entire separation architecture.
The setup procedure for each IP:
- Configure forward DNS: mta1.news.example.com A record pointing to 203.0.113.42
- Configure reverse DNS: 203.0.113.42 PTR record returning mta1.news.example.com (via VPS provider control panel)
- Configure smtp-source-host in PowerMTA VMTA matching these settings
- Verify with
dig +short mta1.news.example.comanddig +short -x 203.0.113.42returning matching values
The most common stream separation failure: operators set up VMTAs with smtp-source-host directives that point to cold pool IPs but present marketing-domain EHLO hostnames (or vice versa). The reputation cross-contamination defeats every other separation control. Verify each IP's FCrDNS independently with dig +short -x IP from an external DNS resolver and ensure the returned hostname matches the smtp-source-host EHLO configuration. Misconfigured FCrDNS produces silent reputation damage that takes weeks to detect through downstream symptoms.
Complaint rate ceilings per stream
Complaint rate management differs between streams because the acceptable ceilings differ substantially.
Marketing stream ceilings:
- Target operational: under 0.1%
- Yellow zone for investigation: 0.1-0.2%
- Red zone immediate action: 0.2-0.3%
- Gmail/Yahoo hard limit: 0.3% triggers throttling, 0.5% triggers blocking
Cold email stream ceilings:
- Target operational: under 0.5%
- Yellow zone for investigation: 0.5-1%
- Red zone immediate action: 1-2%
- Reality: cold email frequently runs 1-2% complaint rate which would be catastrophic for marketing but is operational reality for cold
Monitoring complaint rates per pool produces actionable signals: marketing complaint spike to 0.25% needs immediate investigation of recent campaigns; cold pool complaint rate of 1.5% might be acceptable for cold context depending on conversion economics. The same complaint rate triggers different operational responses based on stream context.
This is precisely why separation matters: combined infrastructure produces averaged complaint rates that hide the actual pattern. A combined deployment sending 90% marketing at 0.1% complaint and 10% cold at 1.5% complaint shows 0.24% combined rate which appears acceptable but contains hidden 1.5% rate that will eventually cascade into reputation events affecting all traffic.
Multi-tenant patterns for agencies and ESPs
Agencies running both streams for multiple customers face additional complexity: customer-level separation alongside stream-level separation.
The pattern: VMTA naming includes customer ID, pool composition respects both customer boundary and stream type.
# Customer A marketing pool
<virtual-mta cust-a-marketing-vmta-1>
smtp-source-host 203.0.113.42 mta1.cust-a-news.example.com
domain-key custa,cust-a-news.example.com,/etc/pmta/keys/cust_a_marketing.pem
</virtual-mta>
<virtual-mta-pool cust-a-marketing-pool>
virtual-mta cust-a-marketing-vmta-1
virtual-mta cust-a-marketing-vmta-2
</virtual-mta-pool>
# Customer A cold pool
<virtual-mta cust-a-cold-vmta-1>
smtp-source-host 198.51.100.10 mta1.cust-a-outreach.example.com
domain-key custacold,cust-a-outreach.example.com,/etc/pmta/keys/cust_a_cold.pem
</virtual-mta>
<virtual-mta-pool cust-a-cold-pool>
virtual-mta cust-a-cold-vmta-1
virtual-mta cust-a-cold-vmta-2
</virtual-mta-pool>
# Customer B marketing pool
<virtual-mta cust-b-marketing-vmta-1>
smtp-source-host 203.0.113.50 mta1.cust-b-news.example.com
domain-key custb,cust-b-news.example.com,/etc/pmta/keys/cust_b_marketing.pem
</virtual-mta>
# ... and so onMailWizz integration follows the same pattern: per-customer delivery servers in MailWizz, each pointing to PowerMTA but injecting X-Virtual-MTA referring to that customer's appropriate pool (marketing or cold based on campaign type).
The IP allocation grows linearly with customer count: 4 IPs per customer marketing pool plus 20 IPs per customer cold pool means a 10-customer agency needs 240 IPs distributed across 20 pools. This is substantial but reflects the operational reality of multi-tenant ESP economics: customer isolation prevents one customer's deliverability issues from affecting other customers' campaigns.
An agency we consulted with had been running combined infrastructure (marketing and cold for 15 customers on shared pools of 8 IPs total) and reported intermittent deliverability complaints from customers across the board. Investigation revealed the predictable pattern: one customer's cold email campaign hit 2% complaint rate, dragged combined pool complaint rate to 0.4%, Gmail throttled the entire pool, all 15 customers experienced marketing deliverability degradation simultaneously. The fix was substantial: redesign infrastructure with per-customer per-stream separation, growing from 8 IPs to approximately 180 IPs across 30 pools. Cost increase: $300/month for additional IPs. Deliverability improvement: marketing inbox placement recovered from 78% to 94% within 6 weeks, cold email per-customer reputation isolated so problem customers' issues stopped affecting good customers. Customer retention improved measurably because customers stopped blaming the agency for problems caused by other customers on shared infrastructure. The lesson: stream separation alone is insufficient for agencies; per-customer separation is also essential and the IP cost increase is negligible compared to customer retention value.
The architectural pattern of separating cold email from bulk marketing email at PowerMTA infrastructure level is non-negotiable for any operator running both streams at scale in 2026. VMTA pool design, IP allocation per stream, domain separation, authentication alignment, throttling per stream, smtp-source-host configuration, and multi-tenant patterns all combine to produce reputation isolation that prevents cross-stream contamination. Operators who build this separation upfront avoid the predictable crises that operators with combined infrastructure encounter when complaint pressure or reputation events on one stream affect all streams simultaneously. The upfront engineering investment pays back many times in reliable deliverability across diverse use cases.