DCV methods

Email challenge-response

When the order is placed, you select an email address from a shortlist of acceptable options. We send an email to that address containing a unique validation code. The email should be received by someone in control of the domain; they follow the link in the email and enter the validation code to prove control of the domain.

The list of acceptable email addresses for any given domain are:

  • admin@

  • administrator@

  • hostmaster@

  • postmaster@

  • webmaster@

  • a contact email address published in the domain’s DNS TXT record and visible to our CA system

When using a DNS TXT contact email address, the TXT record value must be a single, valid email address (with no additional text). It must be published on the _validation-contactemail subdomain of the domain being validated.

The following is an example DNS TXT record for yourdomain.com that is acceptable as a DCV contact email address:

_validation-contactemail.yourdomain.com. IN TXT "[email protected]"

Ordering a certificate through Sectigo’s web interface

When ordering a certificate through Sectigo’s web interface, the certificate request process defaults to email challenge-response DCV. The list of acceptable email addresses will be displayed for selection based on the common name extracted from the CSR.

Ordering a certificate through Sectigo’s API

Once the CSR is received from the customer, the FQDN of the common name (CN) from the CSR must be extracted. DecodeCSR, or any other method you have available, can be used. Use the extracted FQDN to call GetDCVEmailAddressList, which returns the list of acceptable DCV approval email addresses for that FQDN. To include DNS TXT contact email addresses in the response, JSON format must be set to 2.

Only email addresses returned by GetDCVEmailAddressList are acceptable. If an email address you expect to appear in the domain’s DNS TXT record is not returned, the CA system was unable to extract it via DNS TXT lookup and it cannot be used for DCV.

After selecting an acceptable email address, submit it in dcvEmailAddress when calling AutoApplyOrder or AutoApplySSL. The DCV email is sent when the AutoApplyOrder or AutoApplySSL request is processed.

Because DNS TXT results are cached, if you use a DNS TXT contact email address, call AutoApplyOrder or AutoApplySSL within 24 hours of calling GetDCVEmailAddressList.

Calling GetDCVEmailAddressList is not required if the dcvEmailAddress is one of the five default approval addresses.

If you use an email address published in the domain’s DNS TXT record, it is not required to call GetDCVEmailAddressList, but the selected email address must match one of the values that would be returned by that API.

For multi-domain certificates, see DCV policy.

The unique validation code is only valid for 30 days. Any attempt to use the unique validation code after 30 days will fail.

Starting June 15, 2025, WHOIS-based email addresses can no longer be used for domain validation, and previously completed validations using WHOIS email addresses cannot be reused.

Continued use of email-based DCV methods is discouraged. In line with CA/B Forum Ballot SC-090, all email-based DCV methods are on a deprecation path, with full industry deprecation expected by early 2028.

Plan to migrate to DNS-based or HTTP-based validation methods.

HTTP-based DCV

HTTP-based DCV requires an HTTP server on port 80 or an HTTPS server on port 443 for the authorization domain name.

We follow CNAMEs when completing HTTP-based DCV. We retrieve the request token from the valid authorization domain name that exactly matches the FQDN included in the certificate request.

Two hashes of the CSR are generated before submission to Sectigo. A plain text file is created on the HTTP(S) server of the authorization domain name, with one hash used as the filename and the other included in the file content. We call this text file the request token. For more information, see Request token.

For example, if a CSR is generated with CN=example.com, the authorization domain name is example.com. The CSR is hashed using both the MD5 and SHA-256 hashing algorithms. A text file is created containing the SHA-256 hash, followed by the domain sectigo.com on the next line:

c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f
sectigo.com

The file is named <MD5 hash>.txt and placed in the /.well-known/pki-validation/ directory of the HTTP server. The following is an example:

http://example.com/.well-known/pki-validation/C7FBC2039E400C8EF74129EC7DB1842C.txt

Once the order is received by Sectigo and HTTP-based DCV is specified, the Sectigo CA system checks for the presence of the text file and its content. If the file is found and the hash values match, domain control is proven.

Ordering a certificate through Sectigo’s web-interface

The hash values are calculated and shown in the web interface during the order process, on the same page as the DCV email address options. Both the MD5 and SHA-256 hash values must be saved to the file served from your HTTP server (as described above) before you continue with the order.

Ordering a certificate through Sectigo’s API

Generate the hashes from the CSR before submitting the order to Sectigo.

Hashes must be generated from the DER-encoded (binary) version of the CSR, not the base64 PEM encoded version. Variations in PEM encoding can cause different hash values, whereas the DER-encoded CSR will remain constant.

Create the request token file with the following requirements:

  • The filename must use the MD5 hash in uppercase.

  • The filename must have a .txt extension.

  • The SHA-256 hash value within the file is case-insensitive.

Sectigo looks only for the uppercase MD5 hash filename. Most HTTP servers are case-sensitive, so using lowercase characters may cause DCV to fail.

When calling AutoApplyOrder or AutoApplySSL, specify the dcvMethod parameter to indicate HTTP(S)-based DCV. Set dcvMethod to one of the following uppercase values:

  • HTTP_CSR_HASH for HTTP on port 80

  • HTTPS_CSR_HASH for HTTPS on port 443

For multi-domain certificates, see Request token.

DNS-based methods

DNS CNAME Based DCV

DNS CNAME based DCV requires the creation of a unique CNAME record, pointed back to Sectigo. We look for the CNAME at every valid authorization domain — Sectigo starts with the FQDN and then we will strip one or more labels from left to right in the FQDN and will look for the CNAME on each intermediate domain.

For example, for a certificate request for an FQDN of *.mail.internal.example.com, we would look for the CNAME in these places and in this order:

mail.internal.example.com
internal.example.com
example.com

The authorization domain name is the one we find it on.

Two hashes of the CSR are generated before submission to Sectigo. A CNAME DNS record is created under the authorization domain name. We call the content of the CNAME the request token. For more details about the content of the request token, see Request token.

The format of the CNAME will be:

'_' <MD5 hash>.Authorization Domain Name. CNAME <SHA-256 hash>.[<uniqueValue>.]sectigo.com.

The leading underscore is at the start of the MD5 hash.

The following is an example for a CSR is generated with the CN=www.example.com when the CSR is hashed using both the MD5 and SHA-256 hashing algorithms:

MD5: c7fbc2039e400c8ef74129ec7db1842c
SHA-256: c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f

To perform DNS CNAME based DCV, the following DNS CNAME record may be created before submitting the order:

_c7fbc2039e400c8ef74129ec7db1842c.example.com. CNAME
c9c863405fe7675a3988b97664ea6baf.442019e4e52fa335f406f7c5f26cf14f.sectigo.com.

Then the request is submitted to Sectigo, the presence of this CNAME DNS record is checked, and if found, domain control is proven.

Ordering a certificate through Sectigo’s web-interface

The hash values are calculated and presented via the web-interface during the order process. They are on the same screen as the DCV email-address options. Both the MD5 and SHA-256 hash values of the CSR are shown, and must be added to DNS as a CNAME record as the preceding instructions show before continuing with the order.

Ordering a certificate through Sectigo’s API

The hashes are generated from the CSR before the order is submitted to Sectigo. The hashes must be generated from the DER-encoded (binary) version of the CSR, not the base64 PEM-encoded version. Variations in the PEM encoding can cause differing hash values, whereas the hashes of the DER-encoded version will remain constant. The DNS CNAME record is then created in the preceding format.

When the AutoApplyOrder or AutoApplySSL call is made, an additional parameter must be specified to indicate use of CNAME based DCV. This parameter is called dcvMethod and must be set to the uppercase value CNAME_CSR_HASH. For multi-domain certificates, see Request token.

DNS TXT Random Value Based DCV

DNS TXT based DCV requires the creation of a unique DNS TXT record. We look for the DNS TXT random value at every valid authorization domain.

Sectigo starts with the FQDN and then we will strip one or more labels from left to right in the FQDN and will look for the DNS TXT random value on each intermediate domain.

The format of the DNS TXT will be:

'_'pki-validation.Authorization Domain Name [<randomValue>]

For example, to perform DNS TXT based DCV, the following DNS TXT record may be created if the 123456789abcdef== random value is returned for the order.

DNS TXT Record Name: _pki-validation.example.com.
Type: TXT
Value: 123456789abcdef==

The random value is valid for 30 days. The same random value can be used for any number of domains in one certificate request, but may not be used for any other certificate request. Each replacement or renewal of the certificate counts as a new certificate request.

Ordering a certificate through Sectigo’s web-interface

The random value is presented via the web-interface during the order process. It is on the same page as the DCV email-address options. Save it before continuing with the order.

Ordering a certificate through Sectigo’s API

If this method has been chosen for DCV, the response to the certificate request will contain a random value unique to the request and its expiry timestamp. The random value can also be fetched using autoUpdateDCV or GetMDCDomainDetails. The same APIs should be used to fetch a new random value if the latest one has already expired. This method can be used for validation of wildcard domain names.