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.