Unable Send Email due to errors 'Cannot connect to SMTP server' or ‘4.4.1 Cannot Connect to Host’

Overview

You cannot send emails to a particular recipient, domain, or mail server. Within the Message Queue in Kerio Connect Webadmin, you see emails with the status “4.4.1 Cannot connect to host.” The warning log shows dozens of entries similar to this: “[DD/MM/YYYY HH:MM:SS] Cannot connect to SMTP server <server_name>. Messages will stay in the message queue.”

Solution

The 4.4.1 SMTP Status appears when no answer is received from the host or when the connection is lost. This could be due to a temporary issue with their network or mail server or due to a configuration within your middleware (firewall, antivirus, etc.) blocking the connectivity. You can reference the steps below to isolate the source of trouble.

Initial Checks

To ensure the issue is not caused by a fault on the sending end, review the following common sources of connectivity issues. 

1. Verify that the recipient’s email address is correct.
2. Verify that your server can reach the internet:
   1. From the server, execute a ping from the Terminal/CMD Prompt to an external website and verify that you get a response and no lost packets: $ ping google.com
      
3. Verify that your MX Records are valid:
   1. Perform an MX Record lookup on your Kerio Connect domain hostname and confirm that this is referencing your MX subdomain (mail.example.com):
      
      
4. Verify that your SMTP Server can reach other external domains:
   1. Send a test email to a different email account outside the domain experiencing the issues. (ex. Free email provider, such as Gmail.)
   2. Review the Mail Log and confirm it was delivered as expected by reviewing the SMTP response codes:
      1. 2.0.0 – Email has been delivered to the Inbox.
      2. 2.1.5 – Email has been delivered and moved to another folder due to a filtering rule

Reviewing the Logs

After verifying the above details and confirming that the issue is not system-wide and mail can leave the Kerio Connect server, the next step is to look at the Debug Log trace for the SMTP conversation.

1. Enable Additional Debug Log Messages
   1. Within the Webadmin, navigate to Logs > Debug.
   2. Right-click on the logs area, and click on Clear Log.
   3. Right-click on the logs area, and click on Messages.
   4. Enable SMTP Server, SMTP client, and Queue processing:
      
      
2. Send a Test email to the affected recipient email address.
3. Collect the Logging Details:
   1. Gather Debug logs: Navigate to Logs > Debug, right-click on logs and click on Save Log.
   2. Generate Support Information: Navigate to Status > System Health > Support Information.
   3. Note: You can safely disable the additional Debug Log messages that you enabled after saving the logs to avoid log clutter if desired.
4. Review the logs for Error Messages:
   1. Collect any errors within the Support Information log snippets related to the failing test email.
      1. For Example, "[DD/MM/YYYY HH:MM:SS] Cannot connect to SMTP server <server_name>. Messages will stay in the message queue.”
   2. Search for the destination email address within the Debug log to locate the SMTP conversation for your test email. 
      1. Note: In some high-volume servers, you may encounter issues separating the entries from each other. Once you identify a related entry, you can use the threadID to locate the other related entries.
         
         
   3. Once you have identified the SMTP conversation for your test email, you can compare the SMTP Client (smtpc) and Queue Processing (qproc) log entries to isolate where the delivery failure occurs.
      1. Most often, this will result in messages similar to the following, confirming that the failure is happening when attempting to contact the external server:

      2. [DD/MM/YYYY HH:MM:SS] [123145371508736] {qproc} SEND_REMOTE: Started delivery of queued message id=5d2be366-00000000 sender=<username@connect_domain.com>
         [DD/MM/YYYY HH:MM:SS] [123145371508736] {qproc} The default MX delivery rule is applied for sender <username@connect_domain.com> and recipient <ext_user@external_domain.com>
         [DD/MM/YYYY HH:MM:SS] [123145371508736] {qproc} Scheduling recipient: ext_user@external_domain.com to a batch in rule 'external_domain.com'
         [DD/MM/YYYY HH:MM:SS] [123145371508736] {smtpc} Connecting to server mail.external_domain.com (<ip_address_of_external_server>:25) using local interface 0.0.0.0 ...
         [DD/MM/YYYY HH:MM:SS] [123145371508736] {smtpc} Deliver mail: Cannot connect to SMTP server. User: , server: mail.external_domain.com
         [DD/MM/YYYY HH:MM:SS] [123145371508736] {qproc} SEND_MX: Result for recipient ext_user@external_domain.com: delayed, Status: 4.4.1 Cannot connect to host

5. Verify the Connectivity via Telnet
   1. From your Kerio Connect Server, attempt to establish a Telnet over port 25 to the external server: $ telnet external_domain.com 25
      
      
   2. If you see the connection timeout or refused, this confirms that the connectivity issue is not isolated to the MailServer.
6. Review your middleware configuration (Firewall or Antivirus settings) to ensure that the traffic for the Test email is able to flow from SMTP standard port(25) to the outside world.
   1. If the conversation is leaving your network, the connectivity issue is likely on the recipient’s mail server. You can contact them directly to notify them of the issue so that they can address the underlying cause.

Testing

After addressing the reason for the failing SMTP conversation, mail should now flow to the recipient mail server and the mail queue will process any emails that were stuck. You can additionally re-test the Telnet connection to the external server and once everything is okay, you will see ESMTP ready output while performing Telnet: