Postfix Configuration for Email Marketing: Production Setup Guide

Why Postfix for Email Marketing

Postfix handles high-volume email well when configured correctly. It's free, battle-tested, and runs on virtually any Linux server. The challenge isn't whether Postfix can handle marketing volume—it can. The challenge is configuring it to respect ISP rate limits and maintain deliverability.

Out of the box, Postfix will try to deliver as fast as possible. For marketing email, that's a problem. Gmail and Microsoft will defer or block you. This guide covers the specific configurations needed for marketing use. For a complete self-hosted setup, see our Mailcow guide which packages Postfix with a web UI. You'll also need proper DNS configuration and IP warming.

Core Configuration: main.cf

Start with these essential settings in /etc/postfix/main.cf:

# Basic identification
myhostname = mail.yourdomain.com
mydomain = yourdomain.com
myorigin = $mydomain

# Queue management for marketing volume
maximal_queue_lifetime = 5d
bounce_queue_lifetime = 1d
minimal_backoff_time = 300s
maximal_backoff_time = 4000s
queue_run_delay = 300s

# Process limits
default_process_limit = 100
qmgr_message_active_limit = 20000
qmgr_message_recipient_limit = 20000

# Connection settings
smtp_connect_timeout = 30s
smtp_helo_timeout = 120s
smtp_mail_timeout = 180s
smtp_rcpt_timeout = 180s
smtp_data_done_timeout = 600s

# TLS (required for modern deliverability)
smtp_tls_security_level = may
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_loglevel = 1

# Rate limiting (critical for marketing)
smtp_destination_concurrency_limit = 10
smtp_destination_rate_delay = 1s
smtp_extra_recipient_limit = 10

Rate Limiting by Destination

Different mailbox providers tolerate different sending rates. Create per-destination overrides using transport maps.

Create /etc/postfix/transport:

gmail.com       slow:
googlemail.com  slow:
outlook.com     slow:
hotmail.com     slow:
yahoo.com       slow:
aol.com         slow:

Create /etc/postfix/master.cf entries:

slow      unix  -       -       n       -       5       smtp
    -o smtp_destination_concurrency_limit=5
    -o smtp_destination_rate_delay=2s
    -o smtp_extra_recipient_limit=5

Update main.cf:

transport_maps = hash:/etc/postfix/transport

Apply:

postmap /etc/postfix/transport
systemctl reload postfix

Practitioner note: Gmail is the strictest. I've seen servers with perfect reputation get deferred at 20 concurrent connections. Start at 5 connections with 2-second delays for Gmail domains. You can increase later once you've established reputation.

Queue Structure for Marketing

Separate your queues to prevent marketing backlogs from affecting transactional email:

# In main.cf
hash_queue_depth = 2
hash_queue_names = deferred, active, incoming, hold

For true separation, run two Postfix instances—one for transactional, one for marketing:

# Create alternate instance
postmulti -e create -I postfix-marketing

# Configure the marketing instance with more aggressive rate limiting
# Edit /etc/postfix-marketing/main.cf separately

Bounce Handling

Marketing email generates bounces. Handle them properly:

# main.cf bounce settings
bounce_size_limit = 50000
bounce_queue_lifetime = 1d
delay_warning_time = 0

# Enable bounce notification processing
notify_classes = bounce, 2bounce, resource, software
bounce_notice_recipient = [email protected]
2bounce_notice_recipient = [email protected]

Process bounces programmatically. Parse the bounce emails to:

• Identify hard bounces (remove from list immediately)
• Track soft bounces (remove after 3-5 failures)
• Monitor bounce rate (should stay under 2%)

Practitioner note: Don't rely on Postfix bounce notifications alone. Implement VERP (Variable Envelope Return Path) so each recipient gets a unique return-path. This lets you match bounces to specific addresses without parsing bounce messages.

VERP Configuration

VERP makes bounce tracking reliable:

# main.cf
smtpd_authorized_verp_clients = 127.0.0.1

# When sending, use the VERP flag
# From application: MAIL FROM:<[email protected]> VERP

Your application constructs the return path with the recipient encoded. When it bounces, you know exactly which address failed.

Authentication Headers

Add proper authentication headers so DKIM and SPF work correctly:

# main.cf - header cleanup
header_checks = regexp:/etc/postfix/header_checks

# Create /etc/postfix/header_checks
/^Received:.*127.0.0.1/ IGNORE

Integrate with OpenDKIM for DKIM signing:

# main.cf DKIM integration
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Monitoring Queue Health

Marketing email means constant queue activity. Monitor it:

# Check queue depth
mailq | tail -n 1

# Detailed queue summary
qshape deferred

# Force queue flush (use sparingly)
postqueue -f

# Remove stuck messages older than 7 days
find /var/spool/postfix/deferred -type f -mtime +7 -delete

Set up automated monitoring:

#!/bin/bash
# /usr/local/bin/postfix-monitor.sh
QUEUE_SIZE=$(mailq | grep -c "^[A-F0-9]")
if [ $QUEUE_SIZE -gt 10000 ]; then
    echo "Postfix queue size: $QUEUE_SIZE" | mail -s "Queue Alert" [email protected]
fi

Performance Tuning

For volumes over 100K emails/day:

# Increase file descriptor limits
# /etc/security/limits.conf
postfix soft nofile 65536
postfix hard nofile 65536

# main.cf optimizations
in_flow_delay = 0
smtp_connection_cache_on_demand = yes
smtp_connection_cache_time_limit = 2s
smtp_connection_reuse_time_limit = 300s

Practitioner note: Connection caching helps throughput but can mask problems. If Gmail starts deferring you, the cached connections keep hammering them. I prefer shorter cache times (2-5 seconds) for marketing traffic so connections close and reopen with fresh state.

Log Analysis

Parse logs for deliverability metrics:

# Install pflogsumm
apt install pflogsumm

# Generate daily report
cat /var/log/mail.log | pflogsumm

# Key metrics to watch:
# - Delivered vs bounced percentage
# - Deferred message count
# - Per-domain rejection rates

Create custom log parsing for real-time monitoring of:

• Delivery rate by destination domain
• Deferral reasons (rate limiting, reputation, content)
• Bounce types (hard vs soft)

When Postfix Isn't Enough

Postfix works well up to about 500K emails/day with proper tuning. Beyond that, consider:

• PowerMTA: Better queue management, real-time analytics, per-campaign tracking
• KumoMTA: Modern Rust-based MTA with API-first design
• Halon: Scriptable MTA with Lua customization

If you need help configuring Postfix for high-volume marketing or want to evaluate whether it's time to upgrade to a commercial MTA, schedule a consultation.

Sources

• Postfix Documentation: Configuration Parameters
• Postfix Documentation: Queue Management
• Postfix Documentation: Rate Limiting
• RFC 5321: Simple Mail Transfer Protocol

---

v1.0 · March 2026