There are many DCV methods supported by CABF and CAs that aren’t currently supported in ACME, but it’s worth going to the effort of working with the allowed ones because of the broad support for ACME in the industry.

The explanation of the protocol below is more than you might need to work with ACME, but it will help you a great deal to understand it. This is a simplified description. See the ACME specification for all the details.

An ACME client program must run on the client systems. It doesn’t need to be on the system that actually uses the certificate, although that is typical and probably easiest. You use OS facilities (systemd on Linux, Scheduled Tasks on Windows) to configure this program to run on a schedule. In March 2029, maximum certificate lifetime will drop to 47 days, so you might choose to renew every 30 days, and therefore run the client every 30 days.

When you run it, the ACME program contacts the CA to order a certificate, so it must have access to the CA account credentials. The client program sends the certificate order to the CA which returns a data structure containing a list of DCV options (currently DNS-01 and HTTP-01) that the client may use to prove domain control. These are called challenges, and the client selects one of them. Each DCV object also contains a unique value, called a token. HTTP-01 challenges also contain the URL in the domain's web space where the client must place the token.The client then issues an HTTP POST to a supplied web address at the CA to inform it of the response to the challenge.

Assume, for our examples, that the token is "DGyRejmCefe7v4NfDGDKfA". If the challenge is HTTP-01, the CA will also supply a URL, for example https://example.com/acme/authz/prV_B7yEyA4, and the HTTP-01 then posts the response at that address. The DNS-01 writes the response in the public DNS for that domain, for example:

_acme-challenge.www.example.org. 300 IN TXT "DGyRejmCefe7v4NfDGDKfA"

If the challenge is successful — meaning the CA finds the file or DNS record it expects — it responds with an HTTP 200. The client then proceeds with the order by sending a CSR, and polls the server until it responds successfully. At that point it can download the certificate.

DNS-PERSIST-01

In October 2025, the CA/Browser Forum approved a new DCV method: 3.2.2.4.22 DNS TXT Record with Persistent Value. It was not approved as an ACME method and the IETF body in charge of the ACME standard has not finalized work on this method, which will be known as DNS-PERSIST-01 in the ACME context.

DNS-PERSIST-01 requires only that the applicant have a specific record in the public DNS for the domain. The advantage of this method is that the record may be created once and will then work indefinitely, or until the record expiration date, if one is specified. This method is also approved by CA/B Forum for wildcard certificates.

The record refers indirectly to the applicant's account, and there is an option to specify an expiration date for approval using the record. The example below is from the CA/B Forum specification:

_validation-persist.example.com IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"

The IETF working group has been making changes beyond the method approved by the CA/B Forum. After the specification is final and ACME clients implement it, DNS-PERSIST-01 will appear as one of the DCV options presented by the CA to the client. If the challenge entry is already in the DNS for the domain, the ACME client need only POST to the response URL. The CA will then check the DNS entry and reply with approval.