SimpleACMEThe DNS record you configure once and the value used for a particular ACME challenge are not the same thing. A permanent challenge CNAME is a stable delegation. The TXT authorization value behind it changes as your client validates new orders.
That separation is the foundation of SimpleACME. Instead of teaching every renewal host how to edit your main DNS zone, you point the challenge name at the assigned SimpleACME target and use account-specific credentials to update that target.
Follow the record chain
For app.example.com, the challenge owner is commonly _acme-challenge.app.example.com. The CNAME at that owner points to the full target supplied in your SimpleACME account. The TXT response is served at the delegated destination.
Keep the distinction between a fully qualified owner name and the short host field shown by a DNS control panel. Some panels append the zone name automatically. Entering the full name into the wrong field can accidentally create a duplicated suffix.
Why the CNAME can stay
A renewal changes the authorization value, not the intended delegation. As long as the client uses the same registration and the CNAME still resolves correctly, you do not need to edit that CNAME for every certificate order.
The record is permanent in the sense of reusable configuration, not an exemption from maintenance. Deleting the registration, changing its target or moving DNS without copying the record can break future validation.
Check the setup carefully
- Copy the exact owner and target from the account.
- Remove conflicting record types at the same owner where necessary; a CNAME cannot ordinarily coexist with unrelated data at that name.
- Save the change in the authoritative DNS zone, not only a local resolver override.
- Verify the public CNAME and allow caches to expire.
- Run a client staging validation before relying on unattended renewal.
Do not use a provider's HTTP redirect feature in place of a DNS CNAME. They solve different problems, and a web redirect does not delegate DNS challenge answers.
Keep useful operational evidence
SimpleACME's timeline shows TXT authorization changes. Compare those timestamps with the ACME client's order and deployment logs. This helps distinguish an update that never arrived, a DNS visibility problem, a rejected certificate order and an application that did not reload.
Treat the update credentials as sensitive even though the target record is public. The public CNAME is not a password, and knowing it should never be enough to perform an authenticated update.
Fewer changes at the fragile point
The benefit is operational consistency: one provider-independent DNS change, followed by a repeated client workflow. When certificate renewal is already automated, reducing the number of systems that need write access makes that workflow easier to reason about. Prepare a delegated domain and keep the resulting CNAME in your infrastructure documentation.