SMTP diagnostic sends test mail, wont send real mail

As a test, can you completely disable any anti-virus, firewall, proxy or VPN, then try send again. Sometimes even restarting your router may resolve this.

Hi Gary,

Same error

09:58:54.639|05B|   Exception: MailClient.Accounts.SocketException: Sending messages failed due to the following reason: 
09:58:54.639|05B|       "Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.."
09:58:54.639|05B|      at MailClient.Protocols.Smtp.SmtpSendCommand.Execute(WorkerStatus status)
09:58:54.639|05B|      at MailClient.Commands.Command.Process(WorkerStatus status)
09:58:54.639|056|   AccountBase.ChangeOnlineState : State changed to OFFLINE due BrokenConnection

Just to confirm:

  • I have turned off windows firewall on domain, public, private
  • I do not have a VPN connection active
  • I am using Windows Defender and have deactivated Realtime Monitoring
  • I have restarted router as well

It could be a settings or server issue.

To check the settings, go to Menu > Accounts and click on the SMTP tab for the account. The port and security policy are specific pairs, so should be one of the following:

Port 587 = Force usage of SSL/TLS
Port 465 = Use SSL/TLS on special port (legacy)
Port 25 = Use SSL/TLS if available

Click on Save & Close after making any changes.

Hi Gary,

I have tried all of them, the diagnostics worked on 465 Legacy and Use if available, couldnt get it to work with Forcing usage.

The host recommends SSL/TLS and indicates that port should be used, here is their provided information (with personal bits blurred):

The test mail sends fine and diagnostics indicate it works, the only thing that is different really is the test email is tiny, the real email im trying to send is a forward chain which is listed as 91kb in size and has some images in there etc, so unsure if that complicates things in some way.

I have just tried sending while on a VPN connection to see if that does anything different but it gives same error, but I can see the local ip address its using for me is now the VPN ip address in the logs not my local one, so while it still doesnt solve the problem it at least is another scenario tested and not working.

The thing I find odd is that it can send the test messages, and its getting up to the same send point after the handshaking etc. I am wondering if maybe there is some cert issue or something but its not being bubbled up. Although if the test email works I imagine it cant be a cert issue.

If you can recommend any other things to try I am happy to give it a go, but I can send from this account using other email clients (not open when I try using em client), its just em client that seems to have problems, but if there is any other debug information output anywhere or if any of the testers/devs in the business want me to setup a temporary account for them to try and use to see if they get other errors im more than happy to set that up, as I would really like to buy a pro license for this, but if I cant send emails then there is no point.

I found this post which is the same issue I have with same provider I am using, I get that maybe their SMTP setup is rubbish, but it works with other clients so it seems like emClient should have some way to work around this, be it an explicit timeout override or something else.

You can see in the initial error logs, and pretty much anyone elses error logs that it waits 30 seconds from the send to timing out, and I imagine other email clients just wait longer. I guess regardless if emclient cant support slow email servers I cant use it :frowning: as other clients work with it, and I don’t understand why an explicit override value could not be provided in the UI if someone wants to allow for longer timeout durations.

This is a grey area but I have looked through some of your source code and you do seem to have advancedParameters which allow you to override the ConnectionTimeout otherwise it defaults the server.SendTimeout to 30000 ms (30 seconds) and uses this value. This lower level logic can be found within the SmtpSendCommand class.

So is it just a case that this was never exposed in the UI? as people are complaining about this as far back as 2017 and it seems a simple enough change to propagate this value up to the UI in some way so baffled as to why its not been done.

I found this post which is the same issue I have with same provider I am using, I get that maybe their SMTP setup is rubbish, but it works with other clients so it seems like emClient should have some way to work around this, be it an explicit timeout override or something else.

If the SMTP provider server has constant or random timeout issues with mail clients (like Tsohost appears to have alot of the time), then it’s up to the host technical support to fix that. Or alternatively you have to use a different SMTP mail server if they carnt resolve the problem.

Putting in a SMTP timeout option within a mail client is no guarantee that would 100% fix that problem (even if it was implemented). It’s a band-aid solution. You could be constantly adjusting the timeout setting everyday depending on how bad the SMTP mail server was at any given time through the day. Needs a proper SMTP server fix

They wont though, and I understand the angle you are coming from, where really its the SMTP server not being fast enough at responding/accepting payloads BUT at the same time, what if we legitimately have a large file we want to send, even a fast server may take longer than 30 seconds to send causing it to timeout.

However you spin this, other email clients work around this issue differently, and some offer configurable values to allow you as the user to decide how long is too long, here we have no option to do so, and the smtp provider isnt going to change its infrastructure because I tell them emclient only gives them a 30 second window to process a send request.

I would LOVE to use this product as it does everything I want, but unfortunately right now its more faff to change my entire web/mail host provider than it is to move off emclient to another app, but its a shame as there is literally no technical reason why they could not expose this value and potentially have had new customers (even if its only a handful) and avoided a lot of these same sort of posts where peoples SMTP calls timeout, which also costs support time etc.

That is not what the timeout is about. It is not the time it takes to upload the message, but rather the time the server takes to respond when communicating with it. Normally the server should respond in a few milliseconds, so you can understand how extraordinarily long 30 seconds is to go without a response.


Ah right, either way I appreciate 30 seconds is a totally crazy length of time to take to respond, but unfortunately none of that matters if I cant use that server with this client and other clients work.

Either the app developers make the timeout configurable, or somehow tso host increase their timeout, I cant see either happening.

There is a 3rd option that there is something causing the timeout on the server side, which other apps don’t have, be it a cert resolution error or some DNS thing, who knows…

I send emails using that server from android, desktop etc and none of them have an issue and while I dont see debug logs etc they seem to send within a few seconds (I appreciate behind the scenes it may be taking much longer to actually send) but its only since using emclient that I have seen this issue.

In a last ditch attempt to try and solve this I have asked TSOHost (the mail provider) if they can check any logs their side to see if there is any reason why its timing out, and they couldnt see anything however they did notice there were some DNS records that were incorrect, so they have updated them and im waiting to see if that fixes it.

I am unconvinced as other clients worked fine before they changed DNS records, but will report back after ive given it a few hours to propagate.

Granted its not been the full 24-48 hours yet (its about 18 hours as of writing) but I had an urgent mail to send, tried again on this, wouldn’t send, went on a competitors email client (which I am trying to move away from), sent right away.

Im assuming whatever DNS changes they have made wont fix the issues im facing with emClient, can anyone confirm do the devs check this forum? as I would be more than willing to work with the devs to dig deeper into whats causing the issue and trying to solve/mitigate it, as im not the only one over the years whos suffering from it and am more than happy to pay for a pro license (still on my free trial) if it means a developer can treat it as an issue and work with me to resolve it.

sábado 18 noviembre 2023 :: 1415hrs (UTC +0100)

Hey @Grofit

I am intrigued with your issue as I see that you have given your Port addresses etc but you have grayed out your actual SMTP host address, it would be helpful to have this when attempting to resolve your issue. Also do you have your own Domain?


¡Los mejores desde Valencia y mantente a salvo!

[email protected]

Hablo español, luego portugués, inglés, francés y alemán
con conocimiento de varios otros idiomas.

I just left my local IP address in the logs as its just a LAN IP so no one could do anything malicious with it. In terms of the SMTP host I wouldn’t want to put its host name or IP address on here but I am happy to pm you the details if you wish.

I do have my own domain name but like a lot of Web hosts these days the actual SMTP server address is a separate url which is a custom guid subdomain on their own domain i.e

These settings work fine on other email clients for send/receive, on here it receives fine but only does a diagnostic send, I tried sending a minimal email from this to another account via em client and even a message saying “hello” won’t send, so it makes me think the code behind the scenes somehow sends the test email a different way to how the real SMTP send is processed.

sábado 18 noviembre 2023 :: 1624hrs (UTC +0100)

Hey @Grofit

OK I note what you say therefore I can not help you further.

¡Buena suerte!


¡Los mejores desde Valencia y mantente a salvo!

[email protected]

Hablo español, luego portugués, inglés, francés y alemán
con conocimiento de varios otros idiomas.

I don’t really know what you would be able to do to help diagnose with the SMTP host name other than potentially look at DNS records for that domain, I am more than happy to do DNS lookups and provide information back if thats what you would be wanting to see to help diagnose further.


If you purchase eM Client you can then login and lodge a support request via the Pro support page.. An engineer will then be assigned to you to troubleshoot this issue. You can then send in logs etc as they advise.

There is also a 30 day money back guarantee if for some reason this issue cannot be resolved.

We can only give limited user help on this free community forum.


So after speaking to support on both sides I am able to somewhat work around.

The host of the SMTP server tells me there is nothing erroneous in their logs or issues effecting my account/server and they have tested with various other email clients and have no such issues.

Support on EM Client have confirmed they also get the same issues as me, and after giving them a test account to diagnose further they indicate the SMTP host disconnects frequently and takes longer than 30 seconds to respond when it does work.

So while this isnt a solution and there is still a problem, there was one MAJOR breakthrough from the EM Client support which was how to extend the timeout for SMTP requests. To do this you can go to your account settings and then Advanced Options at the bottom of the page and in the Parameters field enter the following:

--smtp-timeout 3600 --smtp-initial-timeout 3600

I think 3600 here is the value in seconds, so we are saying wait 1 hour (60 seconds * 60), so you can set this to whatever interval you want, I have not done any in depth evaluation of the timeouts but I can see now that it is not erroring out as it did before, as the logs end with this now:

09:33:46.832|02E| SMTP S: 250 Accepted
09:33:46.832|02E| SMTP C: DATA
09:33:46.867|02E| SMTP S: 354 Enter message, ending with “.” on a line by itself
09:33:46.871|02E| SMTP C:
09:33:46.871|02E| SMTP C: .
09:34:16.945|02E| SMTP S: 250 OK id=1r665k-00GLOq-A1
09:34:16.947|02E| SMTP C: QUIT

It seemed to only take 30 seconds ironically to accept the email, but I could not find any information in the EM Client docs/articles about how to extend the timeout, so I hope this helps others solve/workaround the problem.

1 Like

Just a follow up email as I asked the provider to give more information in terms of expected service levels with their packages, as I’m only on a shared hosted provider package so its a shared SMTP server, and they said on average that server could take up to a minute to respond and that is apparently pretty normal for shared web hosting SMTP servers, so setting the timeout to about 120 should give it 4 mins to time out, but thought this may be useful information for other users who have similar issues on shared webhost packages.