This confirms it: when a domain is added, Stalwart automatically generates DKIM signing keys for it (managed via dkimManagement), so a new DkimSignature object linked to that domain exists right away, even before you’ve touched DKIM manually.
This confirms the fix: when a domain is created, Stalwart auto-generates DKIM keys for it (DkimSignature objects), and those signatures still reference the domain, blocking a straight domain deletion. Delete the DkimSignature objects first, then the domain.
You can find the linked signature IDs from the error message (DkimSignature#jgrvlmdiadqa, DkimSignature#jgrvlmowaeaa) and remove them before deleting the domain:
docker run --rm ghcr.io/stalwartlabs/cli delete DkimSignature --ids jgrvlmdiadqa,jgrvlmowaeaa --url https://... --api-key ...
docker run --rm ghcr.io/stalwartlabs/cli delete domain --ids c --url https://... --api-key ...
In the WebUI, you can alternatively delete the domain’s DKIM signatures from the DKIM management page for that domain before deleting the domain itself. This is expected behavior: domain deletion is blocked (objectIsLinked) if any object (including auto-generated DKIM keys) still references it, and the docs on apply/destroy note this ordering requirement explicitly (destroy dependents like DkimSignature before the parent Domain).
You didn’t touch DKIM, but the server did: new domains default to automatic DKIM management, which generates one signature per algorithm as soon as the domain exists. Deleting a domain doesn’t cascade to objects that point at it, so the keys have to go first:
stalwart-cli delete dkimsignature --ids jgrvlmdiadqa,jgrvlmowaeaa
stalwart-cli delete domain --ids c
The same works from the web UI by deleting that domain’s entries under DKIM Signatures before the domain.