Automated DNS management fails (DeSEC, "Failed to set DNS RRSet: Not found")

Issues
1

Issue Description

Trying to use the DeSEC DNS provider on a fresh Stalwart instance is not working. The task types “Perform DKIM key rotation for a domain” and “Perform DNS management for a domain” all fail with the same error.

Expected Behavior

The DeSEC DNS provider should update the DNS records at desec.io successfully.

Actual Behavior

The DNS management tasks fail with (shortened example, identical for all tasks and DNS records):

Failed to set DNS RRSet for mx.mydomain.org./TXT: Failed to set DNS RRSet: Not found; Failed to set DNS RRSet for mydomain.org./TXT: Failed to set DNS RRSet: Not found

I fail to comprehend, what that “Failed to set DNS RRSet: Not found” is trying to tell me. What has been “not found”?

Reproduction Steps

  1. Setup fresh Stalwart instance (0.16.7 to date)
  2. Setup domain name and configure automatic DNS management
  3. Setup DNS Provider wit DNS server type “DeSEC” and provide API token created at desec.io
  4. check status for scheduled task for DNS management and DKIM key rotation

Relevant Log Output

Failed to set DNS RRSet for mx.mydomain.org./TXT: Failed to set DNS RRSet: Not found; Failed to set DNS RRSet for mydomain.org./TXT: Failed to set DNS RRSet: Not found

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

The API token from DeSEC seems to be setup correctly. At the DeSEC WebUI the “last used” column in token management gets updated every time i reexecute a DNS task in Stalwart.

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

Let me research the DeSEC DNS provider integration and the “Not found” error.

The CHANGELOG entry is very informative. Let me look at it more closely and also check the DeSEC API behavior around apex records.

The CHANGELOG entry is very informative. There was a known bug with deSEC’s apex record handling: the server was sending @ as the subname for apex records, but the deSEC API rejects that and requires an empty string instead. This fix is noted in the changelog and the “Not found” error you’re seeing is exactly what the deSEC API returns in that scenario.

The key question is: is the fix already in the version you’re running? The changelog entry reads:

deSEC: Use empty subname for apex records instead of @, which the API rejects.

This fix was landed after the initial deSEC support was added. The errors you’re seeing – specifically for mydomain.org./TXT (the apex/root domain records) – match this exact bug. Records like mx.mydomain.org./TXT failing alongside the apex records suggests the same root cause is affecting multiple record types.

What to check and do:

  1. Confirm you’re on the latest available release. The fix for the @ vs empty subname issue was merged into the server codebase. If your Docker image is not fully up to date (e.g., pulled from cache), pull the latest image and restart to ensure you have the patched version.

  2. Token scope at deSEC. The deSEC API token needs write permissions scoped to your domain. Stalwart confirms the token is being used (you see “last used” updating), but deSEC tokens can be restricted by domain – verify the token has permission to manage mydomain.org specifically, not just read or a different domain.

  3. Domain must be registered/delegated in deSEC. The deSEC “Not found” response typically means the domain/zone does not exist in your deSEC account – the API returns 404 when the zone isn’t found, not just when a record is missing. Double-check that mydomain.org (and mx.mydomain.org if that’s a separate zone) actually appear as domains in your deSEC dashboard before Stalwart tries to manage records there.

The third point is the most likely cause if you haven’t explicitly added the zone to deSEC before enabling automatic management – deSEC does not auto-create zones, the zone must already exist in your account.

For reference: DNS Providers documentation

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

3

This has been fixed on the main branch. The fix will be included in v0.16.8.