Postfix Multiple IP Rotation: Transport Maps, Master.cf & Concurrency Guide

DKIM Key Assignment Per IP/Stream

When running multiple Postfix instances or streams, each stream should sign with a separate DKIM selector. This allows key rotation to be performed per-stream without affecting others, and allows you to trace complaint signals back to the specific sending stream by checking which DKIM selector signed the message. Configure OpenDKIM with a SigningTable that maps sending addresses to specific selectors.

# /etc/opendkim/SigningTable
# Map From: address patterns to specific selectors
*@transactional.yourcompany.com  transact-2025._domainkey.yourcompany.com
*@marketing.yourcompany.com      marketing-2025._domainkey.yourcompany.com
*@newsletters.yourcompany.com    news-2025._domainkey.yourcompany.com

# /etc/opendkim/KeyTable
transact-2025._domainkey.yourcompany.com  yourcompany.com:transact-2025:/etc/opendkim/keys/transact-2025.private
marketing-2025._domainkey.yourcompany.com yourcompany.com:marketing-2025:/etc/opendkim/keys/marketing-2025.private
news-2025._domainkey.yourcompany.com      yourcompany.com:news-2025:/etc/opendkim/keys/news-2025.private

# Each selector independently rotatable every 6 months.
# Complaint signals in FBL reports include the DKIM selector used,
# allowing you to trace complaints to specific sending streams.

Monitoring Multiple IPs

Operating multiple sending IPs without per-IP monitoring creates visibility gaps. A blocked or degraded IP may be silently dropping or deferring messages for days before you notice the impact on delivery reports. Set up monitoring alerts on each IP individually.

Updating SPF for Multiple IPs

Every sending IP must be listed in your domain’s SPF record. When adding IPs to Postfix, update SPF before the first send from the new IP — SPF failures on new IPs delay deliverability establishment and generate authentication errors that complicate reputation building.

# DNS TXT record for yourcompany.com
v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 ip4:203.0.113.12 ~all

# If you have a /24 subnet, use CIDR notation:
v=spf1 ip4:203.0.113.0/24 ~all

# After updating SPF, test with:
# dig TXT yourcompany.com +short
# Verify the new IP is listed before sending from it

# SPF lookup limit check:
# Use mxtoolbox.com/spf to count lookups — must stay under 10
# ip4: mechanisms count as 0 lookups each (no DNS resolution needed)

IP Affinity — Binding Specific Senders to Specific IPs

In multi-tenant or multi-product environments, you may need to bind specific senders (From: addresses) to specific IPs. This ensures that a high-complaint marketing send does not use the same IP as low-volume transactional messages, and that each IP’s reputation accurately reflects the traffic it handles. Postfix supports this through sender_dependent_default_transport_maps combined with per-transport IP binding.

# /etc/postfix/main.cf
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport
smtp_bind_address = 203.0.113.10   # default IP for unmatched senders

# /etc/postfix/sender_transport
# Transactional senders → IP 203.0.113.10 (highest reputation)
noreply@company.com       transact-smtp
security@company.com      transact-smtp
billing@company.com       transact-smtp

# Marketing senders → IP 203.0.113.11
newsletter@company.com    marketing-smtp
campaigns@company.com     marketing-smtp

# Cold outreach → IP 203.0.113.12 (lowest reputation risk)
outbound@company.com      outbound-smtp

# /etc/postfix/master.cf (append these transport entries)
transact-smtp   unix - - n - - smtp
    -o smtp_bind_address=203.0.113.10
    -o smtp_destination_concurrency_limit=15

marketing-smtp  unix - - n - - smtp
    -o smtp_bind_address=203.0.113.11
    -o smtp_destination_concurrency_limit=8
    -o smtp_destination_rate_delay=0.1s

outbound-smtp   unix - - n - - smtp
    -o smtp_bind_address=203.0.113.12
    -o smtp_destination_concurrency_limit=5
    -o smtp_destination_rate_delay=0.3s

# Apply changes:
# sudo postmap /etc/postfix/sender_transport
# sudo postfix reload

Advanced IP Rotation: Reputation-Weighted Distribution

Basic round-robin IP rotation distributes load equally across all IPs regardless of their current reputation state. Reputation-weighted rotation — a more sophisticated approach — directs proportionally more traffic through IPs at higher reputation tiers and less through IPs that are warming or recovering. This approach maximises overall pool throughput by ensuring the highest-capacity IPs (those at full reputation) carry the highest volume, while protecting warming IPs from volume spikes that would stall their reputation development.

In Postfix, reputation-weighted rotation is implemented by configuring multiple sender_dependent_relayhost_maps entries that distribute sending cohorts across IPs based on list segment quality. High-engagement segments (last opened within 30 days) are routed through the primary high-reputation IPs. Low-engagement segments are routed through secondary IPs. New list segments from recent acquisition are routed through designated warmup IPs. The routing rules are updated as warmup progresses and IPs graduate from the warmup pool to the production pool.

The configuration requires: (1) Multiple IP bindings in Postfix using smtp_bind_address per transport; (2) Multiple transport definitions in master.cf, one per IP; (3) Sender-based or header-based routing rules in transport_maps that assign each sending identity to the correct transport/IP. For high-volume programmes, this configuration complexity is worth the throughput and reputation management benefits. For lower-volume programmes, simple round-robin with a per-IP sending limit is sufficient and easier to maintain.

Monitoring Per-IP Delivery in Postfix

Postfix’s mail log provides per-IP delivery data that, with the right log parsing, reveals per-IP throughput and deferral rates equivalent to what PowerMTA provides natively. The key log fields: the relay field (showing the destination server and port), the status field (sent, deferred, bounced), and the delay field (showing queue time vs delivery time). A log parsing script that groups these fields by source IP address produces per-IP delivery metrics.

The practical monitoring setup: a daily log parsing script (Python or bash with awk/grep) that produces a per-IP report showing messages sent, delivery rate, average delay, and top deferral reasons for the previous 24 hours. This report, reviewed each morning before any campaign injection, reveals whether any IP in the pool is generating unusual deferral rates that warrant investigation. Combined with SNDS weekly checks for each IP, this two-layer monitoring provides complete per-IP visibility for Postfix-based sending infrastructure at moderate volume. For high-volume programmes above 1 million messages per month, PowerMTA’s native per-event accounting log provides the same data with significantly less custom tooling overhead.

Multi-IP Postfix configuration is the foundation for scalable outbound sending on open-source infrastructure. Configured correctly with reputation-weighted routing and daily log monitoring, it provides the core operational capability that high-volume open-source sending requires — at a fraction of the licensing cost of commercial MTAs, with the operational transparency that Postfix’s detailed mail log provides.