How many IPs do I need for an IP pool?

Minimum 2 IPs per pool for redundancy. For high volume (500K+/day), use 4-8 IPs per pool. Each IP can handle roughly 100K-200K emails/day to Gmail before reputation issues. Transactional pools can use fewer IPs since volume is typically lower.

When should I use IP pools vs a single IP?

Use IP pools when: you send both transactional and marketing email, you have multiple clients/tenants, you send over 200K emails/day, or you need to isolate reputation between campaigns. Single IP is fine for under 100K/day of consistent email types.

How do I assign email to different IP pools?

Most ESPs let you specify the pool in the API call. SendGrid uses x-smtpapi header, Mailgun uses SMTP header injection, and self-hosted uses transport maps in Postfix or virtual queues in PowerMTA. Match the pool to the mail type: transactional mail routes to the transactional pool.

Should transactional and marketing email use different IPs?

Yes, always. Marketing email has higher complaint rates and can damage IP reputation. If that reputation bleeds to transactional IPs, password resets and order confirmations go to spam. Separate pools protect critical transactional mail.

How do I warm up a new IP pool?

Warm each IP in the pool individually or together, starting at 1K-5K emails/day and doubling every 2-3 days. Send to your most engaged recipients first. Monitor reputation via Google Postmaster Tools. Full warmup takes 4-8 weeks depending on volume targets.

IP Pools for Email: How to Set Up and Manage Multiple IPs

What Are IP Pools

An IP pool is a group of IP addresses used for sending email, treated as a single unit. Instead of sending all email from one IP, you route different email types through different pools.

Why pools matter:

Reputation isolation: Marketing email can't damage transactional IP reputation (see stream separation)
Scale: Distribute volume across multiple IPs
Redundancy: If one IP gets blocked, others keep working
Client separation: In multi-tenant systems, isolate client reputation

Pool Architecture Strategy

Basic Setup (Most Organizations)

Pool	IPs	Purpose
Transactional	2	Password resets, order confirmations, receipts
Marketing	4	Newsletters, promotions, campaigns

Agency/Multi-Tenant Setup

Pool	IPs	Purpose
Transactional	2	Shared transactional for all clients
Marketing Tier 1	4	High-reputation clients
Marketing Tier 2	4	Standard clients
Isolation	2	New or risky clients

Enterprise High-Volume Setup

Pool	IPs	Purpose
Transactional	4-8	All transactional mail
Marketing - NA	4-8	North America campaigns
Marketing - EU	4-8	European campaigns
Re-engagement	2	Win-back campaigns (risky)
Cold outreach	2	Prospecting (highest risk)

Practitioner note: I've seen agencies put all their clients on a single IP pool "for simplicity." Then one client sends to a purchased list, tanks the reputation, and suddenly all clients are hitting spam. Isolation pools cost money but save accounts.

SendGrid IP Pool Setup

Create a Pool

curl --request POST \
  --url https://api.sendgrid.com/v3/ips/pools \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{"name": "transactional"}'

Add IPs to Pool

curl --request POST \
  --url https://api.sendgrid.com/v3/ips/pools/transactional/ips \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{"ip": "192.168.1.1"}'

Send Using a Pool

Via API:

{
  "personalizations": [{"to": [{"email": "[email protected]"}]}],
  "from": {"email": "[email protected]"},
  "subject": "Test",
  "content": [{"type": "text/plain", "value": "Test message"}],
  "ip_pool_name": "transactional"
}

Via SMTP (X-SMTPAPI header):

{"ip_pool": "transactional"}

Mailgun IP Pool Setup

Mailgun uses "IP pools" or dedicated IPs assigned to domains.

Assign Domain to Dedicated IPs

curl -s --user 'api:YOUR_API_KEY' \
  https://api.mailgun.net/v3/domains/yourdomain.com \
  -F dedicated_ip='192.168.1.1'

Send with Pool Selection

Mailgun routes by domain. Create separate sending domains mapped to different IP pools:

transactional.yourdomain.com → Transactional pool
marketing.yourdomain.com → Marketing pool

Self-Hosted Postfix IP Pools

Postfix doesn't have native IP pools, but you can achieve similar results with transport maps and multi-instance Postfix.

Method 1: Transport Maps

Create /etc/postfix/transport_pool:

# Route by recipient domain (testing)
gmail.com    smtp:[192.168.1.1]
yahoo.com    smtp:[192.168.1.2]

main.cf:

transport_maps = hash:/etc/postfix/transport_pool

Method 2: Sender-Based Routing

Create /etc/postfix/sender_transport:

[email protected]    smtp-trans:
[email protected]        smtp-marketing:

master.cf:

smtp-trans    unix  -       -       n       -       -       smtp
    -o smtp_bind_address=192.168.1.1

smtp-marketing unix  -       -       n       -       -       smtp
    -o smtp_bind_address=192.168.1.2

Method 3: Multi-Instance Postfix

Run separate Postfix instances for each pool:

postmulti -e create -I postfix-transactional
postmulti -e create -I postfix-marketing

Configure each with different smtp_bind_address values.

Practitioner note: For self-hosted at scale, Postfix transport maps work but get messy. If you're managing more than 4-5 IP pools, consider PowerMTA or KumoMTA — they have proper pool management built in. See our MTA comparison for details.

PowerMTA IP Pool Configuration

PowerMTA has native virtual MTA (vmta) pools:

<virtual-mta transactional>
    smtp-source-host 192.168.1.1 yourdomain.com
    smtp-source-host 192.168.1.2 yourdomain.com
</virtual-mta>

<virtual-mta marketing>
    smtp-source-host 192.168.1.3 yourdomain.com
    smtp-source-host 192.168.1.4 yourdomain.com
</virtual-mta>

<virtual-mta-pool transactional-pool>
    virtual-mta transactional
</virtual-mta-pool>

<virtual-mta-pool marketing-pool>
    virtual-mta marketing
</virtual-mta-pool>

Inject mail with the pool specified:

XMTA transactional-pool

Warming New IP Pools

Each IP in a pool needs individual warming:

Week 1-2: Low Volume

Day 1: 1,000 emails per IP
Day 3: 2,500 emails per IP
Day 5: 5,000 emails per IP
Day 7: 10,000 emails per IP

Week 3-4: Ramp Up

Day 10: 25,000 emails per IP
Day 14: 50,000 emails per IP

Week 5+: Full Volume

Day 21: 100,000 emails per IP
Day 28: Target volume

Key points:

Send to engaged recipients during warmup
Monitor Google Postmaster Tools daily
Slow down if you see reputation dips
Don't add new IPs to a pool mid-warmup

Pool Monitoring

Track per-pool metrics:

Metric	Healthy	Warning	Critical
Bounce rate	<2%	2-5%	>5%
Complaint rate	<0.1%	0.1-0.3%	>0.3%
Gmail reputation	High	Medium	Low/Bad
Blacklist status	None	1 list	Multiple

Set up alerts per pool. A reputation drop in your marketing pool shouldn't go unnoticed while you're watching the transactional pool.

Pool Rotation and Failover

Automatic Rotation

Distribute mail across pool IPs to even out reputation impact:

# PowerMTA rotation
<virtual-mta-pool marketing>
    virtual-mta marketing-1
    virtual-mta marketing-2
    virtual-mta marketing-3
    # Traffic rotates automatically
</virtual-mta-pool>

Manual Failover

If an IP gets blacklisted:

Remove IP from pool immediately
Route traffic to remaining IPs
Request delisting
Re-add IP after delisting confirmed
Monitor closely for 48-72 hours

Don't just leave a blacklisted IP in the pool — it will drag down delivery rates and potentially get your other IPs flagged by association. See IP rotation for failover patterns.

Common Mistakes

Too few IPs per pool One IP per pool means zero redundancy. Always have at least 2.

Mixing email types in one pool Never combine marketing and transactional. One bad campaign shouldn't affect password resets.

Not warming new IPs Adding a cold IP to a warm pool dilutes reputation. Warm separately, then add.

Ignoring pool-level metrics Aggregate stats hide pool-specific problems. Monitor each pool independently.

If you need help designing an IP pool architecture for your email infrastructure or migrating to a multi-pool setup, schedule a consultation.

Sources

SendGrid Documentation: IP Pools
Mailgun Documentation: IP Management
PowerMTA Documentation: Virtual MTAs
M3AAWG: Best Practices for Managing IP Reputation

v1.0 · March 2026