• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue Mail autodiscover doesn't work for Outlook 2019

Liwindo

Basic Pleskian
I've tried for Outlook 2019 on several Windows 10 machines the autodiscover function for imap and pop3 and it doesn't work for me:

1584549109640.png

OS: Ubuntu 18.04.4
Plesk Version: 18.0.25
All custom templates are up-to-date.
All adjustments of How to manage mail autodiscover in Plesk Obsidian? are adjusted for several domains and subscriptions. Doesn't work for any of them. But it works for Thunderbird.

Does anyone else face this issue or has a solution?
 
Could you please provide any your email for checking this issue?
 
I can't get it to work here.

Windows 2019 + Plesk 18.0.25
I have setup a test domainname with SSL configured and autodiscover enabled.
And added a mailbox.

Outlook Office 365
Version 2002 (Build 12527.20278)
This is currently the most recent version

I click in Outlook: File > Add account
I get a popup window and I type the emailaddress of the mailbox.
Then I go to "Advanced Setup" where I need to choose what account i wan to add.
When I click IMAP I need to fill in the server details manually.
 
When you type the emailaddress, then you should click "Connect" (or "Add" button) in the popup, then Outlook asks you to your password.
If it is not happened - Outlook didn't autodiscover your email. Try it again or try it again later.
Outlook 2019/O365 receiving mail settings from his proxy servers (not directly from your domain) and has some lag. Also this proxy-servers has cache, and when you change settings - Outlook still autodiscovering with old settings some time.
 
Try it again or try it again later.
I tried it a few seconds ago and it didn't worked.
has some lag
We are talking here about more than 4 days, so nothing which in my opinion falls under "small lag".

Please be so kind and provide more informations about the technique behind the autodiscover function for self testing and troubleshooting. The informations provided under How to manage mail autodiscover in Plesk Obsidian? are pretty limited.
 
Please be so kind and provide more informations about the technique behind the autodiscover function for self testing and troubleshooting. The informations provided under How to manage mail autodiscover in Plesk Obsidian? are pretty limited.

For Outlook 365 it should use SRV records to get information about IMAP and SMTP servers to connect:
1. So first thing is to check our SRV records avalible:
dig SRV _imaps._tcp.example.com
dig SRV _smtps._tcp.example.com

Then you may want to verify connection and certificate, e.g. for IMAPS, as a host and server name need to use host from SRV record:
echo “QUIT” | openssl s_client -connect <SRV_record_host>:993 -servername <SRV_record_host> 2>&1
 
1. So first thing is to check our SRV records avalible:
dig SRV _imaps._tcp.example.com
dig SRV _smtps._tcp.example.com
Thanks for those information, never read about it before. I created _imaps, _smtp, _autodiscover, _submission at my DNS provider.

echo “QUIT” | openssl s_client -connect <SRV_record_host>:993 -servername <SRV_record_host> 2>&1
It works, can see the TLS-confirmation.

Autodiscover still works for Thunderbird and Mail but Outlook 2019 still sais no.

When I check the autodiscover.xml direct for a domain it is empty:
1585266553502.png

Does this still work in this way or is it deprecated?

I've discovered that the autodiscover information for Thunderbird are provided by the individual Domain and NOT by the (Sub)Domain that is typed in "Specify a custom domain name for mail autodiscover". Important to know. Bug or wanted?

Why is no information provided by Plesk what has to be done at the DNS entries and what provides Plesk on which storage place? Why I have to collect all those information by myself?
 
Last edited:
For Outlook 365 it should use SRV records to get information about IMAP and SMTP servers to connect:
1. So first thing is to check our SRV records avalible:
dig SRV _imaps._tcp.example.com
dig SRV _smtps._tcp.example.com

Then you may want to verify connection and certificate, e.g. for IMAPS, as a host and server name need to use host from SRV record:
echo “QUIT” | openssl s_client -connect <SRV_record_host>:993 -servername <SRV_record_host> 2>&1
I have created my own autodiscovery a few years ago and it's working fine. At the time I researched the mechanism extensively, especially because I needed to create my own PHP-script to provide the autodiscover.xml for Outlook.

As I have no problems with my autodiscovery I also never needed to review it in order to improve it.
I stumbled on your reply in this thread and was surprised to see those records.
I actually researched those records at the time, but later I found out no client was using them as the Microsoft Autodiscovery provides all the info. I do have a separate mechanism for Mozilla's Thunderbird which uses an autoconfig.<domain> record.

Do you have any proof that Outlook is actually using those records?
With "proof" I don't mean any webpage saying that it does, but an actual test where you monitor your DNS to see which records are queried by Outlook.

It would surprise me as autodiscover.xml already provides all the info.
But maybe something has changed?

I do know that Outlook365 has changed its autodiscovery process several times in a way that it doesn't adhere its own description given more than a decade ago. I noticed it checks the existence of an Office365-account of that domain on Microsoft's hosting-platform and will thene give that its preference. I noticed this after I added a domain to that platform for a distant-future migration. From that moment on the conventional autodiscovery which still pointed to their on-premises Exchange was ignored....
To continue using the on-premises Exchange I needed to remove that domain from Office365.
BTW at the time the MX-records never changed and were kept pointing to the on-premises Exchange.
 
Last edited:
I have the same problems.

I installed the latest version of Plesk Obsydian and activated autodiscover according to the description. On several servers with different operating systems and different domains, I did not manage to use the autodiscover function in Office 365.

Check Autodiscover:
1585494266475.png

All fine:
1585494314056.png
But if I use the standard function, he cannot find the settings (Step 1):
1585494425882.png

Step 2:
1585494490017.png
Step 3:
1585494512746.png

My DNS Records:

1585494653745.png

Office 365 is not working!
 
Why is this problem being ignored?

It's not that you announce a feature that just doesn't work.

Everywhere the customer is told how to set up Outlook. Not a single customer can do this using the described method.

So what is the problem of communicating openly about it?
 
I think that should be an open discussion to narrow down the problem. Perhaps it is also a problem with the settings.

In addition, several pieces of information have already been gathered here.

But I like to make a report and refer to this thread.
 
  • Like
Reactions: sol
I have the exact same issue as B4c4rd1,
I submitted a support ticket on this #225771, but I was told it is caused by the DNS propagation!
 
Actually the issue was never solved from my side.

I have the same issue all my servers (windows+linux), on all of my domains, so I don't think it's a DNS propagation issue.
I always use CloudFare for all my domains, and copy all the settings one by one from my Plesk Dns page, Support team confirmed my DNS setting are correct, and said it working on their side, but AutoDiscover has never worked for me (for outlook 2019).
 
I have the same issue all my servers (windows+linux), on all of my domains, so I don't think it's a DNS propagation issue.
I always use CloudFare for all my domains, and copy all the settings one by one from my Plesk Dns page, Support team confirmed my DNS setting are correct, and said it working on their side, but AutoDiscover has never worked for me (for outlook 2019).
Why didn’t you continue to work out the problem with support within this ticket?
 
Back
Top