How to Fix Postfix 'Connection Refused' (Port 25/587 Error)
Fix Postfix 'Connection Refused' errors quickly. Learn how to diagnose port 25/587 issues, firewall rules, master.cf misconfigurations, and resolve slow deliver
- Postfix is not listening on the expected interface (e.g., bound to localhost instead of all interfaces).
- Firewall rules (iptables/ufw/firewalld) are actively rejecting incoming connections to port 25 or 587.
- Syntax errors or misconfigurations in main.cf or master.cf are preventing the daemon from starting.
- Port conflicts exist with other MTAs like Sendmail or Exim already running on the server.
- Quick fix: Check `ss -tulnp | grep :25`, review `inet_interfaces` in `main.cf`, and restart Postfix.
| Method | When to Use | Time | Risk |
|---|---|---|---|
| Updating inet_interfaces | Localhost only connection refused | 2 mins | Low |
| Adjusting Firewall Rules | External connection refused | 5 mins | Medium |
| Restarting/Reloading Postfix | After configuration changes | 1 min | Low |
| Editing master.cf | Submission (587) or SMTPS (465) failing | 10 mins | High |
Understanding the 'Connection Refused' Error
When managing a Linux mail server, encountering a Connection refused error when trying to send an email through Postfix is a rite of passage. This error typically manifests when an email client (MUA) or another Mail Transfer Agent (MTA) attempts to connect to your Postfix server on port 25 (SMTP), 465 (SMTPS), or 587 (Submission), but the operating system explicitly rejects the TCP handshake.
The error usually looks like this in your application logs or when testing via telnet:
telnet: Unable to connect to remote host: Connection refused
Or in your mail client or application logs:
Dial tcp 192.168.1.10:25: connect: connection refused
Unlike a connection timeout (which usually indicates a firewall dropping packets silently), a Connection refused (TCP RST packet received) means one of two things: either no service is listening on the target port and IP address, or a firewall is actively rejecting the connection. Let's break down the troubleshooting process step-by-step to diagnose and resolve these connection issues permanently.
Step 1: Verify Postfix is Running and Listening
The absolute most common reason for a connection refused error is that Postfix simply isn't running, or it's running but only listening on the local loopback interface (127.0.0.1), while you are trying to connect to its public IP address.
First, check the status of the Postfix service using systemd:
sudo systemctl status postfix
If it's not active, attempt to start it. If it fails to start, check the logs immediately to identify the crash reason:
sudo tail -n 50 /var/log/mail.err or sudo journalctl -u postfix
If Postfix is running smoothly, verify which interfaces and ports the master daemon is bound to using ss or netstat:
sudo ss -tulnp | grep master
Look closely at the Local Address column. If you see 127.0.0.1:25 or ::1:25 but you are trying to connect from an external machine on a public IP, the connection will invariably be refused because Postfix is deaf to the outside world.
Step 2: Configure inet_interfaces in main.cf
By default, many Linux distributions configure Postfix to listen only on the loopback interface for security reasons, preventing it from acting as an open relay out of the box. To allow external connections (for receiving mail from the internet or allowing remote clients to send), you must modify the /etc/postfix/main.cf file.
Open /etc/postfix/main.cf in your preferred text editor and locate the inet_interfaces directive. Change it from loopback-only or localhost to all (or specify explicit IP addresses separated by commas):
inet_interfaces = all
After making this change, you must restart (not just reload) Postfix. This is a critical distinction because interface bindings are established when the master daemon initially starts up. A simple reload will not bind new ports:
sudo systemctl restart postfix
Step 3: Enabling Submission (Port 587) and SMTPS (Port 465)
If port 25 is working but you are getting 'Connection refused' on port 587 or 465, the issue lies in your master.cf file. Port 25 is meant for server-to-server communication. Client submissions should happen over port 587 (STARTTLS) or 465 (implicit TLS).
Open /etc/postfix/master.cf. Look for the lines starting with submission and smtps. They are likely commented out (prefixed with a #).
To enable port 587, uncomment the submission line and its essential options:
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
Save the file and restart Postfix. ss -tulnp | grep :587 should now show the master process listening.
Step 4: Firewall and Network Security Groups
If Postfix is explicitly listening on 0.0.0.0:25 (all IPv4 interfaces) but you still receive a connection refused error from an external machine, inspect your firewall. While firewalls typically drop packets causing timeouts, misconfigured rules set to REJECT will send an ICMP port unreachable or TCP RST, resulting in a direct Connection refused message.
Check UFW (Ubuntu/Debian):
sudo ufw status verbose
Allow the necessary ports if they are missing:
sudo ufw allow 25/tcp
sudo ufw allow 587/tcp
Check firewalld (CentOS/RHEL/Fedora):
sudo firewall-cmd --permanent --add-service=smtp
sudo firewall-cmd --permanent --add-service=smtp-submission
sudo firewall-cmd --reload
If your infrastructure is hosted on AWS, GCP, or Azure, ensure that the cloud provider's Network Security Group (NSG) or VPC firewall rules allow inbound traffic on TCP ports 25, 465, and 587. Note that many cloud providers heavily restrict outbound port 25 to prevent spam, but inbound is entirely controlled by your security group settings.
Step 5: Troubleshooting 'Postfix Slow' or Intermittent Refusals
Sometimes Postfix works, but connections take up to 30 seconds to establish, or they are intermittently refused. This is predominantly related to DNS resolution delays or process limits.
DNS Reverse Lookups: Postfix aggressively performs reverse DNS (PTR) lookups on connecting client IP addresses for logging and spam prevention. If your server's configured DNS resolvers are slow, offline, or misconfigured, the connection establishment hangs, leading to application timeouts that appear to the user as failures. Ensure /etc/resolv.conf contains fast, reliable, and reachable nameservers (like 1.1.1.1 or 8.8.8.8) or an internal caching resolver.
Connection Limits Reached: If your server is under heavy legitimate load or experiencing a dictionary attack, Postfix might reach its concurrent connection limit, actively refusing new TCP connections. Check your smtpd process limits in /etc/postfix/master.cf (the maxproc column, usually the 5th column). The default is typically 100. If you observe warnings in /var/log/mail.log stating connection limits reached, you may need to increase this number cautiously to avoid starving the system of RAM.
Step 6: Resolving Address Binding Conflicts
If Postfix outright fails to start, and the system logs show fatal: bind 0.0.0.0 port 25: Address already in use, it indicates a severe port conflict. Another service has already claimed port 25. This is frequently a legacy MTA like Sendmail or Exim, which might be pre-installed on older distributions.
Identify the conflicting daemon exactly:
sudo ss -tulnp | grep :25
If you see a different process name (e.g., sendmail or exim4), you must stop and disable it permanently:
sudo systemctl stop sendmail
sudo systemctl disable sendmail
Once the conflicting service is terminated, you can safely start Postfix:
sudo systemctl start postfix
Conclusion
Resolving a Postfix connection refused error relies on a systematic verification process: ensuring the daemon is actually running, confirming it is bound to the correct network interfaces via main.cf, enabling appropriate client ports in master.cf, and validating that no system or cloud firewalls are actively rejecting the traffic. By systematically checking local listeners with ss, verifying configurations, and monitoring /var/log/mail.log, you can rapidly restore mail flow and ensure robust SMTP connectivity.
Frequently Asked Questions
# 1. Check if Postfix is listening and identify the bound interfaces
sudo ss -tulnp | grep -E ':(25|587|465)'
# 2. Check Postfix service status and recent error logs for crashes
sudo systemctl status postfix
sudo tail -n 50 /var/log/mail.err
# 3. Update main.cf to listen on all interfaces (requires root)
sudo sed -i 's/inet_interfaces = localhost/inet_interfaces = all/g' /etc/postfix/main.cf
# 4. Restart Postfix to apply interface bindings (reload is not enough)
sudo systemctl restart postfix
# 5. Check firewall status and allow mail ports (UFW example)
sudo ufw status verbose
sudo ufw allow 25/tcp
sudo ufw allow 587/tcpError Medic Editorial
Our SRE team has resolved thousands of Linux server and mail routing issues. We specialize in providing actionable, no-nonsense fixes for DevOps engineers, sysadmins, and infrastructure developers.