Postfix Connection refused: blocked port 25 and rejected outbound delivery

You see status=deferred (connect to mx.example.com[192.0.2.1]:25: Connection refused) filling your mail logs. The deferred queue is growing. Postfix cannot establish outbound TCP connections to destination mail servers.

“Connection refused” is not the same as “Connection timed out.” Connection refused means the TCP handshake was actively rejected with a RST packet: the destination IP is reachable, but nothing is listening on that port, or something in the path is rejecting the connection. Connection timed out means the SYN packet was silently dropped: a firewall rule, a network partition, or an ISP dropping egress traffic.

A sub-second connect delay in the log’s delays= field confirms Connection refused. A connect delay near your smtp_connect_timeout (default 30 seconds) confirms Connection timed out.

What this means

When Postfix logs Connection refused, the smtp delivery agent attempted a TCP connect to the destination MX, relayhost, or transport_maps target on port 25 and received an immediate RST. Postfix classifies this as a temporary failure (DSN 4.4.1), defers the message, and schedules a retry with exponential backoff. The deferred queue grows as long as the condition persists.

The canonical log pattern:

postfix/smtp[PID]: QUEUEID: to=<user@domain>, relay=none, delay=0.8,
  delays=0.1/0.1/0.5/0.1, dsn=4.4.1, status=deferred
  (connect to mx.example.com[192.0.2.1]:25: Connection refused)

Three fields tell you what happened:

• relay=none: Postfix never reached the destination. No SMTP session was established.
• delays= third field (connect time): Sub-second means actively refused. Near 30 seconds means timed out. This is your primary triage signal.
• connect to <host>[<ip>]:<port>: The specific host and port Postfix tried to reach. This tells you whether the problem is a content filter on localhost, a relayhost, a transport_maps target, or a destination MX.

Common causes

Quick checks

# Confirm the error pattern and count recent refusals
grep 'Connection refused' /var/log/mail.log | tail -20

# Check connect delay timing (refused is sub-second; timed out is near 30s)
grep 'Connection refused' /var/log/mail.log | grep -oE 'delays=[^ ]+' | tail -10

# Check if relayhost is configured
postconf -h relayhost

# Check transport_maps for domain-specific overrides
postconf -h transport_maps

# Check smtp_connect_timeout (confirms timeout boundary)
postconf -h smtp_connect_timeout

# Test direct TCP to a known MX on port 25
nc -w 5 -zv gmail-smtp-in.l.google.com 25

# Check for content filter refusals to localhost
grep 'connect to 127.0.0.1' /var/log/mail.log | tail -10

# See which destinations are being refused and how often
grep 'Connection refused' /var/log/mail.log | grep -oE 'connect to [^ ]+' | sort | uniq -c | sort -rn | head

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

On RHEL and CentOS systems, substitute /var/log/maillog for /var/log/mail.log.

How to diagnose it

Work through the decision tree in order. The log line tells you which path to take based on the connect to target.

flowchart TD
    A["Log shows Connection refused"] --> B{"Refused target?"}
    B -->|"127.0.0.1 port"| C["Content filter down"]
    B -->|"relayhost"| D["Test relayhost port 25"]
    B -->|"destination MX"| E{"All destinations
or one domain?"}
    E -->|"All destinations"| F["Port 25 egress blocked"]
    E -->|"One domain"| G["MX down or transport override"]
    C --> H{"Filter process running?"}
    H -->|No| I["Restart filter"]
    H -->|Yes| J["Check filter port config"]
    D --> K{"Reachable?"}
    K -->|No| L["Fix relayhost or remove"]
    K -->|Yes| M["Check transport_maps"]
    F --> N["Route via relay on 587 or 465"]
    G --> O["dig MX and inspect transport_maps"]

Step 1: Identify the refused target. Parse the connect to <host>[<ip>]:<port> field from the log line. If it is 127.0.0.1 or localhost, this is a content filter problem, not an outbound delivery problem. If it is a relayhost address, skip to step 4. If it is a destination MX, continue.

Step 2: Determine scope. Are all destinations refused, or just one domain? Extract and group the refused targets:

grep 'Connection refused' /var/log/mail.log | grep -oE 'connect to [^ ]+' | sort | uniq -c | sort -rn | head

If every destination shows Connection refused, the problem is on your side: port 25 egress is blocked, or Postfix cannot route traffic. If only one or a few domains are affected, the destination itself is the issue, or a transport_maps entry is routing those domains somewhere unexpected.

Step 3: Test port 25 egress directly. Pick a well-known MX and test TCP connectivity:

# Test TCP connectivity to a known MX on port 25
nc -w 5 -zv gmail-smtp-in.l.google.com 25

If this fails with Connection refused or times out, your server cannot reach the internet on port 25. This is almost certainly ISP or cloud provider egress filtering. AWS EC2 blocks outbound port 25 by default and lifts the block only on request; Azure blocks outbound SMTP on port 25 for VMs (exemption requestable); GCP blocks outbound port 25 to destinations outside your VPC; OVH blocks it on VPS (requestable); DigitalOcean blocks it (unblock via support ticket). Hetzner does not block outbound port 25 by default. Many residential ISPs (Comcast, Verizon, AT&T) do the same. Check your provider’s documentation.

Step 4: Check relayhost configuration. If postconf -h relayhost returns a value, every outbound message should go through that host. Show the relayhost, then test it manually:

# Show relayhost configuration
postconf -h relayhost
# Test connectivity manually based on output, e.g.:
# nc -w 5 -zv smtp.relay.example 587

If the relayhost refuses connections, it is down or not listening on the configured port. Fix the relayhost, or temporarily remove it to allow direct delivery (if your provider does not block port 25).

Step 5: Check transport_maps overrides. If both relayhost and transport_maps are set, transport_maps takes precedence for matching domains. A transport map entry for a specific domain bypasses the relayhost entirely, causing direct connections that may be refused if port 25 egress is blocked:

# Show transport_maps configuration
postconf -h transport_maps

# Test lookups for affected domains
postmap -q example.com hash:/etc/postfix/transport

Step 6: Check content filter health. If logs show connect to 127.0.0.1[127.0.0.1]:10024: Connection refused, your content filter (typically Amavis, Rspamd, or a commercial filter) is not running or not listening on the configured port. This is not an outbound delivery problem, but it looks identical in the logs:

# Check if content_filter is configured
postconf -h content_filter

# Test the filter port directly
nc -zv 127.0.0.1 10024

# Check filter process status
systemctl status amavisd 2>/dev/null || systemctl status rspamd 2>/dev/null

Metrics and signals to monitor

Fixes

Port 25 egress blocked by ISP or cloud provider

This is the most common cause for servers in cloud environments. AWS EC2 blocks outbound port 25 by default. Many residential ISPs do the same. The fix is to route outbound mail through a relay service on port 587 or 465.

These commands modify live Postfix configuration. Run postfix reload after applying changes. Test with a single message before flushing the queue.

# Set relayhost to a submission relay (adjust host and port)
postconf -e 'relayhost = [smtp.relay.example]:587'

# Enable SASL authentication for the relay
postconf -e 'smtp_sasl_auth_enable = yes'
postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'

# Create the password map
echo '[smtp.relay.example]:587 username:password' > /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

# Reload configuration
postfix reload

This change takes effect immediately for new delivery attempts. Existing deferred messages will be retried against the new relayhost on the next scheduled attempt.

relayhost configured but not listening

If the relayhost itself is down or not accepting connections, all outbound mail stalls. Fix the relayhost service. As a temporary measure, you can remove the relayhost to allow direct delivery, but this only helps if your provider does not block port 25:

# Temporarily remove relayhost for direct delivery
postconf -e 'relayhost ='
postfix reload

Warning: if port 25 egress is also blocked (common in cloud environments), removing relayhost makes things worse, not better. Verify port 25 egress works before relying on direct delivery.

Content filter port down

If the filter process crashed or was never started after a reboot, mail queues up with Connection refused to the filter port. Restart the filter:

# Restart the content filter
systemctl restart amavisd  # or rspamd, or your filter service

In an emergency, you can bypass the filter entirely. This accepts unfiltered mail rather than queueing indefinitely:

# Emergency bypass: mail will be unscanned
postconf -e 'content_filter ='
postfix reload

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

transport_maps overriding relayhost

If transport_maps routes specific domains directly (bypassing relayhost), those domains will fail when port 25 egress is blocked. Inspect the transport map and either remove the override or point it through the relay:

# View the transport map source file
postconf -h transport_maps

# Look up routing for a specific domain
postmap -q problem.domain.com hash:/etc/postfix/transport

Fix the transport map entry, rebuild it with postmap, and reload Postfix.

Destination MX not accepting connections

If only one destination is affected, the problem is on their end. Postfix will retry per its backoff schedule. No action is needed unless the destination is business-critical, in which case consider using a backup relay or contacting the destination postmaster.

Prevention

• Know your provider’s port 25 policy before deploying. AWS and many ISPs block outbound port 25. Plan for relay-based delivery from the start.
• Monitor deferred queue growth rate, not just absolute size. A static queue of 5,000 messages that is shrinking is fine. The same size growing rapidly is a crisis.
• Monitor content filter process health and response time. A filter that is running but unresponsive causes the same symptoms as one that is down.
• Document relayhost and transport_maps dependencies. A transport_maps entry that silently overrides relayhost is easy to forget during incident triage.
• Include port 25 connectivity tests in deployment checks. A simple nc -zv to a known MX during provisioning catches egress blocks before production traffic hits them.
• Alert on deferral reason distribution. A spike in “Connection refused” as a percentage of deferrals distinguishes port 25 blocking from other delivery problems.

How Netdata helps

• Per-second deferred queue depth and growth rate. The derivative (growth rate) catches queue buildup from Connection refused before it reaches crisis, and is more actionable than absolute count.
• Mail flow velocity (injection vs delivery rate). Divergence between these two rates is the earliest indicator that outbound delivery is failing, often minutes before the deferred queue becomes visibly large.
• Postfix log parsing for deferral reason codes. Surfaces whether the dominant error is Connection refused (port closed), Connection timed out (port filtered), 4xx responses (destination throttling), or DNS failures, determining which diagnostic path to follow.
• Content filter process and port health. Independent checks on the filter process and its listening port catch filter outages before they manifest as Postfix delivery failures.
• TCP connectivity probes. Tests relayhost and content filter ports independently of Postfix, confirming whether the problem is configuration or network reachability.
• DNS resolver latency and failure rate. Rules out DNS as a contributing factor; DNS failure causes a different deferral pattern that requires a different fix.

Related guides

• Postfix deferred queue growing: why mail piles up and how to drain it
• Postfix not listening on port 25 or 587: connection refused
• Postfix mail flow: injection rate outpacing delivery rate
• How Postfix actually works in production: a mental model for operators
• Postfix flushing and clearing the deferred queue: postqueue and postsuper
• Postfix monitoring checklist: the signals every production mail server needs