This error means that the smtp-proxy component failed to establish a connection to the upstream mail server, likely because the upstream server rejected the initial connection attempt.
The most common reason for this is that the upstream mail server is actively blocking connections from your IP address. This can happen for a variety of reasons, including:
-
IP Address Reputation: Your mail server’s IP address may have a poor reputation due to past spamming activity, either by you or by previous users of that IP.
- Diagnosis: Check your IP address against common Real-time Blackhole Lists (RBLs) like Spamhaus, SORBS, or Barracuda. You can use online tools like MXToolbox’s Blacklist Check.
- Fix: If your IP is listed, you’ll need to follow the delisting procedure for each specific RBL. This usually involves filling out a form and waiting for review. Once delisted, your IP’s reputation will improve over time.
- Why it works: RBLs are curated lists of IPs known to send spam. Mail servers query these lists before accepting connections. Removing your IP from these lists signals to other servers that you are no longer a spam source.
-
Firewall Rules on the Upstream Server: The remote mail server’s firewall might be configured to reject connections from specific IP ranges or individual IPs, especially if they are not on an allowlist.
- Diagnosis: If you have contact with the administrator of the remote mail server, ask them to check their firewall logs for connection attempts from your IP and any corresponding
REJECTorDROPrules. - Fix: The administrator of the remote mail server needs to add an
ALLOWrule for your server’s IP address in their firewall configuration. For example, if usingiptables, it might look like:iptables -I INPUT -s YOUR_SERVER_IP -p tcp --dport 25 -j ACCEPT. - Why it works: This explicitly permits traffic from your IP address to reach the mail server’s SMTP port, bypassing any general blocking rules.
- Diagnosis: If you have contact with the administrator of the remote mail server, ask them to check their firewall logs for connection attempts from your IP and any corresponding
-
Rate Limiting: The upstream mail server might be rate-limiting connections based on the number of connections or the rate of connection attempts from a single IP address.
- Diagnosis: Observe your outbound connection attempts over a short period. If you see a pattern of successful connections followed by rejections, rate limiting is a possibility. Some servers might return a specific error code or message indicating this.
- Fix: Adjust your mail server’s outgoing queue settings to send mail at a slower, more consistent rate. This might involve reducing the number of concurrent connections allowed to a single destination or increasing the delay between sending batches of emails. For example, in Postfix, you might adjust
max-idle-ttlandsmtp_connection_timeout. - Why it works: By reducing the frequency and intensity of connection attempts, you stay within the upstream server’s acceptable limits, preventing them from triggering their rate-limiting defenses.
-
Incorrect DNS Records (MX Records): The MX records for the recipient’s domain might be misconfigured, pointing to an IP address that is not running an SMTP server or is not accessible.
- Diagnosis: Use
digornslookupto query the MX records for the recipient’s domain. For example:dig MX example.com. Verify that the returned IP addresses are correct and that you can ping or telnet to those IPs on port 25. - Fix: The administrator of the recipient’s domain needs to correct their DNS MX records to point to the correct mail server IP addresses.
- Why it works: Correct MX records ensure that your mail server attempts to connect to the actual mail server responsible for receiving mail for that domain.
- Diagnosis: Use
-
Network Issues or Intermediate Firewalls: There could be a firewall or network device between your server and the upstream mail server that is blocking port 25 (or the relevant SMTP port).
- Diagnosis: Perform a
tracerouteto the recipient’s mail server IP address. Look for any hops that show high latency or are marked as* * *, which could indicate a network problem or a firewall blocking the path. You can also trytelnetfrom your server to the remote IP on port 25. Iftelnettimes out, the issue is likely network-related or a firewall. - Fix: If a firewall is identified, you’ll need to work with your network administrator or the administrator of the intermediate network to open port 25 for traffic to the destination mail server IP.
- Why it works: This ensures that the network path is clear and that traffic on the necessary port can traverse without being blocked.
- Diagnosis: Perform a
-
Upstream Server Misconfiguration or Downtime: The remote mail server itself might be experiencing temporary issues, such as being overloaded, undergoing maintenance, or having a misconfiguration that prevents it from accepting new connections.
- Diagnosis: Try connecting to the remote mail server using
telnet YOUR_REMOTE_IP 25. If you get a connection refused or a very quick timeout, it could be a server-side issue. Check the remote server’s status page or contact their support if available. - Fix: In this case, there’s little you can do except wait for the remote server administrator to resolve the issue. You can configure your mail server to retry sending the email later.
- Why it works: This is a waiting game. Once the remote server is back online and accepting connections, your mail server’s retry mechanism will eventually succeed.
- Diagnosis: Try connecting to the remote mail server using
The next error you’ll likely encounter if all SMTP connection issues are resolved is a 550 Recipient unknown error, indicating that while the connection was successful, the specific email address you’re trying to send to does not exist on the remote server.