IMAP / SMTP slow performance on Office 365 (10sec idle time before receiving/sending data) RRS feed

  • Question

  • Hi,

    I am using O365 with IMAP and SMTP access.

    I notice that anytime I have to connect through IMAP or anytime I have to send an email it takes ages to connect (exactly 10sec).

    It is very easy to reproduce the issue and it is always 10sec before my email client is actually moving data.

    After theses 10sec the bytes transfer is good, but I always have to wait this "idle" time and I don't know why.

    It happens just after the TLS certificate negociation and it is very easy to see it on a packet capture.

    Any idea what can cause this issue?

    Tested on mutt and Thunderbird, on two different computers with the exact same symptom for IMAP sync or SMTP.

    many thanks
    Monday, October 10, 2016 5:45 PM

All replies

  • Hi,

    If you are using the Internet mail account (Gmail, Hotmail etc.), please go to your webmail and check the IMAP settings for your account. Make sure the Port and Certificate are configured correctly in Outlook client.

    Additionally, please go to Send/Receive tab, in the Send/receive group, click Send/Receive Groups > Define Send/Receive Groups, make sure your account is not set any send/receive schedule.

    Also disable any third-party antivirus programs in your computer, confirm if the issue persists.


    Winnie Liang

    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, October 11, 2016 10:42 AM
  • Hi Winnie,

    Thanks for your reply, perhaps I was not clear enough on my explanation.

    I forgot to mention that I am not using an Outlook client as I am on Linux (so no antivirus as well).

    My client is under Linux and I am using Thunderbird / mutt with the same symptoms on from two different computers and I am connecting through IMAPs/SMTPs to O365 account.

    Very easy to reproduce, as everytime I connect to synchronize folder through IMAPs or send an email through SMTPs I got this 10sec straight after the TLS certificat negociation before receiving some data from O365 server... and this is what I am trying to figure out...


    Tuesday, October 11, 2016 12:59 PM
  • I made some tests and now I have a better idea from where the delay is coming from and in which phase of SMTP.

    I did a packet capture and correlate with verbose logging on my side and it is definitely the login phase which is very slow.

    Here on the screenshot the login is sent packet # 261 and immediately ACK from the server packet # 262 with no delay (131ms), then there are 14 seconds(between packet #262 to #263) before the server is sending the Authentication Successful...

    Is there a better way to tune this phase from the server or client side ?

    Anyone who are using Office365 through IMAP & SMTP experiment the same issue ?

    In fact it is very annoying as on every mail sent (and also on IMAPS every time they is a synchronization) I got more than 10 seconds delay and then everything is sent / synchronized smoothly..

    Many thanks

    <-- 220 AM3PR05CA0073.outlook.office365.com Microsoft ESMTP MAIL Service ready at Thu, 20 Oct 2016 14:42:38 +0000
    --> EHLO localhost
    <-- 250-AM3PR05CA0073.outlook.office365.com Hello []
    <-- 250-SIZE 157286400
    <-- 250-PIPELINING
    <-- 250-DSN
    <-- 250-STARTTLS
    <-- 250-8BITMIME
    <-- 250-BINARYMIME
    <-- 250 CHUNKING
    --> STARTTLS
    <-- 220 2.0.0 SMTP server ready
    TLS certificate information:
            Common Name: outlook.com
            Organization: Microsoft Corporation
            Organizational unit: Microsoft Corporation
            Locality: Redmond
            State or Province: WA
            Country: US
            Common Name: Microsoft IT SSL SHA2
            Organization: Microsoft Corporation
            Organizational unit: Microsoft IT
            Locality: Redmond
            State or Province: Washington
            Country: US
            Activation time: Wed 14 Oct 2015 12:20:04 AM CEST
            Expiration time: Fri 13 Oct 2017 12:20:04 AM CEST
            SHA256: A1:C0:26:65:59:14:1B:2E:70:D6:C6:5E:15:54:B2:16:AC:7B:D3:B4:9F:5F:B0:6F:C8:4A:2C:4C:B9:64:EF:7A
            SHA1 (deprecated): A0:47:6C:0C:30:34:7A:7A:15:9A:9F:F5:0B:CD:BC:84:BD:D3:D1:66
    --> EHLO localhost
    <-- 250-AM3PR05CA0073.outlook.office365.com Hello []
    <-- 250-SIZE 157286400
    <-- 250-PIPELINING
    <-- 250-DSN
    <-- 250-AUTH LOGIN
    <-- 250-8BITMIME
    <-- 250-BINARYMIME
    <-- 250 CHUNKING
    --> AUTH LOGIN
    <-- 334 **********
    --> ****************************
    <-- 334 **********
    --> ****************
    <-- 235 2.7.0 Authentication successful target host CY4PR18MB1064.namprd18.prod.outlook.com
    --> MAIL FROM:<*****@v******.***>
    --> RCPT TO:<******@******.**>
    --> DATA
    <-- 250 2.1.0 Sender OK
    <-- 250 2.1.5 Recipient OK
    <-- 354 Start mail input; end with <CRLF>.<CRLF>
    --> From: ***********@**********.***
    --> Date: Thu, 20 Oct 2016 16:41:41 +0200
    --> hello there
    --> .
    <-- 250 2.6.0 --> QUIT
    <-- 221 2.0.0 Service closing transmission channel

    • Edited by 2Belette Saturday, October 22, 2016 8:42 PM
    Thursday, October 20, 2016 3:51 PM
  • Same issue for me, Thunderbird under Windows and this is really annoying. Sending an email takes ages.

    One possibility is that it is a voluntary delay by MS to force users to adopt Outlook (who strangely does not suffer that issue).

    My company has 50 users under Office 365 and mail sending is a serious problem. I have 20 years of email accessible within seconds thanks to Thunderbird, that's something Outlook can't offer. So I won't change to Outlook just because that pleases Microsoft...

    If that defect is not a voluntary action by Microsoft, then please fix that issue!


    Wednesday, January 25, 2017 6:39 PM
  • Same problem for us. We are using Office365 E3 and imap as well as smtp connections hang / idle during the login process for 15-20 seconds.

    The service is hardly usable in the current condition.

    Haven't found a solution yet. Any help or hints highly appreciated.


    Thursday, January 26, 2017 10:24 PM
  • would be nice to have an official answer from Microsoft as proposing this service is not very functional..

    if the objective is to lower some brut force attack or so even I don't think it would make a huge difference passing from 10 sec to 5sec. This would keep protecting Microsoft servers against attack and would give end user experience much better as 5 sec is acceptable but 10 is too much...

    Wednesday, February 1, 2017 10:24 AM
  • Honestly, I don't think they care, if they did they would have been working to address the issue a long time ago as this isn't anything new.  Granted I do believe that the service is getting worse now, most likely do to either volume or additional throttling they have in place.  As someone who uses a non-microsoft client app, I routinely have hit the retry or resend option a number of times before it's successful.

    I also use gmail and yahoo and both of their smtp relays seem to handle the loads just fine without any delays using the same client (e.g. Thunderbird, Mac MailApp, ...).

    Monday, February 20, 2017 1:00 PM
  • 9 months since the last post, and I'm still suffering from annoying delays with SMTP and IMAP. Problem  is recurring about once a month, and after a day or so it's usually back to normal.

    But it's not surprising, since EVERYTHING related to Azure or Exchange online is always painfully slow.



    Wednesday, November 29, 2017 8:01 AM
  • Just came across this when testing to move from GoDaddy's Workspace Email to O365. 

    GoDaddy Workspace which is a decade old product sends in 1.4 seconds on average and this is a basic email with Test as the message.

    Outlook365.com sends in 6.26 seconds on average.

    I was testing using a simple CDO.Message test loop and sending 10 times over.  This was creating the new CDO.Message each time.  So results are.

    GoDaddy Workspace = 14.39 seconds to send 10 messages

    Outlook365.com = 62.67 seconds to send 10 messages

    Now I moved the loop for testing to leave the CDO.Message object valid and just loop around the send command and it's faster but still 3 times slower than what the GoDaddy programmers could do a decade ago.

    GoDaddy Workspace = 6.22 seconds to send 10 messages

    Outlook365.com = 18.65 seconds to send 10 messages

    It honestly doesn't surprise me.  The Outlook.com team has so many major bugs in it since release almost 2 years ago.  2 years later you still can't view or download command file types like PDF unless your Primary Alias is your @outlook.com email address.  You also can't filter messages coming into your main inbox from connected accounts.

    The decade old Hotmail.com was 100 times better and more reliable also.  Granted they have added some nice features and it's great to access it from multiple devices but MICROSOFT YOU HAVE TO GET THE BASICS CORRECT FIRST!

    • Edited by RMcManamy Saturday, December 2, 2017 3:14 PM
    Saturday, December 2, 2017 3:11 PM
  • Same problem for us......

    We are using Office365 with Thunderbird and we're suffering from annoying delays (10/20 seconds) with SMTP and IMAP!

    Monday, March 26, 2018 3:11 PM
  • The university where I work changed all e-mails to 365 and it has been a disaster in terms of how slow the accounts are to use with Thunderbird  via IMAP. Bordearline unusable! It's incredible how Microsoft keeps this running this way. I use Thunderbird in several computers and regardless I am in the university network or elsewhere, it's close to impossible to work with my account. I have the e-mail of our research centre, which is managed by our own server and it works at the sleep of light with Thunderbird, while the MS 365 e-mail account takes ages to move an e-mail between folders, donloading or sending SMTP e-mails. When is Microsoft going to fix this and provide a usable e-mail? We have thousand of people (academics, researchers, students, and staff etc) wasting hours per week with low productivity because of these 365 e-mail accounts, with everyone with e-mail clients saying it's unbelievable slow to do anything and because its our official e-mail at the university we cannot do away with it.
    Tuesday, November 27, 2018 3:34 AM
  • Whilst it does not fix the SMTP login issue, I found that reducing the number of IMAP connections to 1 fixed the other sync issues. See the instructions at the very bottom of this page:


    Now Thunderbird is at least usable.
    Monday, November 11, 2019 5:39 PM