Postfix Connection timed out: delivery deferrals to unreachable destinations

The mail log shows the same deferral line for every message to one or more destinations:

status=deferred (connect to mx.example.com[192.0.2.1]:25: Connection timed out)

Postfix sent a TCP SYN to the destination MX on port 25 and received no SYN-ACK within smtp_connect_timeout (default 30 seconds). Something on the network path silently dropped the SYN. Postfix defers the message and schedules a retry with exponential backoff.

Distinguish this from two other errors that produce similar queue growth but need different fixes:

• Connection refused: the remote host sent a RST. The destination is reachable; port 25 is closed. Remote-side or configuration issue.
• Host not found / Name service error: DNS resolution failed. No MX record returned, or the resolver timed out. DNS problem.
• Connection timed out: the SYN went out and nothing came back. The problem is the network path.

Postfix will not retry the deferred message until its backoff timer expires (minimal_backoff_time, default 300s). After applying a fix, run postqueue -f to force an immediate retry sweep. On large deferred queues, this generates a burst of outbound connection attempts.

flowchart TD
    A["Log: Connection timed out to MX IP port 25"] --> B{"All destinations affected?"}
    B -->|"Yes"| C["Test: nc to known MX port 25"]
    C --> D{"Times out?"}
    D -->|"Yes"| E["Outbound port 25 blocked
or network partition"]
    D -->|"No"| F["Check inet_protocols,
nf_conntrack, Postfix config"]
    B -->|"One or few destinations"| G["Test connectivity to
the specific MX IP"]
    G --> H{"Times out?"}
    H -->|"Yes"| I["Remote MX overloaded
or path-specific firewall"]
    H -->|"No"| J["Check IPv6 vs IPv4,
DNS resolution details"]

Common causes

Quick checks

All read-only and safe on a production server. The mail log path varies by distribution: /var/log/mail.log on Debian/Ubuntu, /var/log/maillog on RHEL/CentOS.

# Confirm the current connect timeout
postconf -h smtp_connect_timeout

# Test outbound port 25 to a known-good MX
timeout 35 bash -c 'echo QUIT | nc -w 30 gmail-smtp-in.l.google.com 25'

# Test a specific failing MX IP
timeout 35 bash -c 'echo QUIT | nc -w 30 192.0.2.1 25'

# Check inet_protocols (all means ipv4+ipv6)
postconf -h inet_protocols

# Top deferred destinations by domain
grep 'status=deferred' /var/log/mail.log | grep -o 'to=<[^>]*>' | sed 's/.*@//' | sort | uniq -c | sort -rn | head -20

# Current deferred queue size
find /var/spool/postfix/deferred -type f | wc -l

# Check conntrack SYN_SENT timeout (Linux with netfilter loaded; default is 120s)
cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_syn_sent 2>/dev/null || echo "conntrack module not loaded"

# Resolve MX for a failing destination
dig +short example.com MX

# Check compatibility_level (Postfix 3.0+)
postconf -h compatibility_level

How to diagnose

1. Determine scope. Run the deferred-destinations grep above. If every domain is timing out, the problem is local: outbound port 25, local firewall, or DNS resolver. If only a few domains are affected, the problem is destination-specific: remote overload, path-specific firewall, or IPv6 issue.

2. Test direct TCP connectivity. Pick a failing destination MX IP and test from the server:

   # Test to the specific MX IP that Postfix is timing out on
   timeout 35 bash -c 'echo QUIT | nc -w 30 192.0.2.1 25'
   

   If this also times out, the problem is the network path or port blocking. If it succeeds, the problem may be intermittent or specific to Postfix configuration (IPv6 preference, concurrency limits).

3. Check for port 25 blocking. Cloud providers commonly block outbound port 25 by default. Test to multiple well-known MX hosts. If all time out, port 25 is almost certainly blocked at the network level. If some succeed and others do not, the problem is path-specific.

4. Check IPv6. If your server has an IPv6 address and inet_protocols = all, Postfix may attempt delivery over IPv6. With the default smtp_address_preference = any, Postfix alternates between IPv4 and IPv6 addresses across destinations (smtp_balance_inet_protocols = yes by default). If IPv6 routing is broken (common on hosts with IPv6 configured but no working route), the connection attempt burns the full timeout before falling back:

   # Check if the destination has AAAA records
   dig +short example.com AAAA
   
   # Test IPv6 connectivity directly
   nc -6 -w 5 mx.example.com 25
   

   If IPv6 connectivity is broken, set inet_protocols = ipv4 and do a full restart (not reload). This causes a brief service interruption.

5. Check DNS. Verify that MX records resolve correctly and quickly:

   dig example.com MX
   

   DNS failures typically produce “Host not found” rather than “Connection timed out.” DNS resolution and TCP connection establishment are separate phases in the smtp delivery agent, so a slow-but-successful DNS lookup should not affect smtp_connect_timeout.

6. Check conntrack on Linux. If netfilter connection tracking is loaded, verify that the SYN_SENT timeout is not set below smtp_connect_timeout:

   ls /proc/sys/net/netfilter/nf_conntrack_tcp_timeout* 2>/dev/null
   

   A SYN_SENT timeout below 30 seconds can cause conntrack to drop the session entry before Postfix’s own timeout fires, producing intermittent failures. The default is 120s on most distributions, so this requires unusual misconfiguration.

7. Check for post-upgrade changes. If timeouts started after a Postfix upgrade, check compatibility_level and run postconf -n to compare active settings against expected values. Postfix 3.9 introduced smtpd_forbid_bare_newline (default normalize) on the inbound smtpd side and capped DNS lookup results at 100 records; neither causes outbound “Connection timed out”. Review the release notes for your version.

Metrics and signals to monitor

Fixes

Outbound port 25 blocked

If all destinations time out, port 25 is blocked somewhere between your server and the internet. This is the most common cause on cloud platforms.

Option 1: Relay through a smart host. Configure Postfix to send all outbound mail through a relay on port 587 (submission), which is not subject to port 25 blocking:

postconf -e 'relayhost = [relay.example.com]:587'
postconf -e 'smtp_sasl_auth_enable = yes'
postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
postconf -e 'smtp_tls_security_level = encrypt'

Create the password map file, run postmap /etc/postfix/sasl_passwd, then reload Postfix.

Option 2: Request port 25 unblocking. AWS, Google Cloud, and other providers can unblock outbound port 25 on request. This takes hours to days and may require justification.

Broken IPv6 routing

If IPv6 connectivity is broken but IPv4 works, force IPv4-only delivery:

postconf -e 'inet_protocols = ipv4'
postfix stop && postfix start

A postfix reload is insufficient because inet_protocols is read at process startup, not on reload. This causes a brief service interruption.

Remote MX overload

If one destination times out but others deliver normally, the remote MX may be overloaded, rate-limiting your IP, or experiencing its own outage. Postfix will retry with exponential backoff. Do not force-flush repeatedly; it adds load to an already-struggling destination.

If the destination is consuming too many active queue slots and starving other destinations, temporarily reduce concurrency:

postconf -e 'smtp_destination_concurrency_limit = 2'
postfix reload

nf_conntrack interference

If conntrack is dropping sessions prematurely, raise the SYN_SENT timeout above smtp_connect_timeout:

# Current value
cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_syn_sent

# Raise to exceed smtp_connect_timeout (system-wide change, requires root)
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_sent=60

Make the change persistent in /etc/sysctl.conf or a file under /etc/sysctl.d/.

Post-upgrade behavior changes

If timeouts started after upgrading to Postfix 3.9+, review the release notes for behavioral changes. Run postconf -n and compare against your pre-upgrade configuration. Check compatibility_level and any new defaults that may have changed delivery behavior.

Prevention

• Monitor outbound connectivity independently. Probe TCP connectivity to port 25 on known MX hosts from the server. This catches port blocking before users notice deferred mail.
• Track deferred queue growth rate, not just size. A static queue of 5,000 messages may be fine. A queue growing at 500 messages per hour is a problem regardless of absolute size.
• Set inet_protocols explicitly. If you do not need IPv6 for mail delivery, set inet_protocols = ipv4 to eliminate IPv6 fallback delays.
• Tune smtp_connect_timeout for your environment. The default 30 seconds is appropriate for general internet delivery. For high-volume relays to known destinations, shorter timeouts fail faster and move on to the next MX; the TUNING_README recommends reducing the value below the default without prescribing an exact number.
• Document your cloud provider port 25 policy. Know whether outbound port 25 is blocked before deployment, and have a relay host configured as a fallback.

How Netdata helps

Netdata surfaces the signals that distinguish “Connection timed out” from other deferral causes, and correlates them with system-level network metrics:

• Per-second deferred queue metrics show the growth rate that absolute snapshots miss. A rising deferred rate with a flat delivery rate is the earliest indicator of a connectivity problem.
• Active queue depth vs. qmgr_message_active_limit reveals when one slow destination monopolizes delivery slots and starves others.
• Network connection metrics on the host show outbound SYN counts, connection states, and conntrack table utilization. A spike in SYN_SENT states without corresponding ESTABLISHED transitions confirms network path failure.
• DNS query latency from the host distinguishes slow resolution from actual TCP timeout.
• Correlation across the stack lets you see whether a deferred queue spike aligns with a network partition, a cloud provider maintenance window, or a configuration change timestamp.

For a broader view of Postfix monitoring signals, see the Postfix monitoring checklist.

Related guides

• Postfix active queue saturation: hitting qmgr_message_active_limit
• How Postfix actually works in production: a mental model for operators
• Postfix mail flow: injection rate outpacing delivery rate
• Postfix queue message age: the delivery latency queue depth cannot show
• Postfix monitoring checklist: the signals every production mail server needs
• Postfix not listening on port 25 or 587: connection refused