How to Fix 'Postfix Connection Refused' and Slow Delivery Issues

Understanding the 'Connection Refused' Error in Postfix

When you encounter a Connection refused error while attempting to send emails through a Postfix server, it fundamentally means that the client attempted to establish a TCP connection on a specific port (usually port 25 for SMTP, 587 for submission, or 465 for smtps), but the server OS actively rejected it. This is different from a timeout, where packets are simply dropped. A refused connection indicates that either no service is listening on that port, the service is listening on a different interface, or a firewall rule explicitly rejected the packet with a TCP RST.

Simultaneously, issues like postfix not working or postfix slow often stem from related misconfigurations: DNS resolution delays, unresponsive downstream relays, or resource exhaustion. In this guide, we will systematically diagnose and resolve these critical mail flow interruptions.

Step 1: Diagnose the Listening Sockets

The most common reason for a connection refused error is that Postfix is only listening on the local loopback interface (127.0.0.1). If an external client or another server tries to connect via the public IP, the OS will refuse the connection because Postfix isn't bound to that IP.

First, check the status of the Postfix service:

systemctl status postfix

If it's running, verify which interfaces and ports it is bound to using ss or netstat:

sudo ss -tlnp | grep master

If you see 127.0.0.1:25 but not 0.0.0.0:25 or your public IP, Postfix is restricted to local connections. This is the default configuration on many Linux distributions (like Ubuntu and Debian) for security reasons.

Step 2: Fix Interface Bindings in main.cf

To allow Postfix to accept connections from external sources, you must modify the inet_interfaces directive in the primary configuration file, main.cf.

Open /etc/postfix/main.cf with your preferred text editor:

sudo nano /etc/postfix/main.cf

Locate the inet_interfaces line. It likely looks like this:

inet_interfaces = loopback-only

Change it to all to listen on all available network interfaces, or specify specific IP addresses:

inet_interfaces = all

You should also verify the mynetworks setting to ensure you aren't inadvertently creating an open relay. It should typically only include your local subnets.

After making changes, restart Postfix:

sudo systemctl restart postfix

Step 3: Inspect Firewall and Security Groups

If Postfix is listening on 0.0.0.0:25 but external clients still receive a connection refused or timeout error, the issue is likely a firewall.

Check your local firewall rules. For UFW (Uncomplicated Firewall) on Ubuntu/Debian:

sudo ufw status

If port 25 is not listed as ALLOW, add it:

sudo ufw allow 25/tcp
sudo ufw allow 587/tcp

For systems using firewalld (RHEL/CentOS/Rocky):

sudo firewall-cmd --permanent --add-service=smtp
sudo firewall-cmd --reload

Note for Cloud Providers: If you are hosted on AWS, GCP, Azure, or DigitalOcean, you must also ensure that the cloud provider's external firewall (Security Groups or VPC firewall rules) allows inbound traffic on TCP port 25. Furthermore, many cloud providers block outbound port 25 by default to prevent spam; if your postfix not working issue is related to sending mail rather than receiving it, you may need to request the block be lifted or configure Postfix to use a relay host like SendGrid or Amazon SES.

Step 4: Master.cf Misconfigurations and Chroot Issues

Sometimes, the error is internal. You might see logs in /var/log/mail.log indicating that Postfix components cannot communicate with each other, resulting in connection refused errors between internal socket files.

This frequently happens when Postfix services are run in a chroot jail but lack the necessary libraries or socket access within the jail.

Examine /etc/postfix/master.cf. The 5th column dictates whether a service runs chrooted (y, n, or -).

If you suspect chroot issues, you can temporarily disable it for the smtp and smtpd services by changing the chroot column from y or - to n. After changing master.cf, always run postfix reload.

Step 5: Troubleshooting 'Postfix Slow' and DNS Delays

If Postfix is accepting connections but email delivery is agonizingly slow, the culprit is almost always DNS. Postfix relies heavily on DNS for MX record lookups, reverse DNS (PTR) checks, and anti-spam mechanisms (RBLs/DNSBLs).

If your server's configured DNS resolvers in /etc/resolv.conf are slow or unresponsive, every SMTP transaction will stall.

To diagnose: Check the mail queues:

mailq

If you see messages stuck with errors like Connection timed out or Host or domain name not found, test DNS resolution manually from the server:

dig MX targetdomain.com

To fix:

1. Use reliable, fast DNS resolvers (e.g., Google 8.8.8.8, Cloudflare 1.1.1.1).
2. Install a local caching DNS server like systemd-resolved, dnsmasq, or unbound to drastically reduce lookup times for repeated queries. Postfix performs many identical queries, so a local cache provides an immense performance boost.

Step 6: Checking for SMTP Restrictions and Greylisting

Another cause for delayed mail (postfix slow) is the use of postgrey or aggressive smtpd_recipient_restrictions. Greylisting intentionally rejects the first connection attempt from an unknown sender with a temporary 4xx error (which might look like a refusal or failure to an end-user), forcing the sending server to retry later. Check your main.cf for check_policy_service to see if greylisting is enabled and adjust the delay parameters if it is causing unacceptable lag.