Contents
Why separation matters
Running marketing and transactional email on the same IP pool is one of the most common and costly mistakes in email infrastructure. The reasoning is direct: marketing campaigns generate complaint spikes, and when a promotional campaign triggers spam complaints across a shared IP, those complaints suppress delivery of transactional email on the same infrastructure. A password reset or order confirmation fails to arrive because the last marketing blast irritated too many subscribers.
The two streams have fundamentally different deliverability profiles. Transactional email is expected, urgent, critical to recipients, and naturally produces high engagement and low complaints. Marketing email is less urgent, produces lower engagement, and carries higher complaint rates even from legitimate opted-in subscribers because promotional mail is simply not anticipated the way a password reset is. Mixing them means the lower-performing marketing stream drags down the deliverability of the critical transactional stream.
This guide exists because the separation is treated as optional by operators who have not yet experienced the failure mode it prevents. The leading email service providers (SendGrid, Amazon SES, Google Workspace) all recommend the separation; the practitioner consensus treats it as a non-negotiable best practice. The structure: the two stream profiles, VMTA pool design at PowerMTA level, IP allocation, subdomain strategy, the specific donotreply subdomain mistake to avoid, authentication per stream, throttling differences, application routing patterns to send each stream to the right pool, monitoring metrics that differ by stream.
The two stream profiles
| Attribute | Transactional | Marketing |
|---|---|---|
| Recipient expectation | Expected, awaited | Not always anticipated |
| Urgency | Immediate (password reset) | Low (newsletter can wait) |
| Engagement (open rate) | High, 50-80% | Moderate, 15-30% |
| Complaint rate typical | Very low, near zero | 0.01-0.15% |
| Delivery rate target | 99%+ | 92%+ inbox placement |
| Speed requirement | Seconds to inbox | Minutes acceptable |
| Volume pattern | Event-driven, steady | Bursty campaign sends |
| Content | Functional, plain | Designed templates, images, CTAs |
| Examples | Password reset, order confirmation, shipping notice | Newsletter, promotion, announcement |
| Metrics that matter | Delivery rate, speed, errors | Open rate, click rate, conversions |
The profile difference is the entire justification for separation. Transactional email's high engagement and low complaints make it a reputation asset; marketing email's lower engagement and higher complaints make it a reputation risk. Keeping them separate means the asset is not dragged down by the risk.
VMTA pool design
The PowerMTA architecture for stream separation: dedicated virtual-mta-pool definitions for transactional and marketing, with VMTAs bound to dedicated source IPs per stream.
# Transactional pool - 1-2 IPs, critical reliability
<virtual-mta transactional-vmta-1>
smtp-source-host 203.0.113.50 mail.example.com
domain-key tx,mail.example.com,/etc/pmta/keys/transactional.pem
</virtual-mta>
<virtual-mta transactional-vmta-2>
smtp-source-host 203.0.113.51 mail2.example.com
domain-key tx,mail.example.com,/etc/pmta/keys/transactional.pem
</virtual-mta>
<virtual-mta-pool transactional-pool>
virtual-mta transactional-vmta-1
virtual-mta transactional-vmta-2
</virtual-mta-pool>
# Marketing pool - 4 IPs, tolerates reputation fluctuation
<virtual-mta marketing-vmta-1>
smtp-source-host 203.0.113.60 mta1.news.example.com
domain-key mkt,news.example.com,/etc/pmta/keys/marketing.pem
</virtual-mta>
<virtual-mta marketing-vmta-2>
smtp-source-host 203.0.113.61 mta2.news.example.com
domain-key mkt,news.example.com,/etc/pmta/keys/marketing.pem
</virtual-mta>
<virtual-mta marketing-vmta-3>
smtp-source-host 203.0.113.62 mta3.news.example.com
domain-key mkt,news.example.com,/etc/pmta/keys/marketing.pem
</virtual-mta>
<virtual-mta marketing-vmta-4>
smtp-source-host 203.0.113.63 mta4.news.example.com
domain-key mkt,news.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>The substantive points: transactional VMTAs use the transactional subdomain (mail.example.com) and transactional DKIM key; marketing VMTAs use the marketing subdomain (news.example.com) and marketing DKIM key; the pools are completely separate so reputation cannot cross-contaminate.
Applications inject X-Virtual-MTA headers pointing to the appropriate pool: transactional API calls inject X-Virtual-MTA: transactional-pool, marketing campaigns inject X-Virtual-MTA: marketing-pool. PowerMTA routes accordingly.
IP allocation per stream
IP allocation differs between streams because the volume profiles differ.
Transactional IPs. Transactional volume is typically lower than marketing volume for most businesses (one password reset per user occasionally versus one newsletter to the entire list weekly). Transactional email also benefits from concentrated reputation: fewer IPs with consistent high-engagement sending build stronger reputation than many IPs each lightly used. Typical allocation: 1-2 IPs for transactional even at substantial scale.
| Transactional monthly volume | IPs recommended |
|---|---|
| Under 500K | 1 |
| 500K-2M | 1-2 |
| 2M-10M | 2-3 |
| 10M+ | 3-5 |
Marketing IPs. Marketing volume is typically higher and bursty (campaign sends). Marketing IP allocation follows the standard 1 IP per 100K-500K monthly sends pattern.
| Marketing monthly volume | IPs recommended |
|---|---|
| Under 100K | 1 |
| 100K-500K | 1-2 |
| 500K-2M | 2-4 |
| 2M-10M | 4-8 |
| 10M+ | 8-20 |
The substantive point: transactional gets fewer IPs because concentrated high-engagement sending builds the strongest reputation, which is exactly what the critical transactional stream needs. Marketing gets more IPs to distribute bursty campaign load.
Subdomain strategy
Subdomain separation pairs with IP separation for complete reputation isolation. The standard structure:
| Stream | Subdomain example | Purpose |
|---|---|---|
| Transactional | mail.example.com or notify.example.com | Password resets, confirmations, notifications |
| Marketing | news.example.com or marketing.example.com | Newsletters, promotions, campaigns |
| Primary domain | example.com | Corporate email, parent reputation anchor |
Both subdomains inherit authority from the primary brand domain while building independent reputation. The subdomain approach is best suited to high-volume sending; if you are not sending substantial volume, starting with a single domain is reasonable and separation can be introduced as volume grows.
Each subdomain needs complete independent DNS setup: A records for the sending hosts, SPF authorizing the pool IPs, DKIM keys, DMARC policy. The subdomain isolation means a reputation event on news.example.com (marketing) does not affect mail.example.com (transactional) because receiving MTAs evaluate domain reputation at the subdomain granularity.
The donotreply subdomain mistake
One specific subdomain mistake deserves explicit warning: do not use donotreply or noreply style subdomains or addresses for the transactional stream.
The donotreply pattern (donotreply@example.com, noreply.example.com) is common but counterproductive. It discourages recipients from replying, and replies are one of the strongest positive engagement signals receiving MTAs use to evaluate sender reputation. A recipient replying to an email tells Gmail, Outlook, and Yahoo that this is a real conversation with a real human, which is exactly the signal that improves inbox placement.
Transactional email frequently uses donotreply addresses because the sending system is automated and operators assume nobody should reply to a password reset. But this throws away engagement signal. The better pattern: use a transactional address that recipients can reply to, with a monitored inbox handling the replies. Customers do reply to order confirmations and shipping notices with questions, and capturing those replies both improves reputation and improves customer service.
If your transactional email sends from donotreply@example.com, you are actively discouraging the single strongest positive reputation signal available. Replies tell receiving MTAs that recipients value your mail enough to engage. Switch transactional sending to a monitored address (support@example.com, hello@example.com, or a stream-specific address) that recipients can reply to. Route the inbound replies to a support queue. The reputation improvement plus the customer service benefit substantially outweighs the minor overhead of monitoring an inbox.
Authentication per stream
Each subdomain requires complete independent authentication.
Transactional subdomain (mail.example.com):
# SPF authorizing transactional pool IPs
mail.example.com TXT "v=spf1 ip4:203.0.113.50 ip4:203.0.113.51 -all"
# DKIM TXT record at tx._domainkey.mail.example.com
# DMARC at _dmarc.mail.example.com - strict policy for critical stream
_dmarc.mail.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com;"Marketing subdomain (news.example.com):
# SPF authorizing marketing pool IPs
news.example.com TXT "v=spf1 ip4:203.0.113.60 ip4:203.0.113.61 ip4:203.0.113.62 ip4:203.0.113.63 -all"
# DKIM TXT record at mkt._domainkey.news.example.com
# DMARC at _dmarc.news.example.com
_dmarc.news.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com;"The substantive points: each subdomain's SPF authorizes only its own pool IPs; each subdomain signs with its own DKIM key; the transactional subdomain can carry a stricter DMARC policy (p=reject) immediately because transactional sending is fully controlled and alignment is reliable, while the marketing subdomain may start at p=quarantine and progress to p=reject as alignment proves stable.
The DKIM key separation matters for isolation: marketing email cannot sign with the transactional key and transactional email cannot sign with the marketing key, so a key compromise or reputation event affecting one stream's DKIM does not affect the other.
Throttling differences
Throttling per stream reflects the different volume profiles and urgency requirements.
Transactional throttling (per-VMTA in PowerMTA):
domain gmail.com {
max-msg-rate 2000/h # Adequate for event-driven transactional
max-conn-rate 15/m
max-smtp-out 10
retry-sequence 2m,5m,10m,30m,1h # Aggressive early retry, speed matters
retry-max-time 12h # Stale transactional has no value
backoff-retry 30m
backoff-after 10 errors
}Transactional throttling uses aggressive early retries because speed matters (a password reset needs to arrive in seconds, and if the first attempt fails the retry should be quick). The retry-max-time is short (12h) because a transactional message that has not delivered within 12 hours has lost its value.
Marketing throttling (per-VMTA in PowerMTA):
domain gmail.com {
max-msg-rate 3000/h # Higher sustained for bulk campaigns
max-conn-rate 20/m
max-smtp-out 15
retry-sequence 5m,10m,15m,30m,1h,4h # Standard marketing retry
retry-max-time 2d # Marketing tolerates longer retry window
backoff-retry 30m
backoff-after 10 errors
}Marketing throttling uses standard retry sequences and a longer retry-max-time (2d) because marketing messages retain value longer than transactional and the urgency is lower.
PowerMTA processes throttling per VMTA, so the transactional pool and marketing pool throttle independently. A marketing throttling event does not affect transactional delivery pace.
Application routing patterns
Applications need to route each message to the correct pool. The patterns:
MailWizz multi-delivery-server pattern. Create two MailWizz delivery servers: "PowerMTA Transactional" injecting X-Virtual-MTA: transactional-pool, "PowerMTA Marketing" injecting X-Virtual-MTA: marketing-pool. MailWizz uses the transactional delivery server for its transactional email features and the marketing delivery server for campaigns. The From addresses configured per delivery server use the appropriate subdomain.
Application API pattern. When a custom application sends through PowerMTA, the application code determines stream type and injects the appropriate X-Virtual-MTA header. Password reset code injects transactional-pool; the marketing system injects marketing-pool. The application also sets the From address to the appropriate subdomain.
# Pseudocode for application routing
def send_email(message, stream_type):
if stream_type == 'transactional':
message.headers['X-Virtual-MTA'] = 'transactional-pool'
message.from_address = 'noreply-but-monitored@mail.example.com'
elif stream_type == 'marketing':
message.headers['X-Virtual-MTA'] = 'marketing-pool'
message.from_address = 'newsletter@news.example.com'
smtp_send(message, 'powermta-host', 25)Separate application instances pattern. Some operators run entirely separate application stacks for transactional and marketing: a transactional email service (custom or commercial transactional API) and a marketing platform (MailWizz, Mautic). Each connects to PowerMTA with its own delivery configuration injecting the appropriate VMTA pool. This pattern provides the cleanest separation but requires running two application stacks.
Whichever pattern, the substantive requirement is that the X-Virtual-MTA header correctly identifies the stream and the From address uses the correct subdomain. A transactional message that accidentally injects marketing-pool routes through marketing IPs and contaminates the separation; correct routing is essential.
Monitoring metrics per stream
The metrics that matter differ between streams, and monitoring should reflect this.
Transactional metrics:
- Delivery rate: target 99%+, alert if drops below 98%
- Speed to inbox: target seconds, alert if median exceeds 2 minutes
- Bounce rate: target near zero, alert on any increase
- Error rate: SMTP errors during handoff, alert on any pattern
- Queue depth on transactional pool: should be near zero (transactional drains fast), alert on accumulation
Marketing metrics:
- Inbox placement: target 92%+, monitor via seed testing
- Complaint rate: target under 0.1%, alert at 0.2%, critical at 0.3% (Gmail/Yahoo threshold)
- Open rate: campaign-level engagement metric
- Click rate: campaign-level engagement metric
- Bounce rate: list quality indicator
- Queue depth on marketing pool: tolerates depth during campaign bursts
The monitoring separation matters because the same signal means different things per stream. Queue depth of 2000 on the marketing pool during a campaign send is normal; queue depth of 2000 on the transactional pool is an incident because transactional should drain near-instantly. Complaint rate of 0.15% is acceptable for marketing but would be alarming if it appeared on transactional.
Build separate Grafana dashboards or dashboard sections per stream so operators see transactional health and marketing health independently. Combined dashboards average the metrics and hide the stream-specific signals that matter.
An e-commerce operator we worked with ran transactional and marketing on shared infrastructure (single domain, single IP pool of 4 IPs). It worked fine until Black Friday, when a large promotional campaign generated a complaint spike that pushed the shared IP pool's complaint rate above Gmail's threshold. Gmail throttled the entire pool. The visible symptom that triggered the support escalation was not the marketing campaign underperforming, it was that password reset emails started landing in spam folders. Customers could not reset passwords during the highest-traffic shopping day of the year, generating a flood of support tickets and lost sales. The fix was the separation this guide describes: dedicate IPs and subdomains for transactional, separate from marketing. After the redesign, the next campaign-driven complaint spike affected only the marketing stream (where it is tolerable) and transactional delivery stayed at 99.4% throughout. The lesson: the cost of mixed infrastructure is invisible until the exact wrong moment, and the wrong moment is always a high-traffic period when the marketing volume spikes. Separate before the incident, not after.
The separation of transactional from marketing email at PowerMTA infrastructure level protects the critical transactional stream from the reputation fluctuations inherent in marketing sends. VMTA pool design, IP allocation favoring concentrated transactional reputation, subdomain strategy, the donotreply mistake to avoid, authentication per stream, throttling tuned per stream's urgency profile, application routing, and stream-specific monitoring together produce an architecture where a marketing complaint spike cannot suppress password reset delivery. The leading email service providers all recommend this separation and the practitioner consensus treats it as non-negotiable. Operators who build it before experiencing the failure mode avoid the expensive lesson; operators who learn it from a Black Friday incident wish they had built it sooner.