DNS-01 challenge TXT records are not removed after successful ACME validation

Issues
1

Issue Description

Stalwart leaves temporary DNS-01 _acme-challenge TXT records in DNS after successful ACME validation and certificate issuance.

I am using the built-in deSEC DNS provider with the DNS-01 challenge type. Certificate issuance completes successfully for all configured SANs, but one _acme-challenge TXT record remains in the DNS zone for each validated hostname.

In this case the certificate contains six SANs, and six corresponding _acme-challenge TXT records remained after the certificate was successfully issued.

This appears related #238, but the behavior is different: there are no DNS update errors or failed ACME validations in this case. The certificate is issued successfully; only the temporary DNS records are not cleaned up afterwards.

Expected Behavior

After a DNS-01 authorization has been successfully validated, Stalwart should remove the temporary _acme-challenge TXT record that was created for that authorization.

This also matches the Stalwart documentation, which states that DNS-01 publishes a per-validation TXT record and removes it once validation succeeds:

Actual Behavior

The ACME order completes successfully and the Let’s Encrypt certificate is issued correctly, but the _acme-challenge TXT records remain in the DNS zone after validation.

For a certificate containing the following six SANs:

mail.example.com
host.example.com
mta-sts.example.com
ua-auto-config.example.com
autoconfig.example.com
autodiscover.example.com

the following six TXT records remained after successful issuance:

_acme-challenge.mail.example.com
_acme-challenge.host.example.com
_acme-challenge.mta-sts.example.com
_acme-challenge.ua-auto-config.example.com
_acme-challenge.autoconfig.example.com
_acme-challenge.autodiscover.example.com

There were no DNS update errors and the issued certificate is valid.

Reproduction Steps

  1. Configure a domain in Stalwart with automatic DNS management using the built-in deSEC provider.
  2. Configure an ACME provider using Let’s Encrypt and the DNS-01 challenge type.
  3. Configure one or more Subject Alternative Names for the certificate.
  4. Trigger certificate issuance or renewal.
  5. Wait for DNS propagation and successful ACME validation.
  6. Confirm that the certificate is successfully issued.
  7. Inspect the DNS zone in deSEC.
  8. Observe that the _acme-challenge TXT records created by Stalwart are still present after successful validation.

Relevant Log Output

No relevant error is logged. ACME validation and certificate issuance complete successfully; the issue is only visible by inspecting the DNS zone afterwards.

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

  • Built-in deSEC DNS provider
  • Let’s Encrypt production ACME
  • DNS-01 challenge
  • deSEC DNS TTL: 15 minutes
  • ACME DNS polling interval: 15 seconds
  • Propagation timeout: 5 minutes
  • Initial propagation delay: 16 minutes

The deSEC API credentials have permission to create, modify and delete records in the zone. Record creation works correctly and certificate issuance succeeds.

I also reviewed the v0.16.21 implementation in:

crates/common/src/network/acme/order.rs

In the DNS-01 path, Stalwart calls set_rrset() to publish the TXT challenge and waits for propagation. Once the authorization reaches AuthStatus::Valid, the function returns successfully. I could not find a corresponding deletion of the temporary TXT record after successful validation.

The same behavior appears to still be present in v0.16.22.

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

Reviewing the ACME DNS-01 code confirms this: in crates/common/src/network/acme/order.rs, the authorize() function calls set_rrset() to publish the _acme-challenge TXT record and waits for propagation, but once AuthStatus::Valid is reached (both in the initial match and in the polling loop later in the function) it simply returns Ok(()). There is no call to remove or delete the TXT record anywhere in that path or in the DnsUpdater wrapper (crates/common/src/network/dns/update.rs), which only exposes set_rrset/update-style operations used for provisioning, not a corresponding cleanup call after a successful authorization.

So your analysis is correct: the current implementation does not clean up the _acme-challenge TXT records after successful DNS-01 validation, which contradicts the behavior described in the docs at Challenge Types | Stalwart. This looks like a genuine bug rather than a configuration issue on your end. A staff member will need to confirm and address this in the code; I can’t file that change myself, but your report and code references are exactly what they’ll need to follow up on.

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

3

Fixed in v0.16.23 (yet to be released).