When utilizing the Automatic DNS Management feature for my primary domain, every DNS record is successfully added to deSEC except for those that use the domain name for the subname field. In my case, the relevant records are:
example.com. IN TXT "v=spf1 mx -all"
example.com. IN CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/##########"
(I had manually added the MX record in advance, but since this is the only other record with “example.com.” in the subname field I will assume this to be the fourth record issuing the BadRequest.)
Relevant Log Output
Failed to create DNS record for example.com.: Failed to create DNS record: API error: BadRequest {"subname":["Subname can only use (lowercase) a-z, 0-9, ., -, and _, may start with a '*.', or just be '*'. Components may not exceed 63 characters."]}; Failed to create DNS record for example.com.: Failed to create DNS record: API error: BadRequest {"subname":["Subname can only use (lowercase) a-z, 0-9, ., -, and _, may start with a '*.', or just be '*'. Components may not exceed 63 characters."]}; Failed to create DNS record for example.com.: Failed to create DNS record: API error: BadRequest {"subname":["Subname can only use (lowercase) a-z, 0-9, ., -, and _, may start with a '*.', or just be '*'. Components may not exceed 63 characters."]}; Failed to create DNS record for example.com.: Failed to create DNS record: API error: BadRequest {"subname":["Subname can only use (lowercase) a-z, 0-9, ., -, and _, may start with a '*.', or just be '*'. Components may not exceed 63 characters."]}
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
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 agree to follow the project’s Code of Conduct.
I had the same issue. What makes it worse, is that stalwart clears all records first, takes a while to recreate them and then fails for most of them. I think it should try to merge them intelligently.
So, i attempted a successful migration after a few attempts and got thru to a working docker container instance (upgrade from v15.5 to v16.3), but:
Using Cloudflare Token, when CF is setup as a DNS provider breaks with the following error Failed to create DNS record for ua-auto-config.mydomain.com.: Failed to create DNS record: API error: BadRequest {"success":false,"errors":[{"code":6003,"message":"Invalid request headers","error_chain":[{"code":6103,"message":"Invalid format for **X-Auth-Key header**"}]}],"messages":[],"result":null};
So i changed the CF Token to the CF Auth Key, now it at least authenticates with CF with appropriate CF Email account but further fails again, regardless of whether there’s records already exist or not at all. stalwart-temp | 2026-05-02T12:04:58Z WARN Task failed during processing (task-manager.task-failed) id = 305016055437198337, details = "DnsManagement", reason = "Failed to create DNS record for mydomain.com.: Failed to create DNS record: API error: BadRequest {"result":null,"success":false,"errors":[{"code":81058,"message":"**An identical record already exists**."}],"messages":[]}"
Is this just me or does anyone else have this issue with CF setup as DNS Provider?
@mdecimus Why does the DNS Server config page ask for CF Token but won’t work unless a CF AUTH Key is provided, instead?
Additional Issue with DNS records for the domain(s) setup in Stalwart:
A custom HTTPS listener is setup for JMAP (4443 instead of default 443).
While i had to include the following env vars to be able to access the webadmin portal, the DNS records (SRV) specifically for caldav and carddav however didn’t respect this change and kept using 443 port instead while no DNS records (SRV) for JMAP were created at all. (as visible in the zone file option of the domain).
Do I misunderstand that caldav and carddav should work on the same listener as JMAP?
So essentially since CF DNS Server won’t work as expected, and hence the ACME Provider is usless because, the domain settings expect a functional DNS Server for ACME to work, obviously. Thus forcing me to either use manual DNS server and hence manually mapped TLS certificate/private-key combo
So for now, i’ve reverted back to v0.15.5
List of issues, post migration (at least in my case):
Cloudflare Auth Key works although a Token is supposedly required, but doesn’t work.
Auto DNS management (Cloudflare, in my case, deSEC in OP’s case) fails to intelligently (or utterly) create/update records
I tried creating a new domain to check the behavior after having changed the HTTP listener ports but the DNS zone file simply ignores the currently active listeners and continues to use default port 443, for CalDav, CardDav and JMAP. In the process, it didn’t even create new TLSA records for the new domain