Outlook for Mac: Autodiscover v1 endpoint returns "resource not found" for client requests

Issues
1

Issue Description

New Outlook for Mac won’t set up an account against our server. It gets most of the way through autodiscovery and then falls over at the last step.

We host about 21 domains on one Stalwart instance, TLS direct on the server, no proxy in front, ACME with TLS-ALPN-01. The domain in question got its cert this morning and it covers all four autodiscovery hostnames. Thunderbird and other clients pick up settings fine via the Mozilla autoconfig XML, so discovery generally works.

What Outlook does is hit the v2 JSON endpoint, get a valid pointer back, follow it to /autodiscover/autodiscover.xml, and then the server answers resource.not-found. Every time. Six attempts, same result.

The confusing part is that if I POST to that same URL by hand with curl I get a 200 and a complete response with the right IMAP and SMTP settings. So the endpoint works, just not for whatever Outlook is sending.

Expected Behavior

Docs say clients reaching the server over HTTPS get the autoconfig and autodiscover documents automatically, and that v1 and v2 are both supported for Outlook. So I’d expect Outlook to get the v1 response after following the redirect and configure itself.

Actual Behavior

Outlook’s requests to the v1 endpoint come back as resource.not-found, the client never gets settings, and it drops to the manual provider picker. Its own log records HxProbeAccountSettingsFailureResults error 111.

Same URL with a hand-built POST returns 200, which is the bit I can’t explain and cannot post logs, as I limited to 2 URLs.

Reproduction Steps

  1. Domain configured with ACME cert management, default autodiscovery hostnames, cert issued and verifying
  2. Add the account in new Outlook for Mac
  3. Outlook queries the v2 endpoint three times (ActiveSync, REST, AutodiscoverV1), follows the URL it gets back
  4. Server returns resource.not-found
  5. Provider picker appears

Relevant Log Output

2026-09-21T12:48:36Z DEBUG HTTP request URL (http.request-url) listenerId = “https”, localPort = 443, remoteIp = , url = “/autodiscover/autodiscover.json/v1.0/[email protected]?Protocol=AutodiscoverV1&RedirectCount=1”
2026-09-21T12:48:36Z DEBUG HTTP request URL (http.request-url) listenerId = “https”, localPort = 443, remoteIp = , url = “/autodiscover/autodiscover.json/v1.0/[email protected]?Protocol=REST&RedirectCount=1”
2026-09-21T12:48:37Z DEBUG HTTP request URL (http.request-url) listenerId = “https”, localPort = 443, remoteIp = , url = “/autodiscover/autodiscover.xml”
2026-09-21T12:48:37Z DEBUG Resource not found (resource.not-found) listenerId = “https”, localPort = 443, remoteIp =

Outlook side, same minute:

Autodetect: Begin {“Domain”:“example”}
Autodetect: Failed {“Method”:1,“Duration”:18.6,“ErrorCode”:111,“ErrorString”:“HxProbeAccountSettingsFailureResults error 111”,“Domain”:“example”}
OlkAccountConfigEmailAdvancedPhase: AutoConfig service did not return relevant results
Provider Picker: Enter

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

RocksDB

Blob Storage

Filesystem

Search Engine

Internal

Directory Backend

Internal

Additional Context

Client is new Outlook for Mac

Things I checked and ruled out before posting: DNS resolves all four hostnames to the server; cert SANs are autoconfig., autodiscover., mta-sts. and ua-auto-config.example.com and openssl s_client -servername autodiscover.example.com gives Verify return code: 0 (ok); no IP blocking or rate limiting hitting the client; tcpdump confirms Outlook connects to both the autodiscover host and the redirect target so it is following the redirect; another domain on the same box returns identical v2 and v1 responses, so it’s not domain-specific.

Minor thing while I’m here: the v2 endpoint returns 400 InvalidProtocol for ActiveSync and REST, which Outlook probes before AutodiscoverV1. Assume that’s intentional but mentioning it in case those clients want something else back.

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

That mismatch between “curl POST works but Outlook’s own connection to the same URL fails” is explained by the request method, not the URL or cert.

Looking at how Stalwart’s HTTP router handles /autodiscover/autodiscover.xml, it only serves the v1 Autodiscover response when the incoming request is a POST with an XML body containing <EMailAddress>. Any other method to that path (for example the unauthenticated GET probe that Exchange/Outlook clients issue first, per the classic MS-OXDSCLI dance, to check whether the endpoint requires auth before it sends the real authenticated POST) falls through the match arms with nothing handling it, and the server returns resource.not-found, which is the 404 you’re seeing in the log.

So the flow is:

  1. Outlook follows the v2 JSON redirect to /autodiscover/autodiscover.xml.
  2. It first sends a preliminary GET (or an unauthenticated request) to that URL to see if it needs credentials.
  3. Stalwart’s handler only recognizes POST, so that request 404s.
  4. Because Outlook got a 404 instead of a 401 Unauthorized on this probe, it aborts autodiscovery (HxProbeAccountSettingsFailureResults error 111) instead of retrying with an authenticated POST.

When you hand-craft the request with curl, you’re presumably sending the POST with the XML body directly, which is exactly the case the server does handle, hence the 200.

This is a server-side behavior gap for that GET/probe step, not a certificate, DNS, or domain-config issue on your end, so there’s nothing further to fix in your setup. I don’t have anything in the current docs describing an intended fallback for that probe request, so I can’t say definitively whether this is expected or a bug in the autodiscover handler.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

The log gives it away. On /autodiscover/autodiscover.xml the server only answers POST, and any other method falls through to resource.not-found, which is why your hand-built POST works. A POST with a missing or unreadable body would log resource.bad-parameters instead. So whatever arrived after the redirect wasn’t a POST, and a plain curl -i GET against the same URL should give you the identical 404 and log line.

To see what Outlook does send, set the http events to trace level and run one attempt. A POST produces an http.request-body event, with the headers and body, right after the request URL; for anything else you’ll see nothing between the URL and the not-found. Also check the remote IP on those requests. New Outlook does part of its discovery through Microsoft’s cloud service, so they may not come from the Mac at all.

The 400 InvalidProtocol for ActiveSync and REST is intentional, since the server doesn’t offer either protocol, and Outlook moves on to AutodiscoverV1 as your log shows. The v2 answer points at the server’s own hostname, not autodiscover., which is the second host you saw in tcpdump.

4

Thanks so much for getting back to me. I just checked with http.request-body at the trace level.

I did a manual POST to the v1 endpoint, and it sent a request-body event. But Outlook’s request to that same URL doesn’t - it just goes connection started, then request URL (/autodiscover/autodiscover.xml), response body, resource.not-found, all using the same port, and no body event at all.

So, Outlook isn’t sending a POST after the v2 redirect, which seems to confirm what you thought.

Also, the .xml requests are coming directly from the client machine, not Microsoft’s cloud. Only the Protocol=ActiveSync probes are coming from Microsoft (those are the 52.125.141.x addresses).

That really points to a problem on the client-side. Since so many people are using the new Outlook, do you think we could have it respond to GET requests on that endpoint? It doesn’t carry any specific addresses, but the server and ports are consistent across deployments, so a simple, general response might help the client move forward. I’d be happy to test out a patch if that would be helpful.

5

That settles which side it’s on. I’m wary of answering a bare GET with settings, though. In Autodiscover v1 the email address travels in the POST body; a GET is only defined for the redirect step, where the client expects a 302, and Exchange itself answers a GET on that URL with an error. I have nothing showing that new Outlook for Mac would accept an XML reply to a GET, so a patch built on that assumption could easily miss.

The method has to come from the client side, since Stalwart doesn’t log it on http.request-url. mitmproxy on the Mac (with its CA trusted) or Outlook’s own network log would show whether it’s a GET, a HEAD or an OPTIONS preflight, and an OPTIONS would point somewhere else entirely. If you can capture one attempt I’m happy to try something against it.