So, just to add some more information to this ...

Outlook 365 when connected to Smartermail over MAPI, periodically queries autodiscover information from the server.  

Now, when Outlook does this, it's supposed to send a request with an XML block, and then SM replies with the data.  Unfortunately, the first time Outlook sends a request, it usually fails to submit the request with this XML block, and instead sends an empty 0-byte request, which SM just returns blank.

Now, I've had my server setup with SRV autodiscover records, because I host dozens of domains and they all connect to the same SM mail server, and I have one SSL cert for the mail server.  Using a SRV record lets me direct all the domains to my one SM domain that hosts the cert.

With that configuration, Outlook will still try and contact the client's domain autodiscover.<domain>.com first -- which is rejected as not configured.  It eventually tries the SRV record method, but sends a zero-byte XML block in the request.

When this happens, Outlook 365 will then try one or two more things to get an autodiscover record, including actually manufacturing one to outlook.com!  unfortunately it gets a response back, and once that happens, Outlook reconfigures the e-mail account to talk to outlook.com, and now my MAPI account is totally unusable.  I have to delete and recreate the MAPI account.

The only way to fix Outlook 365 not to connect to outlook.com for autodiscover info is to setup a registry key in HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover, and add a DWORD value of ExcludeExplicitO365Endpoint to 1.

That fixes the first part of the autodiscover problem screwing up my MAPI account.

The next problem is these 0-byte requests that keep arriving.  The only way I've been able to fix this is to actually setup every domain on my server with a LetsEncrypt! cert so that Outlook can resolve autodiscover.<domain>.com and make an HTTPS autodiscover request on every mail domain.

That doesn't solve the 0-byte problem, but what does happen is that since the first request to autodiscover.<domain>.com actually succeeds with a 0-byte content length, Outlook then sends a SRV record autodiscover request with a valid XML block, and SM responds.

So, to make autodiscover work, I needed two methods that succeeded -- each domain needed an autodiscover subdomain over https, and then the SRV record.  If I just have one of those two, I get a zero byte request and an empty response.  I need two of them so that Outlook will send at least one of them a valid request and get a valid response.

, to make autodiscover work, I needed two methods that succeeded -- each domain needed an autodiscover subdomain over https, and then the SRV record.  
'======
Not sure I understand.... so a subdomain that looks like
srv  subdomain.domain.com      port 443 
and
srv  domain.com  ??
'=========

No.  If my main e-mail server is called `mail.maildomain.com` and the user's e-mail address is `doe@john.com` then I needed two things:

1.  DNS `A` record for `autodiscover.john.com` which is reachable via https and points to the same IIS site as `mail.maildomain.com` with it's own SSL cert

2.  A `SRV` record `_autodiscover._tcp.john.com` that redirects to `mail.maildomain.com`

Outlook tries the A record first and tries to contact an autodiscover URL through it.  If that fails, it then tries the SRV record.

Two SRV records won't do it.  Outlook doesn't try looking for two SRV records.  It tries resolving `autodiscover.john.com` first, and if that fails, it looks for a SRV record.

So since Outlook tries two different means of autodiscovering, I have 2x the chance of Outlook sending a properly formatted request.