Overview

This article explains how to troubleshoot issues with outbound email delivery correctly. Common symptoms related to these issues are:

• Unable to send Email from SMTP Server with the error “Result: delayed, Status: 4.4.1 Cannot connect to host”
• When sending out messages, you are receiving “550 5.7.1 Relaying is denied”.

Workflow

Instructions

Each blue rectangle represents a troubleshooting procedure and links to a section in this article:

1. Verify SMTP Setup
2. Review the SMTP Relay Settings
3. Check MX Records
4. Enable SMTP Debug Logs and Reproduce
5. Check your Domain for Blacklisting
6. Verify Recipient Domain Connectivity
7. Test Ping from Connect Server to Recipient Server
8. Test Ping from Connect Server to Neutral Server
9. Test SMTP via Telnet
10. Check Firewall/AV Settings on the Connect Host Server/Network
11. Enable Additional Logs and Simplify Test Scenario
12. Contact IT Department to Correct
13. Analyze SMTP Conversation
14. Compare Configuration Differences to Correct Issue
15. Check for Known Status Issues
16. Contact Recipient to Address

Verify SMTP Setup

Before you can begin troubleshooting the specific behavior that you see with the failed outbound delivery of emails, take a moment to review the current SMTP configuration within Kerio Connect. This includes checking the Server-side SMTP settings as shown within Configuring SMTP Server and the SMTP Configuration of the SMTP Client where the emails are drafted.

Some helpful questions to ask while verifying the scenario:

• Does this impact all users in all locations using every email client?
• Does the issue only happen when relaying the email?
• Were there any recent changes to the Network, SMTP Configuration, or Server itself?
• Is this only affecting particular recipients or certain email domains?
• Is this only affecting outgoing emails, or are inbound emails also affected?

Review the SMTP Relay Settings

If you are using an SMTP Relay to deliver email, the first step is confirming that the defined settings are valid. You can use the guidance within Sending Kerio Connect Emails Through SMTP Outbound Relay. The most common issues with relays are authentication or security, as there can often be multiple layers at play in either scenario.

You can review the Warning Log within the WebAdmin Portal to check for hints at a potential Authentication issue, as shown within Email Domain Forwarding.

Check MX Records

Many email servers will prevent the delivery of messages with invalid mismatched MX records. Perform a DNS check against both the Sending and Receiving domains to confirm both are correctly defined. You can utilize a utility such as MXToolbox to run this check.

While you will often be unable to correct the MX Records for the Receiving end directly, this can help illuminate potential delivery issues, such as the Host Not being Found. If you identify a problem with the receiving end’s DNS records, Contact the Recipient to Address the issue.

Enable SMTP Debug Logs and Reproduce

Once the initial checks have been run, the next step is to increase the Debug Logging level and reproduce the behavior to allow you to continue the investigation better. Using the guidance within Enabling Debug Log Messages Types in Kerio Connect to enable the following log messages at a minimum:

• SMTP Server
• SMTP Client
• Queue Processing

These will provide you with a better look at each of the main components involved in sending emails. Within higher volume servers, these can result in an increased number of logging messages being generated, reducing the server performance. As such, you should consider disabling any other message types while actioning this test to help reduce the load and make the analysis of the logs easier. We generally suggest clearing the Debug Log before sending your test email for a similar reason.

Once the Debug Logs have been enabled, perform the test scenario where the issue first appeared. Wait a few moments to ensure you capture all related messages and then Save the Debug Log. Once collected, you can locate the failing SMTP conversation within for any clear errors, such as a connection being refused or closed by the Remote Host(Receiving Server).

Check your Domain for Blacklisting

This particular SMTP error is most often seen in situations where your Domain has been Blacklisted or Greylisted. As a first step, it is suggested that you check your Domain against blacklists using a 3rd-party utility like mxToolbox. If you identify your domain, it may explain this temporary server error. Most of the major blacklist maintainers provide a method to get your IP removed.

MXToolbox provides further details about their findings, as shown below. You can select this to learn more about the blacklist, what options are available to you, and more.

If you are not listed on a blacklist, this may indicate that the recipient mail server has instead greylisted your IP.

If this is occurring with an email server you have messaged before, it can indicate throttling. Often this can occur due to instances of bulk emails being sent to the affected domain. The best course of action is generally to wait sometime before sending additional emails and verifying whether the issue persists.

If you are seeing this issue only when emailing O365 users, please reference the guidance within Unable to Email O365 Domain due to SMTP Error “451 4.4.4 Temporary Server Error" to verify the cause and potentially remove your domain from their internal blacklists.

Verify Recipient Domain Connectivity

If you identify a failed connection to the Remote host, whether closed or outright refused, this can often indicate a connectivity issue of one kind or another. Many great utilities can help analyze the potential causes of these connection issues. For example, checktls.com provides a convenient “Receiver Test,” which you can use to validate the receiving Servers ability to receive mail:

Once it completes, you can select “Show Details” to get a better look at any issues it identifies. In the example snippet below, we can quickly confirm that the Server is answering SMTP connections on port 25; it allows connections over TLSv1.3 and has a valid Cert. This can enable you to rule out connectivity issues from other servers without having one available.

If any apparent issues are found for the Receiving Server, you will want to Contact the Recipient to Address the issue.

Test Ping from Connect Server to Recipient Server

If the Domain connectivity is confirmed to work well using the tests above, this indicates that this is not impacting all Mail Servers. To verify whether there is a proper network path between your Server and theirs, you can perform a simple PING test.

1. Connect to the Kerio Connect Host Server directly.
2. Access the Terminal (or CMD/PowerShell Console).
3. Execute the following command:
   1. $ ping <ip_address_of_receiving_server>
   2. Note: You can collect this from the checkTLS.com results above, if necessary.
4. Confirm that you see no lost packets or “Refused Connections.”
   1. 

If you can get a response, this indicates that general network traffic is open between the two servers. If you encounter any issues, this may mean some block (such as a firewall) is preventing the connection.

Test Ping from Connect Server to Neutral Server

If you encounter issues with the previous ping test, you can rule out network route issues on your end by performing the same test to a neutral server (or two), such as Google. This can help confirm that the previous test was not a result of a block on your end. You can repeat the steps above, replacing the IP address with your chosen neutral Server. It is best to select a “Known Good” server.

1. Connect to the Kerio Connect Host Server directly.
2. Access the Terminal (or CMD/PowerShell Console).
3. Execute the following command:
   1. $ ping <neutral_server_ip_or_domain>
   2. Example:
      1. $ ping google.com
4. As before, confirm that you see no lost packets or “Refused Connections.”

If you continue to see issues, this may indicate that your Middleware (Firewall, Antivirus, Antispam) within your network is blocking traffic leaving your Server. It is advised that you check the settings to confirm that your Server is not restricted.

Test SMTP via Telnet

While similar to the previous Ping tests, using Telnet (or an alternative) can be a more direct verification that traffic between your Server and the recipient is allowed over SMTP (port 25).

Note: If your Kerio Connect server is hosted on a macOS system, you may not have access to Telnet and can use a similar command “nc” for this purpose.

Similarly, some Windows Servers may not have this utility installed. You can reference Microsoft’s documentation for installing this or use a 3rd-party Terminal Emulator such as Putty.

1. Connect to the Kerio Connect Host Server directly.
2. Access the Terminal (or CMD/PowerShell Console).
3. Execute the following command:
   1. $ telnet <receiving_server_ip_or_domain> 25
   2. $ nc -vz <receiving_server_ip_or_domain> 25
   3. Examples:
      1. 
      2. 
4. Verify that the session is successful over port 25.
   1. Note: Depending on your chosen CLI utility, the exact response will vary (as seen above); however, you are looking for either a “connection succeeded” or the Server response “220 SMTP/ESMTP Ready.”

If you run into trouble with this test, the most common issue will be an issue with the firewall blocking SMTP traffic.

Check Firewall/AV Settings on the Connect Host Server/Network

If you consistently see issues with the previous tests, this may be indicating an issue with your middleware configuration preventing traffic from leaving or reaching your Server. Verify that you have opened your firewall to the Kerio Connect services as shown within Securing Kerio Connect.

If you are not familiar with the steps to do so or traffic is still not flowing out of your network, please get in touch with your IT Department directly to assist with this check. 

Enable Additional Logs and Simplify Test Scenario

Once you have verified that the receiving Server can establish a connection with your Server over port 25 via the command line, this often indicates that some component of your SMTP or Client configuration may be responsible for the issues you are seeing.

To help further isolate this, you can potentially enable additional Debug Logs based on your findings thus far. If you see signs of SSL/TLS or DNS records being a factor, some examples of useful debug messages might be:

• Network Connections and SSL
• SPF Record Lookup
• User Authentication
• DNS Resolver

Regardless of whether you enable new messages, we suggest simplifying the SMTP Configuration. Some examples of this are listed below, but the exact methods taken will depend on the existing configuration:

1. Use Webmail directly to rule out Email Client issues.
2. Do not use an external gateway(Relay) to rule out problems with the Relay.
3. Send plaintext emails (if previous tests included complex email signatures, footers, etc.)

If the simplified email is delivered, you can compare the differences to help correct the issue.

Contact IT Department to Correct

If you encounter issues verifying the middleware or find that the traffic is not flowing out from the Server, please get in touch with your IT Department to further troubleshoot the problem. 

Please note that troubleshooting your network is outside of the Kerio Connect Support scope, and any analysis should be performed directly by your internal teams. Their main focus should be on confirming wherein transport the connection fails. Below are some valuable considerations:

• Does the connection reach your Edge Servers?
• Do you have multi-layer/tier translations or a DMZ that might be filtering the connection?
• Beyond the firewall, do you have other middleware that might be having an impact? (Anti-Spam, Anti-Virus, or additional IPS)

Analyze SMTP Conversation

Suppose you see signs that the connection is being closed, or your simplified test continues to show issues with sending/delivery to the recipient server. In that case, the next step will be to dig into the SMTP Conversation itself. You can review SMTP Conversations - Concept Article for general guidance on this process. The most important details to confirm are the Status/Response codes generated from your test reproductions. 

In particular, verify whether or not you see a “2. XX” Status code within the Queue Processing entries for the failed delivery. These indicate that your Server properly handled the transaction, and any further issues are isolated to the Recipient Server:

If you identify any other Response/Status codes within the SMTP conversation, you can Check for Known Status Issues.

Compare Configuration Differences to Correct Issue

If you find that the email is successfully sent and delivered after simplifying your test scenario, the next step will be one-by-one returning the adjustments to their previous setting. You can identify which change was responsible for the issue and take the necessary actions to analyze or correct the problem. 

Check for Known Status Issues

While there are many potential Status combinations outlined within Enhanced Mail System Status Codes (RFC3463), most of these have become relatively well documented over the years. We have collected the most common entries within SMTP Conversations- Concept Article. Still, you can also check the RFC definition document directly to confirm the most likely causes for the cited errors. 

It is suggested that you run a search within the Kerio Connect Help Center first to verify any product-specific solutions identified. If none is identified, there are often authoritative sources online that can provide some insight into the Status and Response code combinations you encounter. 

If you encounter issues identifying, understanding, or addressing the Status code, please open a Support Ticket and provide all of the logging and testing details that you have collected for further analysis. In addition, please include a copy of your Support Information File.

Contact Recipient to Address

In a large number of cases, issues with outbound email delivery cannot be solved on the sender’s end, as the problem is isolated to factors outside of your control. In these situations, the best course of action is to contact the recipient directly and share any details you have collected from your testing to help them resolve the trouble.

Further, they can potentially provide you with an alternate form of contact while correcting their issue.