• I cleared the records for that domain. Let me know if that fixes the issue on your end.

    The data can be influenced, but by the Outlook client itself. There is currently no way for you to clear the data, it has to go through our support for manual changes.

    Tuesday, August 29, 2017 9:25 PM

All replies

  • Just out of curious - why you'd like to debug this within Outlook?

    Better to share the detailed steps with us here.

    Monday, August 28, 2017 10:31 AM
  • Hello Aleksander,

    This service is not a third party, it's a Microsoft service helping with account configuration. The issue might be that it recorded the test settings and is serving these ones, therefore breaking the final settings.

    If you let me know the domain I can remove the test settings from the service's records.

    Monday, August 28, 2017 8:08 PM
  • Deleted
    Tuesday, August 29, 2017 5:53 AM
  • I cleared the records for that domain. Let me know if that fixes the issue on your end.

    The data can be influenced, but by the Outlook client itself. There is currently no way for you to clear the data, it has to go through our support for manual changes.

    Tuesday, August 29, 2017 9:25 PM
  • Deleted
    Wednesday, August 30, 2017 6:45 AM
  • Deleted
    Wednesday, August 30, 2017 7:16 AM
  • If the Outlook client proposes wrong settings, you have the option to override them with manual ones to connect your mailbox. When you do that, Outlook contacts the service to report the error and try to correct the recorded data.

    So the action to correct the recorded data is indirect, it's the fact that you connect your mailbox to Outlook with manual settings that will affect the recorded data.

    Wednesday, August 30, 2017 3:09 PM
  • Apologies for the cross post but I am hoping you can help. We've tried quite a few other support channels but don't seem to be getting anywhere.

    We are having a very similar issue with one of our domains. It used to be based with Google but is now Office 365. However the Microsoft Outlook (a.k.a acompli) app refuses to update its autodiscover process to recognise this fact. A POST GET request (replicating what the app does) to the acompli servers immediately returns Google mail servers for our domain, whereas the answer should now be office 365. We are able to press 'NOT Google' and set up manually, but this is a 27,000 user domain and naturally this is causing a few issues and confusion as we have moved away from Google. We moved MX records over 14 days ago.

    You mentioned above that you cleared out the records for Aleksander and I wondered if you would be able to advise which MS team I might be able to contact to achieve the same for our domain.

    Many Thanks, Mark

    • Edited by Mark Needham Wednesday, September 20, 2017 8:28 PM
    Wednesday, September 20, 2017 8:14 PM
  • Hi Mark,

    Did you figure out which MS Team to contact? We're having the exact same problem (migrated from Google to O365, Outlook apps still autodetect Google).


    Thursday, September 28, 2017 2:33 AM
  • Hi Matt,

    Sadly not really. Although we are still trying from various channels.

    The only one I am currently getting a little joy with is back with "in-app" support. I have sent them the POST GET request we traced on the app (see below). I advised them that the app is doing this first before Exchange autodiscover is ever asked to do anything and that I can repeat the problem, time after time (on hundreds of devices, so please don't ask me to re-install!). So, in light of this proof, can they advise what their autodetect process is doing and why won't it update itself. This service is chat only, but they seemed to take this on-board at second attempt and have agreed to escalate with a 24-48 hr turn around.

    Other things tried:

    Premier Support - Not interested in supporting this app

    Account Managers(s) - Escalation via our support channels has so far not fed any further info back. Still waiting on that.

    365 Support - Still with them to an extent, although wanted to insist on looking at our Exchange hybrid and ADFS servers. I sent them a network trace with our server IP's and asked to them explain why the problem occurs before our servers even get asked a question. Also not really interested in supporting this app, but keen on ruling 365 services out. 365 currently want more Fiddler traces, which is actually not that easy from a mobile device. We have resorted to using Android emulators.

    My own testing: In short everything about our environment works, autodiscover, adfs etc. Every other process works other than anything that makes a request to I've done the MS auto discover tests (pointless in some ways as the app never asks it), SSO tests tried multiple others apps and clients. All is fine apart from this.

    If I have any advice it would be to repeat my test below and should you get 'Google' back too, raise it in-app support, but make it crystal clear the problem is many devices. I will update this post when / if I get a resolution. Let me know how you get on. I will too.


    I just used the ARC plug-in for Chrome as a method of repeating this test. Just change the X-Email header to your domain.

    GET,outlook,yahoo,google,icloud&protocols=eas,imap,smtp,rest-cloud HTTP/1.1

    Accept-Language: en_GB

    X-Email: bob@your.domain

    User-Agent: Outlook-Android/ Dalvik/2.1.0 (Linux; U; Android 6.0.1; D5803 Build/23.5.A.1.291)


    Connection: Keep-Alive

    Accept-Encoding: gzip

    Thursday, September 28, 2017 9:04 AM
  • Hi Mark,

    Sorry for the late reply, I didn’t get a notification of this thread for some reason.

    I believe your issue is now fixed. I'm working on a change to avoid this situation in the future.

    Thanks for reporting!

    Thursday, September 28, 2017 3:02 PM
  • Hey Matt,

    I'm working on a change that would most likely solve your issue, it should be out next week at the latest.

    I can do a manual change directly in the meantime if you prefer, I just need the domain impacted.Also, out of curiosity, how long ago was the migration?

    Thursday, September 28, 2017 3:04 PM
  • Hi Pierre,

    Thanks for picking this up. I've tried a few devices (inc app re-install just in case) and am still being taken to Google as initial discovery.

    However I've just done a new POST request against a few of your servers and can see that it comes up office365. Is it possible the change will take a while to take effect?



    Thursday, September 28, 2017 4:47 PM
  • Yes, there is some caching per server cluster. I guess the devices are fixed on a cluster with the old value cached, and your requests are hitting a cluster that didn’t have the legacy value cached. All cached data should be cleared in max 6 hours.
    Thursday, September 28, 2017 4:52 PM
  • Thanks Pierre,

    Much appreciated. I'll check back with a few devices after that time period and let you know how it goes.

    Kind Rgds,


    Thursday, September 28, 2017 4:54 PM
  • Hi Pierre,

    Thanks so much for looking into this! The domain is We can wait for the fix to be pushed out (next week is break for us anyway) but if you have a chance to do a manual change we'll test it right away.

    We switched our MX records over to Office 365 on August 9.


    Friday, September 29, 2017 1:14 AM
  • Hey Matt,

    The change has been deployed, let me know if you still encounter the issue.

    Friday, September 29, 2017 6:49 PM
  • Can you please clear from this horrible service whose only use seems to be to break email auto configuration?   It has been broken since it moved off of GoDaddy in February.  I watched the communication with outlook via mitmproxy and the only communication with this was to get the incorrect information.  I tried forcing it to the correct location and logging into a profile numerous times and outlook never gave feedback to the "service".
    Monday, October 9, 2017 9:59 PM
  • Sorry for the inconvenience. We're aware of the service's shortcomings and are actively working to improve it.

    I've published an update today that might fix your issue, let me know how it goes.

    Wednesday, October 11, 2017 10:40 PM
  • Hello I am Robert and working for a CSP in Germany,

    since a few weeks we have some problems with autodiscover. It seems that the autodisocver service try to use

    cached outdated infromations. I opened a premier case ticket a few weeks ago and deleting cache from 

    prod-nam-autodetect.acompli....... resolved our problem. Microsoft suggest me to post in this forum to

    delete other cached informations if the error happend again for other customers.

    So please delete cached Informations for ""

    Kind Regards


    Wednesday, November 1, 2017 7:57 AM
  • @Pierre-Elie Fauche I have the same issue with which I migrated from G suite to O365 over a week ago Acompli still believes the domain is with Google, can you clear the cache thanks
    Wednesday, December 20, 2017 3:06 AM
  • Hello James, it should be fixed. Sorry for the inconvenience.

    Wednesday, December 20, 2017 9:19 PM
  • Thanks Pierre-Elie

    Looks to be working on Outlook on Mac, but the iOS app still thinks it's G-Suite :(

    Thursday, December 21, 2017 12:06 AM
  • That might happen depending on the server you hit and their cache. It should be propagated everywhere in maximum 4 hours.
    Thursday, December 21, 2017 12:09 AM
  • Ah makes sense. Thanks very much for doing that for me, appreciate it.

    Will try again tomorrow, the fact I tried won’t have cached the wrong value again correct?

    Have a good holiday!

    Thanks, James

    • Edited by James Leonard Thursday, December 21, 2017 8:59 AM fix formatting
    Thursday, December 21, 2017 12:44 AM
  • And it's all working now, on iOS as well

    Thanks heaps Pierre-Elie

    Thursday, December 21, 2017 11:39 PM
  • You're very welcome!
    Thursday, December 21, 2017 11:42 PM
  • Hey guys!

    I have the same issu (company changed to other isp)

    I did a good login with the right servers (manually edited) and found out, that their is a feedback mechanism for the MS-Servers. So the server should have the right serverdata now.

    How long will it take, that your servers are delivering this data?

    Thursday, December 28, 2017 2:17 PM
  • Hi,

    The feedbacks are not used directly (to avoid risks of poisoning), but they should trigger a cache refresh on the next login for the domain.

    In any case cache is refreshed after a week.

    I can help more with the domain name.

    Thursday, December 28, 2017 3:26 PM
  • Domainname ist Thank you!

    If it is possible I would like if you just disable the function for this domain. I have a well configured autodiscover running.

    Thursday, December 28, 2017 6:34 PM
  • Hello?
    Thursday, January 4, 2018 9:27 PM
  • Sorry for the late reply, I wanted to look at what was happening exactly.

    It should use your configured autodiscover now.

    Thursday, January 4, 2018 9:54 PM
  • Hello,

    Can you assist in performing this fix for

    We have an issue with the Outlook mobile app and Outlook 2016. It's redirecting to Google. We have an Exchange Hybrid.


    • Edited by Darrell ETG Monday, January 8, 2018 9:44 PM
    Monday, January 8, 2018 9:12 PM
  • Hi Darrell,

    It should be fixed now. The system got confused because your MX records seem to still be pointing towards Google.

    Wednesday, January 10, 2018 6:30 PM
  • This thread isn't actively monitored, so for a prompt handling of your request please contact Office Support directly: (with mention of the "Outlook Mobile AutoDetect Service")
    Friday, January 12, 2018 7:46 PM
  • Thank you!

    Do you know what we can reference when reporting this? Was a very long phone call with Microsoft when I tried previously.

    Saturday, January 13, 2018 1:34 AM
  • Yes, that's actually a great point: you can reference the Outlook Mobile AutoDetect service.


    Tuesday, January 16, 2018 4:03 PM
  • Hi Pierre-Elie,

    Our company have the same issue,  Could you help us to clear  these domain names?



    Friday, February 9, 2018 1:52 AM
  • Hi Tim,

    It should be fixed, sorry for the inconvenience.

    Friday, February 9, 2018 5:25 PM
  • Hi Pierre-Elie,

    Is there any way to prevent this situation in the future?

    We set our  MX record to Google for using the google email relay service to help us spam the junk mails.

    I think this might be the reason, MS service recognized our email services as a Gmail account, even if we deployed the autodiscover service to address the correct email servers settings. 

    in the future when we create a new domain, if we deploy the autodiscover services first, then change our MX record to Google later, will this kind of issues happen again?

    if yes, what should we do to prevent it?

    Thank you so much 

    • Edited by Jude Zhu Sunday, February 11, 2018 12:53 AM
    Sunday, February 11, 2018 12:52 AM
  • Hello,

    i want Clearing these "Service" for my URLs without posting these URLs in public!

    HOW TO?

    Also, what Kind of security desater is going on here?
    Everybody can ask for Clearing this "Service" ok nice please cleare the Service for.

    i never registered for this kind of Service.

    some keywords for searchengine:

    autodiscover problem _autodiscover_ Autodiscover-dns Office 2016 Outlook Password Problem _autodiscover._tcp office Setup wizzard O365 nslookup active Directory Exchange Server email account Office account type selector 

    • Edited by Andy-GER Thursday, February 22, 2018 3:34 PM
    Thursday, February 22, 2018 3:02 PM
  • Hi Pierre-Elie,

    Our company Alcolizer is also having the same issue,  Could you clear our domain. and

    Thank you.


    Monday, April 2, 2018 1:21 PM
  • Hi Pierre-Elie,

    Please clear

    Wednesday, April 11, 2018 8:52 PM
  • Hello Pierre-Elie,

    Can you please clear


    Rohit Hajare

    Thursday, April 19, 2018 10:13 PM
  • This is new Outlook 2016 (365) behavior.

    MS add new autodiscover process called Simplified account creation.
    I don't know mechanism of this, but I think it is combination MX record and configuration on '

    Simplified account creation, is the first autodiscover step.

    If you want bypass it, you can do it by registry :

    Or manually in GUI

    Monday, April 23, 2018 9:29 AM
  • @Pierre-Elie Fauche

    Can you clear ? Thanks!

    Monday, June 4, 2018 1:42 PM
  • Pierre, is there any supportu panel where I can clear data for domain? I'm fighting with Outlook app supportu but they don't want to help.

    Friday, July 6, 2018 10:07 PM
  • Good day

    I've been running around for hours trying to figure out why Outlook 2016 auto discovery is not working correctly.  The testing tools all worked correctly, older versions of Outlook work, including Outlook 2016 prior to the new wizard.  I eventually just started up wireshark and found that Outlook 2016's new wizard was looking at instead of the correct autodiscovery.

    This is a bit of a pain as I'm trying to setup autodiscovery for a server with about 500 domains and they all point to old settings instead of the updated settings.

    How long does this service cache information for?

    Is their any way of clearing the cache without posting on this thread?

    When is the testing tools available going to show that this service has cached data?

    If, for now, you can clear the cache for that would be great, but an answer to the above questions will be much appreciated.

    Best wishes

    Kobus Etsebeth

    Tuesday, July 24, 2018 1:39 PM
  • @ Pierre-Elie Fauche


    Can you clear  Having the same issue as others on this thread.  If there's another way these types of requests need to be made, please let me know.



    Thursday, September 13, 2018 12:27 AM
  • Hi Pierre-Elie,

    Can you remove the following domains :-

    as the settings are pointing to a 3rd party mail filtering service we use

    Many Thanks


    Tuesday, October 2, 2018 8:45 AM

  • @ Pierre-Elie Fauche

    Hello Pierre:

    Can you clear  Having the same issue as others on this thread.



    Thursday, November 8, 2018 9:10 AM
    • Proposed as answer by Jeremy DahlMVP Friday, November 30, 2018 6:54 PM
    Thursday, November 29, 2018 4:52 AM
  • Hello,

    @Pierre-Elie Fauche

    can you please clear the domain



    Friday, December 7, 2018 5:24 PM
  • Hello,

    @Pierre-Elie Fauche

    Could you please clear the domain



    Wednesday, December 19, 2018 8:50 PM
  • Hello Pierre-Elie,

    could you please clear the settings for

    Thanks in advance.


    Wednesday, January 9, 2019 10:14 AM
  • Hello Pierre-Elie,

    Could you please clear the settings for

    Thanks in advance.


    Thursday, February 28, 2019 5:06 PM
  • I cleared the records for that domain. Let me know if that fixes the issue on your end.

    The data can be influenced, but by the Outlook client itself. There is currently no way for you to clear the data, it has to go through our support for manual changes.

    Good Morning,

    I have a problem, I have configured auto discovery in my domains, but after the implementation of microsoft autodetect in the "16.0.6769.2015" version, the Outlook 2016 and mobile Outlook clients have started to return the incorrect SMTP data, returning:
    door 25

    The correct thing was to return:


    door 587

    I've already applied the solution to disable autodetect on the client and by discovery, it returns the correct data. But as many customers are, it is impossible to apply this solution at all.

    Using the fiddler, I saw that a request is made for, it seems to be an api of them, and making the request for them returns wrong:

    curl ",outlook,yahoo,google,icloud&protocols=eas,imap,smtp,rest-cloud" -H "X-Email: test @ domain "

    PS: I already made a knock to disable autodetect, but even so it becomes unfeasible to disable everyone.
    Return from webservice:

    This happens for all domains in my database, because even when configured, when there is a connection difficulty, Outlook tries to reconfigure and pick up the incorrect data.

    {"email": "", "services": [], "protocols": [{"username": "", "protocol": "eas", "autodiscover": "", "validated": false}, {"protocol": "imap", "hostname": "", "port": 993, "encryption": "ssl", "insecure": "invalid_certificate", "validated": false}, {"protocol": "smtp", "hostname": "", "port ": 25," encryption ":" none "," insecure ":" plain "," validated ": false}]}

    Could someone give me a light?
    Thank you very much in advance!
    Wednesday, March 6, 2019 1:03 PM
  • Domain with the same error. Autodetect is not correct
    Friday, May 3, 2019 6:17 AM