PowerMTA DKIM Key Rotation Without Delivery Interruption

Why DKIM Key Rotation Matters

DKIM keys should be rotated periodically — annually at minimum, quarterly for high-security environments. Private key exposure (from server compromise, personnel changes, or backup mishandling) allows third parties to forge authenticated messages from your domain. Rotation also forces key hygiene: identifying all systems that sign with DKIM and ensuring they are all updated consistently.

PowerMTA supports a zero-downtime key rotation process because SMTP allows messages signed with either the old or new key to be valid during the transition window. The rotation procedure runs old and new selectors simultaneously, eliminates the old key only after all in-flight signed messages have been delivered or expired.

Zero-Downtime Rotation Procedure

# STEP 1: Generate new key pair with new selector name
# Convention: use year-quarter (e.g., s2-2026q1) or sequential (s1, s2, s3)
NEWSELECTOR="s2"

openssl genrsa -out /etc/pmta/dkim/yourdomain-$NEWSELECTOR.private 2048
chmod 640 /etc/pmta/dkim/yourdomain-$NEWSELECTOR.private
chown root:pmta /etc/pmta/dkim/yourdomain-$NEWSELECTOR.private

# Extract public key for DNS publication
openssl rsa -in /etc/pmta/dkim/yourdomain-$NEWSELECTOR.private -pubout 2>/dev/null | \
  grep -v "^-" | tr -d '\n'
# Copy the output → use as DNS TXT record value

# STEP 2: Publish new public key in DNS (but do NOT update PowerMTA yet)
# $NEWSELECTOR._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=[NEW_PUBLIC_KEY]"
# Wait for DNS propagation: 24-48 hours

# STEP 3: Verify DNS is live
dig TXT $NEWSELECTOR._domainkey.yourdomain.com
# Should return the new public key

# STEP 4: Update PowerMTA to sign with NEW selector
# Edit /etc/pmta/config or virtual-mta blocks:
# OLD:
#   dkim-sign domain="yourdomain.com" key-file="/etc/pmta/dkim/yourdomain.private" selector="s1"
# NEW:
#   dkim-sign domain="yourdomain.com" key-file="/etc/pmta/dkim/yourdomain-s2.private" selector="s2"

pmta reload
# Verify signing is working with new selector:
pmta show status | grep dkim

# STEP 5: Send test message and verify Authentication-Results header shows s2
# Authentication-Results: mx.google.com;
#   dkim=pass header.i=@yourdomain.com header.s=s2

# STEP 6: Retain old s1 DNS record for 7 days
# In-flight messages signed with s1 need the old key for verification
# After 7 days: remove s1._domainkey.yourdomain.com DNS record
# After 30 days: delete old private key file
# rm /etc/pmta/dkim/yourdomain.private  # (old s1 key)

Multi-Domain Key Rotation

In environments with multiple sending domains, coordinate key rotation across all domains. Create a rotation calendar — stagger rotations by two weeks between domains so you are not simultaneously rotating keys for all domains and managing the DNS propagation overlap for each.

# Rotation calendar (quarterly):
# Jan 1:  yourdomain.com        s1 → s2
# Jan 15: newsletter.yourdomain.com  n1 → n2
# Feb 1:  brand-a.com           a1 → a2
# Feb 15: brand-b.com           b1 → b2

# Verify all selectors post-rotation:
for DOMAIN in yourdomain.com newsletter.yourdomain.com brand-a.com; do
    echo "=== $DOMAIN ==="
    SELECTOR=$(grep -A2 "dkim-sign domain=\"$DOMAIN\"" /etc/pmta/config | grep selector | awk -F\" '{print $2}')
    dig TXT $SELECTOR._domainkey.$DOMAIN | grep "v=DKIM1"
    echo "Selector $SELECTOR: $?"
done

Key Rotation Scheduling and Automation

DKIM key rotation should be on a defined cadence: annually at minimum for established environments, quarterly for security-conscious operations. Automate where possible: generate the new key pair, publish DNS, update PowerMTA config, and verify signing in a scripted sequence. The 7-day window between DNS publication and old record retirement ensures all in-flight signed messages remain verifiable during the transition.

Accounting Log Analysis for This Configuration

Monitor this configuration area through the PowerMTA accounting log's dsnDiag field. Filter accounting records for the specific ISP domains affected by this configuration and group dsnDiag responses by first 60 characters to identify the dominant error patterns. A deferral rate above 5% at any single ISP warrants investigation; above 15% requires immediate volume reduction and configuration review.

The dlvSourceIp field in the accounting log enables per-IP analysis within this configuration context. Comparing per-IP deferral rates identifies whether a configuration issue affects all IPs in a pool uniformly (configuration problem) or just specific IPs (reputation or IP-specific problem). This distinction determines the correct remediation path.

Calibrating to Your Current Environment

The parameter values documented in this reference are appropriate for established, warmed IPs with HIGH reputation at the target ISP. New or warming IPs, and IPs with MEDIUM or LOW reputation, require more conservative values. Move up incrementally as reputation signals confirm the infrastructure can sustain additional throughput. Review ISP-specific configuration monthly — Postmaster Tools reputation tier changes and SNDS status changes are the primary triggers.

Production Deployment Summary

Implementing this PowerMTA configuration correctly in production requires testing the specific parameter values against your actual IP reputation history, ISP distribution, and sending volume. The values documented here represent proven starting points, not fixed constants — your optimal configuration may differ based on your infrastructure's operational history.

After applying any configuration change, monitor the accounting log for the first 2-4 hours to verify the change produced the expected effect on deferral rates. A configuration change that was expected to reduce deferrals but shows no change (or increased deferrals) indicates either: the change addressed the wrong variable, or there is a confounding factor that needs investigation before continuing.

The Cloud Server for Email infrastructure team manages PowerMTA environments daily, applying the configuration principles documented in this reference series across clients with varied volume levels, ISP distributions, and reputation histories. Contact us at infrastructure@cloudserverforemail.com for a technical assessment of your specific PowerMTA configuration requirements.