IMAP Connectivity Troubleshooting
Last Updated -
What is required for proper IMAP Connectivity with my outbound mail server?
Desk.com needs a clear communication path to send and receive data to and from your IMAP mail server in order to retrieve email. If there is anything hindering that communication, you may receive errors.
What ports do I need to open on my network?
The required ports would be determined by your mail server and network administrators, so you should consult with them to find the proper settings for your inbound mailbox. Ports 143 or 993 are the most commonly used ports, and most IMAP servers have port 143 open by default.
Port 143: If you are using port 143, you should set the Mailbox Type field in the Desk.com Admin to IMAP.
Port 993: If you are using port 993, you are using Secure IMAP and you should set the Mailbox Type field to IMAPS.
Important notes about the Host field
This field must contain the EXTERNAL hostname of your mail server. (i.e.: mail.yourcompany.com and NOT internal.address.yourcompany.com). Please verify with your mail server administrator that the hostname that you are using will work externally on your network. If you are using an IP address, it cannot start with 10. (i.e.: 10.1.1.50) or 192. (i.e.:192.168.1.10) , these are internal IP address ranges.
What are the symptoms of connectivity errors?
- Emails are not being pulled into Desk.com
- Cases are not being created.
- Emails are on the mail server, but not in Desk
- Similar error message to the ones below appearing in your error logs, or on screen in the Admin:
→Last Error: Closed Stream
→Command received in Invalid state.
*** If you are receiving Command received in Invalid state, you may want to view this article as well.
What should I do if have any of these issues?
Troubleshooting email connectivity issues is not an easy task. There could be any number of things wrong. To help isolate the issue, you should run the following email diagnostic tools and gather all of the information possible.
MX Lookup: You can check what the outside world (including Desk.com) see's as the MX Record for your domain at http://www.mxtoolbox.com using their MX Lookup tool. Type in your domain name ie.: mycompany.com (not the full mail server name) to see what the outside world see's as your mail server name. Verify that the hostname or IP returned is what you are using in Desk.com
DNS Lookup: Make sure that there is nothing unusual about your mail servers domain name, and what results are returned by DNS by running this tool http://www.mxtoolbox.com/DNSLookup.aspx
or the Reverse Lookup tool located at http://www.mxtoolbox.com/ReverseLookup.aspx
Port Scan Tool: This tool will validate which ports are open on your mail server, and is located at http://www.mxtoolbox.com/PortScan.aspx. Plug your Host into the field and run a port scan. Verify that the port 143 is open (If using 143 and IMAP).
You can verify that ports are open using TELNET. Please refer to this article for more information:
Was the whitelist (https://support.desk.com/customer/portal/articles/13595-allowing-desk-com-servers-access-to-your-mail-servers) applied to all of the necessary mail servers, front end servers, endpoint devices or applications, spam filtering devices or applications, antivirus applications, firewalls, routers or other network devices? Were the proper exceptions made where required?
I have checked and everything mentioned looks OK, but am still receiving the relay error, now what?
If you feel that you have done everything correctly, and continue to receive errors then you my have missed a device or exception in one of your applications/devices. At this point, it would be highly recommended that you get your email server administrator or network administrators to sniff out the Desk.com whitelist IPs on your network, and locate the failure point. The Desk.com servers will try to send email every minute or two, and the connection attempts should be easily visible in your network and mail server logs. While the Desk.com support team can provide guidance on the potential failure points, the actual configuration is done entirely in you own or your hosting providers network environment.
You may also be interested in this article: