With default hostname “mail . example . com” and default domain is “example . com”, most of the config URLs in “mail . example . com/mail/config-v1.1.xml” are correct by showing “mail . example . com”; however, the clientConfigUpdate URL appears as “autoconfig . mail . example . com/mail/config-v1.1.xml”. I don’t believe this is correct as the “autoconfig” should be based off of the default domain and not default hostname.
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.
Based on the server source, this is expected given how the autoconfig fallback works, not a bug in the sense of misusing the primary domain: when the request doesn’t include an emailaddress query parameter, Stalwart falls back to using the server’s hostname (server_name, e.g. mail.example.com) as the “domain” value used to build the clientConfigUpdate URL, rather than the actual mail domain. That’s why you see autoconfig.mail.example.com when browsing the URL directly without an email parameter.
In real-world use, mail clients (Thunderbird, Outlook, etc.) always request the autoconfig URL with an [email protected] parameter. In that case Stalwart correctly extracts example.com from the address and the clientConfigUpdate URL will be https://autoconfig.example.com/mail/config-v1.1.xml as expected. If you test the endpoint manually without appending [email protected], you’ll see the hostname-based fallback instead.
You can verify by requesting: https://mail.example.com/mail/[email protected]
and confirming the clientConfigUpdate URL now shows autoconfig.example.com.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
Actually, I don’t think this is a bug. The default value, like the bot wrote, uses the default hostname. However, when you try and obtain the settings by entering the email address in a client, Thunderbird for example, it does pull in the correct URLs. If your default domain is “mail.example.com”, try going to “https://mail.example.com/mail/[email protected]” and view the last URL - it should be correct.
The domain in clientConfigUpdate comes from the emailaddress query parameter, and only falls back to the server hostname when that parameter is missing. Most autoconfig clients append it, so the URL is correct in practice. The response you get from the bare URL is a template rather than a live configuration, which is why it also contains a %EMAILADDRESS% placeholder; that’s the tell.
To see it directly, fetch the same URL with [email protected] appended and the last URL comes back as autoconfig.example.com. The incoming and outgoing server hostnames were always right, which is why only that one line looked off.