Server is returning a JSON with HTML error code 404 and detail “The requested resource does not exist on this server.”
Reproduction Steps
Brand new instalation
Configuration of the domain, DNS entries
Relevant Log Output
2026-05-14T06:19:24Z DEBUG HTTP request URL (http.request-url) listenerId = “https”, localPort = 443, remoteIp = 172.20.0.50, remotePort = 60598, url = “/autodiscover/autodiscover.xml”
2026-05-14T06:19:24Z TRACE Expression evaluation result (eval.result) listenerId = “https”, localPort = 443, remoteIp = 172.20.0.50, remotePort = 60598, id = “Http with id singleton”, key = “allowedEndpoints”, result = “Integer(200)”
2026-05-14T06:19:24Z DEBUG Resource not found (resource.not-found) listenerId = “https”, localPort = 443, remoteIp = 172.20.0.50, remotePort = 60598
2026-05-14T06:19:24Z TRACE HTTP response body (http.response-body) listenerId = “https”, localPort = 443, remoteIp = 172.20.0.50, remotePort = 60598, contents = “{“type”:“about:blank”,“status”:404,“title”:“Not Found”,“detail”:“The requested resource does not exist on this server.”}”, code = 404, size = 120
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
Additional Context
Stalwart version 0.16.5
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.
The problem is that you are accessing https://mail.example.com/autodiscover/autodiscover.xml, but Stalwart expects the Microsoft Autodiscover request to come from the dedicated autodiscover subdomain, not the main mail hostname.
which requires a matching CNAME for autoconfig.example.com.
The docs note: “The legacy Mozilla autoconfig and Microsoft Autodiscover formats expect to find their endpoints on dedicated subdomains, typically pointed at the mail host.” No additional server-side configuration is needed beyond the DNS records – once the CNAME resolves to Stalwart over HTTPS (port 443), it will serve the discovery documents automatically.
The required DNS records are also shown on the domain management page in the WebUI.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.
The Microsoft autodiscover endpoint at /autodiscover/autodiscover.xml only responds to POST requests with an XML body (that’s the v1 protocol spec), so a plain GET will always return 404 even on a working setup. The endpoints Stalwart exposes are:
POST /autodiscover/autodiscover.xml (Microsoft v1)
GET /autodiscover/autodiscover.json?Email=... (Microsoft v2)
GET /.well-known/autoconfig/mail/config-v1.1.xml (Mozilla)
GET /mail/config-v1.1.xml (Mozilla legacy)
So if you want to test from a browser or curl, use the Mozilla path; that one returns the XML on GET. For Microsoft clients (Outlook), let the client drive: it will POST to autodiscover.<domain>/autodiscover/autodiscover.xml, and that POST will succeed if your DNS has the autodiscover CNAME pointing at your Stalwart host.
Outlook autoconfig is not working at all, when I’m configuring the account I have to choose the server type (IMAP) and after that to enter mail server, ports etc.
Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
Autodiscover settings weren’t obtained when the Autodiscover POST request was sent.
Test Steps
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL ThisIsTheCorrectURL/Autodiscover/Autodiscover.xml for user [email protected].
The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
On the other hand the Outlook Test Connectivity is working means is showing the server, ports etc.
So I need help to find out if I did something wrong or how can I help identifying the problem.
The Connectivity Analyzer failure usually comes down to one of three things on a working Stalwart install: the autodiscover.<domain> CNAME isn’t published (Thunderbird working only proves autoconfig.<domain> is in place, which is a separate record), the autodiscover.<domain> name isn’t covered by the TLS certificate (Outlook will not POST over a name-mismatched cert), or port 443 isn’t reachable for that hostname. The full record list is at Setting up DNS | Stalwart.
Once both CNAMEs resolve to the mail host and the cert covers autodiscover.<domain>, the Connectivity Analyzer should succeed. If it still doesn’t, share the request log lines from your server for the analyzer’s IP and the exact URL it hit.
The email fullfiled in the Outlook window was [email protected] as in the autodiscover link, I don’t understand the error “Missing domain in email address”.
The 404 on /autodiscover/autodiscover.xml is expected and not a bug. That endpoint is the Microsoft v1 (POX) endpoint and it is POST-only, so any browser GET will always return 404, even on a fully working setup. It is not meant to be opened in a browser.
The “Missing domain in email address” 400 was the v2 endpoint not reading the address when Outlook puts it in the URL path (the /autodiscover/autodiscover.json/v1.0/user@domain form) rather than in an Email query parameter. That was fixed in 0.16.9. While looking into your report I also found a related edge case: if a client percent-encodes the @ as %40 in the path, the address was still missed and you would get the same 400. We have just fixed that too, so both the literal and encoded path forms are handled.
The 400 you still see after upgrading is a different and intentional response. Outlook probes with Protocol=ActiveSync, and Stalwart does not implement an ActiveSync/Exchange server, so it only advertises AutodiscoverV1 and returns InvalidProtocol for anything else. This matches what Office 365 itself returns for an unsupported protocol, so it is by design and does not break the working AutodiscoverV1 flow. Outlook probes one protocol per request, so that single 400 is harmless.
To make sure the working path succeeds end to end, confirm that autodiscover. resolves and is covered by your TLS certificate on 443. Thunderbird succeeding only exercises the Mozilla autoconfig path, which is separate from the Microsoft records, so it is not a guarantee that the Outlook side is reachable.
I’m concentrating only on Outlook so the all the last tests were done only from Outlook when adding a new account.
autodiscover.example.ro it is published (in order to be 100% I put it in etc/hosts) and this is proved by the fact that the request is reaching the server:
That seems to be the problen, your certificate is *.example.com, but the host is autodiscover.example.ro. A *.example.com wildcard doesn’t cover anything under .ro, so when Outlook reaches autodiscover.example.ro it gets a cert that doesn’t match the name and refuses to POST. The request hitting the server (which your /etc/hosts entry guarantees) only proves DNS and reachability, not that the TLS name validates.
Two things to note even once the cert is fixed: a *.example.ro wildcard covers autodiscover.example.ro but not multi-label hosts, so make sure the cert’s SAN list actually includes autodiscover.example.ro. And the ActiveSync 400 and the browser 404 are both expected; the real flow is Outlook probing the v2 JSON endpoint, getting redirected to the v1 POX URL, then POSTing to it over a valid cert. Check what’s served with:
@andreim Can you please change the title of this bug to “Exchange AutoDiscover is not working”? Because AutoConfig is the method that Thunderbird uses. You are talking specifically about Exchange AutoDiscover.