Domain Control Validation (DCV) explained

Before any certificate authority issues a certificate for example.com, it has to confirm you actually control that domain. That step is Domain Control Validation, and knowing how it works explains most "my certificate won't issue" problems.

The three validation methods

HTTP validation. The CA asks you to place a specific file at a known path, like /.well-known/acme-challenge/<token>. It fetches that URL over plain HTTP; if the token matches, you pass. This is what most automated clients use, but it requires the domain to already be reachable on port 80.
DNS validation. The CA gives you a token to publish as a TXT record, usually at _acme-challenge.example.com. It queries DNS for that record. This works even when the site is not yet live, and it is the only method that can issue wildcard certificates.
Email validation. The CA emails an address it considers authoritative for the domain (admin@, webmaster@, or the WHOIS contact) with a confirmation link. It is the oldest method and the least automated.

Why DNS validation is often the better choice

HTTP validation breaks if the site is behind a CDN, not yet deployed, or redirecting all traffic to HTTPS before the cert exists. DNS validation sidesteps all of that: a TXT record proves control without the site being up, and it is the only route to a wildcard. The trade-off is that your DNS must be reachable and the record correctly published, including surviving propagation delays.

When issuance stalls

The usual failures: the HTTP challenge file is blocked by a redirect to HTTPS, the DNS TXT record has not propagated yet, or a CAA record on the domain forbids the CA you chose. Checking that the validation record is actually visible from the public internet is the fastest way to unblock issuance.

You can confirm a domain's DCV-related DNS records resolve correctly with the Alt DCV Checker. If a CAA record is the blocker, the DNS records explained guide covers how those records work.