Postfix mail flow: injection rate outpacing delivery rate

The queue is growing, delivery latency is climbing, and the gap between what Postfix accepts and what it delivers is sustained. This divergence surfaces before queue-depth alerts fire.

Injection rate and delivery rate should track within about 10% over any 5-minute window. When they diverge consistently, the outbound path is constrained. The constraint might be a single slow destination monopolizing active queue slots, a DNS resolver failure silently deferring all deliveries, a content filter that has stopped responding, or destination-side rate limiting. Each cause has a distinct signature in the logs and queue directories.

For the broader Postfix architecture and queue model, see How Postfix actually works in production.

What this means

When injection rate exceeds delivery rate over a sustained window, the difference accumulates in the queue. Mail that cannot be delivered immediately enters the deferred queue and is retried with exponential backoff (up to maximal_backoff_time, default 4000 seconds, roughly 1.1 hours). If new mail keeps arriving faster than old mail can be retried and delivered, the queue grows until disk space or inodes are exhausted.

Velocity is the leading indicator. Queue depth is lagging. By the time the deferred queue is large enough to trigger a count-based alert, the underlying problem has been compounding for minutes or hours.

Two severity thresholds matter:

• Injection greater than 0 with delivery equal to 0 for more than 10 minutes: Complete delivery failure. Page immediately.
• Deferred ratio above 20% of injection: Significant delivery degradation. The system is delivering some mail, but a substantial fraction is failing and will enter the deferred retry cycle.

A healthy system maintains a deferred rate below 5% of total injection and an injection-to-delivery ratio near 1:1 over 5-minute windows.

Counting nuances that distort the ratio

Before trusting raw counts, understand four asymmetries in Postfix logging:

• Multi-recipient mail counts once inbound but many times outbound. A message with 50 recipients generates one client= log line (injection) but up to 50 status=sent lines (delivery). A healthy list server may show delivery rate naturally exceeding injection rate.
• Bounces inflate delivery counts. Bounce messages are sent from the null sender (<>) and their delivery produces status=sent lines. Double-bounces are typically discarded. Both inflate apparent delivery count.
• Backup MX designs run injection far above delivery by design. A backup MX accepts mail it cannot deliver until the primary recovers. Do not alert on this pattern for backup MX instances.
• Log rotation causes apparent velocity drops. If your monitoring reads /var/log/mail.log directly and the file rotates mid-window, rates drop to zero temporarily. Use journald or a log shipper that handles rotation.

The diagnostic flow below assumes you have accounted for these factors.

flowchart TD
    A[Injection > Delivery sustained] --> B{Delivery near zero?}
    B -->|Yes, over 10 min| C[Complete failure: page]
    B -->|No, degraded| D{All domains deferred?}
    C --> E{DNS resolves?}
    E -->|No| F[DNS failure]
    E -->|Yes| G{Filter responsive?}
    G -->|No| H[Filter backpressure]
    D -->|Yes| F
    D -->|Specific only| K{Active queue at limit?}
    K -->|Yes| L[Queue gridlock]
    K -->|No| M[Destination throttling]

Common causes

Quick checks

All commands are read-only and safe to run during an incident. The log file path varies by distribution: Debian and Ubuntu typically use /var/log/mail.log, while RHEL-family systems use /var/log/maillog. Adjust accordingly.

The timestamp-based grep approach below matches a single minute, not a rolling 5-minute window. For accurate rolling windows, use journalctl --since, a log analysis tool, or a monitoring system that parses logs continuously.

# Messages accepted (injection) in the specified minute
grep "$(date -d '5 minutes ago' '+%b %e %H:%M')" /var/log/mail.log | grep -c 'client='

# Messages delivered successfully
grep "$(date -d '5 minutes ago' '+%b %e %H:%M')" /var/log/mail.log | grep -c 'status=sent'

# Deferred messages
grep "$(date -d '5 minutes ago' '+%b %e %H:%M')" /var/log/mail.log | grep -c 'status=deferred'

# Bounced messages
grep "$(date -d '5 minutes ago' '+%b %e %H:%M')" /var/log/mail.log | grep -c 'status=bounced'

# Active queue size (use find: Postfix may hash queue files into subdirectories)
find /var/spool/postfix/active -type f | wc -l

# Deferred queue file count
find /var/spool/postfix/deferred -type f | wc -l

# Current active queue limit
postconf -h qmgr_message_active_limit

# Top deferred destination domains
grep 'status=deferred' /var/log/mail.log | awk -F'to=<|>,' '{print $2}' | cut -d@ -f2 | sort | uniq -c | sort -rn | head

# Test DNS resolution directly from the MTA host
dig @$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf) gmail.com MX

How to diagnose it

1. Confirm the divergence. Count client= lines (injection) and status=sent lines (delivery) over the same time window. If delivery is zero and injection is nonzero for more than 10 minutes, treat it as a complete delivery failure and page.

2. Check whether all destinations are affected or just specific ones. Run the top-deferred-domains command. If one or two domains dominate the deferred list, the problem is likely destination-specific: rate limiting, reputation, or that destination being down. If many domains are deferred equally, suspect DNS or a system-wide issue.

3. Inspect the deferred reason codes. Look at the DSN codes and textual reasons in deferred log lines:

   # Show recent deferral reasons
   grep 'status=deferred' /var/log/mail.log | tail -20
   

   “Host not found” or “Name service error” points to DNS. “Connection timed out” points to network or firewall. “4.7.1” or similar rate-limit codes point to destination throttling.

4. Check active queue saturation. Compare active queue file count to qmgr_message_active_limit (default 20,000). If the active queue is near the limit, the queue manager cannot schedule new deliveries regardless of destination health. This is the queue gridlock state: one slow destination occupies slots that starve all others.

5. Test DNS from the MTA host. If all destinations are affected, run the dig command from the quick checks. If DNS queries fail or time out, the resolver is the bottleneck, not Postfix.

6. Check content filter health. If the incoming queue is growing but the active queue is small, mail is accepted but not entering the delivery pipeline. Check whether your content filter (Amavis, Rspamd, ClamAV, or a Milter) is responsive:

   # Test filter port connectivity (example: Amavis on port 10024)
   nc -zv localhost 10024
   

   If the filter is unresponsive, mail piles up in the incoming queue before it ever reaches the active queue.

7. Check for bounce storms. If bounce rate is high relative to injection, a backscatter or bounce self-sustain loop may be consuming delivery capacity. Look for MAILER-DAEMON senders dominating the queue:

   # Identify bounce sources
   grep 'status=bounced' /var/log/mail.log | head -20 | grep -o 'from=<[^>]*>' | sort | uniq -c
   

Metrics and signals to monitor

Fixes

Slow destination monopolization (queue gridlock)

When one destination consumes most active queue slots, other destinations are starved. The queue manager uses fair queueing, not priority queueing, so a single slow domain can block everything.

1. Identify the consuming destination using the top-deferred-domains command.
2. Temporarily reduce destination concurrency for that transport:

   # Reduce smtp delivery concurrency (disruptive: affects all smtp deliveries)
   postconf -e 'smtp_destination_concurrency_limit=2'
   postfix reload
   

3. Emergency: hold mail for the problem domain to free active queue slots:

   # Find and hold mail to a specific domain
   # Disruptive: those messages stop delivery entirely until released
   # Slow on large queues; grep reads every deferred file
   # Queue files are plain text (header + content); grep -l works across Postfix versions
   find /var/spool/postfix/deferred -type f -exec grep -l '@problem.domain' {} \; | sed 's|.*/||' | postsuper -h -
   

   Release with postsuper -H ALL or postsuper -H queue_id after the destination recovers.

DNS resolver failure

1. Test the resolver directly from the MTA host using dig or host against the configured nameserver.
2. Check the resolver process:

   # Check resolver status
   systemctl status systemd-resolved
   pgrep -a named
   

3. Add a fallback resolver to /etc/resolv.conf if the local resolver has failed, then run postfix reload.

Content filter or Milter backpressure

1. Check filter process health: systemctl status amavisd or equivalent for your filter.
2. Test the filter port directly with nc -zv.
3. Emergency bypass (security tradeoff: accepts unfiltered mail):

   # DANGEROUS: disables all content filtering until reversed
   postconf -e 'content_filter='
   postfix reload
   

   Re-enable filtering as soon as the filter is healthy.

Bounce storm

1. Identify the bounce source from log analysis using the command in diagnostic step 7.
2. Tighten recipient restrictions if accepting mail for unknown recipients causes backscatter.
3. Clear bounce queue carefully, verifying patterns before deletion:

   # DANGEROUS: verify the pattern matches only bounce messages before running
   # tr -d '*!' strips the active (*) and hold (!) indicators from queue IDs
   mailq | grep -E 'MAILER-DAEMON|double-bounce' | awk '{print $1}' | tr -d '*!' | postsuper -d -
   

What not to do

• Do not flush the entire deferred queue with postqueue -f during congestion. This floods already-saturated destinations with retry attempts and makes the problem worse. The Postfix QSHAPE_README explicitly warns against this.
• Do not restart Postfix as a first response. A restart triggers a full queue rescan that can be slow on large queues, and it loses in-memory queue manager state including retry timers and rate-limit counters. Use postfix reload for configuration changes.
• Do not raise qmgr_message_active_limit blindly. Higher limits increase memory usage in the queue manager, which is single-threaded and not memory-efficient with large queues. Address the root cause of the bottleneck first.

Prevention

• Monitor injection versus delivery velocity as a leading indicator. Alert when delivery equals 0 with injection above 0 for more than 10 minutes, and when the deferred ratio exceeds 20% of injection.
• Track active queue utilization against qmgr_message_active_limit. Alert at 80% sustained.
• Monitor the DNS resolver independently from Postfix. Resolver failure looks like slow mail, not an obvious error. Track resolver latency and failure rate as separate signals.
• Track content filter response time, not just process liveness. Filter slowdown causes queue backup long before the process crashes.
• Monitor queue filesystem inodes, not just disk space. Postfix creates one file per queued message. Inode exhaustion manifests as “No space left on device” even when df shows free space.
• Monitor bounce rate explicitly. Bounces generate status=sent lines, making them invisible in simple delivery metrics. Track bounce rate as its own signal and alert above 1% sustained.

How Netdata helps

Netdata collects the signals that distinguish injection-versus-delivery problems and shortens the diagnostic path:

• Per-second mail flow metrics show injection and delivery rates diverging in real time, before queue depth accumulates enough to trigger lagging alerts.
• Queue depth breakdowns across incoming, active, and deferred directories show exactly where mail is piling up, distinguishing destination monopolization from filter backpressure.
• DNS resolver latency and error rates are collected independently from Postfix, making it clear whether delivery failures stem from DNS rather than the MTA.
• Content filter and Milter process metrics (memory, CPU, file descriptors) reveal filter degradation before it becomes a complete stop.
• Anomaly detection on injection and delivery rates flags divergence from historical baselines even when absolute values look normal.

Related guides

• How Postfix actually works in production: a mental model for operators
• Postfix master process not running: the whole MTA is down
• Postfix monitoring checklist: the signals every production mail server needs
• Postfix monitoring maturity model: from survival to expert