Bagaimana Cara Lulus Validasi Kontrol Domain (DCV)?

When you order an SSL/TLS certificate, the Certificate Authority won’t just hand it over. They need proof you actually control the domain you’re securing. That’s where Domain Control Validation (DCV) comes in. It’s the verification process that confirms domain ownership before any certificate gets issued.

This isn’t just bureaucratic red tape. DCV prevents attackers from obtaining valid certificates for domains they don’t own, which would completely undermine the trust model that keeps HTTPS secure. The CA/Browser Forum, the industry body that sets baseline requirements for certificate issuance, mandates specific DCV methods that all Certificate Authorities must follow.

In this guide, we’ll break down what DCV is, explore the different validation methods available, and help you choose the right approach for your infrastructure.

---

Table of Contents

1. What is Domain Control Validation (DCV)?
2. Email-Based Domain Validation Methods
3. DNS-Based DCV Methods
4. HTTP/HTTPS File-Based Validation Methods
5. Special Validation Scenarios
6. Choosing the Right DCV Method for Your Needs
7. Common DCV Issues and Quick Fixes

---

---

What is DCV (Domain Control Validation)?

Domain Control Validation (DCV) is the process Certificate Authorities use to verify domain ownership before issuing an SSL/TLS certificate. It confirms control by requiring the applicant to respond via email, upload a file to the domain, or configure DNS records to prove authority over the domain.

The process works like this: the CA generates a unique challenge (usually a random alphanumeric string), and you demonstrate control by responding through your domain’s infrastructure. This could be through DNS records, your web server, or administrative email addresses. Once validated, the CA knows they’re issuing the certificate to the legitimate domain owner, not someone trying to impersonate your site.

Industry Standards and Compliance

The CA/Browser Forum‘s baseline requirements define exactly how DCV must be performed. These aren’t suggestions, they’re strict rules that CAs must follow or risk losing their trusted status in browsers.

Current standards include:

• Validation must use one of the approved DCV methods (covered below)
• Multi-Perspective Issuance Corroboration (MPIC) requires validation from multiple network perspectives to prevent localized attacks
• Validation is reusable for 397 days for Organization Validated (OV) and Extended Validation (EV) certificates
• Domain Validated (DV) certificates can’t reuse validation, you must validate every time you renew

Here’s something important: these requirements are tightening. The industry is reducing maximum certificate lifespans and validation periods.

The CA/Browser Forum has defined a clear timeline for certificate lifetimes: they are now limited to 200 days as of March 15, 2026, with further reductions to 100 days from March 15, 2027, and 47 days starting March 15, 2029.

This tightening also affects validation cycles, making frequent revalidation and SSL certificate automation increasingly necessary.

---

Email-Based Domain Validation Methods

1. Constructed Email Verification

Email validation is the most common DCV method because it’s simple and requires no technical changes to your infrastructure. The CA sends an email containing a validation link or code to specific addresses at your domain.

The CA will try these generic email addresses:

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]

You don’t need all of these set up, just one working address from the list. The CA checks your domain’s MX records to confirm email can be delivered, then sends the validation request.

When the email arrives, you’ll click a verification link or copy a code back into the certificate ordering platform. The process usually takes just a few minutes if your email is properly configured.

This method works great if:

• You have established email infrastructure for your domain
• You’re ordering certificates occasionally, not at scale
• You want the simplest validation process with no DNS or web server changes

The downside? You can’t automate it easily, and if your email goes down or the addresses aren’t monitored, your validation will fail.

2. Email to DNS TXT Contact

This variation combines email with DNS. Instead of using generic addresses, you publish a specific email address in a DNS TXT record at _validation-contactemail.yourdomain.com. The CA reads this record and sends validation to that address.

Why use this approach?

• Reusability: Once configured, it remains valid for the full validation period
• Centralized control: You decide exactly which email receives validation requests
• Team-friendly: Point it to a distribution list, not someone’s personal inbox

Here’s the practical setup:

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

Just create this DNS TXT record with your preferred contact email, and the CA will use it automatically. This is particularly useful for organizations managing multiple certificates. You can standardize validation across all domains through one monitored inbox.

---

DNS-Based DCV Methods

1. DNS TXT Record Validation

DNS TXT record validation is popular for its flexibility and automation potential. When you order a certificate, the CA provides a specific hostname and validation token that you add as a TXT record to your domain’s DNS.

The basic process:

1. The CA provides a hostname (typically _dvsauth.yourdomain.com) and token during certificate ordering
2. You create the TXT record with that token as the value
3. The CA queries your DNS to confirm the record exists
4. Once verified, they issue the certificate

The record typically looks like this:

_dvsauth.yourdomain.com. IN TXT "ab1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q"

DNS TXT validation is ideal for:

• Automation – DNS APIs make this scriptable through ACME clients or custom tools
• Environments without web servers – you only need DNS access
• Wildcard certificates – we’ll cover this requirement in the Special Scenarios section

One thing to watch: DNS propagation time. If your nameservers have high TTL values or slow propagation, validation might take longer. Most CAs will retry for 24 hours, but it’s best to set lower TTL values before adding validation records.

2. DNS CNAME Record Method

CNAME validation uses a different record type but achieves the same goal. Instead of storing the validation token directly, you create a CNAME that points to a validation target controlled by the CA.

Example configuration:

_dnsauth.yourdomain.com. IN CNAME random-token.dcv.digicert.com.

The key difference: the CNAME points to a record the CA controls, which means they can update the validation target without you changing DNS. Some CAs also allow this for domain prevalidation, you set up the CNAME once, and they can validate whenever you order certificates.

CNAME validation works well when:

• Your DNS provider makes CNAMEs easier to manage than TXT records
• You want domain prevalidation capability for OV/EV certificates
• You’re working with CAs that support CNAME-based validation flows

Not all CAs offer CNAME validation, so check with your provider. But when available, it’s a solid option for teams that prefer this DNS record type.

---

---

HTTP/HTTPS File-Based Validation Methods

1. HTTP Practical Demonstration

File-based validation requires you to place a specific file on your web server at a designated path. The CA then accesses this file via HTTP or HTTPS to confirm you control the server hosting the domain.

The standard path is: http://yourdomain.com/.well-known/pki-validation/fileauth.txt

The CA provides both the exact filename and the content. You create this file on your server, ensure it’s accessible, and the CA validates by fetching it.

Critical implementation points:

• The file must be accessible on port 80 (HTTP) or port 443 (HTTPS)
• The .well-known directory is a standard location defined in RFC 8615
• This is required for IP address validation. If you’re getting a certificate for an IPv4 or IPv6 address, HTTP validation is typically your only option

File-based validation is straightforward if you have direct web server access. It’s less ideal if you’re using hosting services with restricted file system access or CDNs that might cache or interfere with validation requests.

Troubleshooting tips:

• Make sure redirects don’t interfere. The CA must reach the exact validation URL
• Check that firewalls allow HTTP/HTTPS access
• Disable caching for the validation directory
• Verify the file permissions allow public read access

2. ACME Challenge Integration

ACME (Automated Certificate Management Environment) protocol uses HTTP-01 and DNS-01 challenges for automated DCV. If you’re using Let’s Encrypt or another ACME-compatible CA, your ACME client handles the entire validation process automatically.

HTTP-01 challenge: Places a validation file at /.well-known/acme-challenge/ (similar to standard HTTP validation)

DNS-01 challenge: Creates a TXT record at _acme-challenge.yourdomain.com

Your client (like Certbot, acme.sh, or integrated tools in platforms like cPanel) handles validation and certificate renewal without manual intervention. ACME has become the standard for automated certificate management, particularly for organizations managing large certificate inventories.

---

Special Validation Scenarios

1. Multi-Domain and SAN Certificate Validation

If you’re ordering a multi-domain certificate (also called SAN or UCC certificates), you must validate each domain separately. A single DCV check doesn’t cover all domains on the certificate.

Example: A certificate for example.com, www.example.com, and shop.example.com requires three separate validations, even though they’re related domains.

The good news? You can mix validation methods. Use email validation for one domain and DNS validation for another if that matches your infrastructure. The CA’s platform will track validation status for each domain and only issue the certificate once all domains are verified.

2. Wildcard Domain Validation

Wildcard certificates (covering *.example.com) require DNS-based validation methods. Most CAs won’t accept email or HTTP validation for wildcards due to security considerations.

Why DNS validation for wildcards?

Wildcard certificates secure unlimited subdomains. File-based validation could only prove control of one subdomain at a time, and email validation doesn’t demonstrate control over all possible subdomains. DNS validation proves you control the entire domain’s DNS infrastructure, which is appropriate for a certificate that protects all subdomains.

If you need a wildcard certificate, plan on using DNS TXT or CNAME validation. These are typically your only options.

3. Subdomain Validation Considerations

You can validate at the subdomain level or parent domain level, depending on the validation method. For HTTP validation, the file must be accessible at the specific subdomain you’re validating. For DNS validation, you create records at the appropriate subdomain level.

One important distinction: Validating the parent domain (example.com) doesn’t automatically validate subdomains (blog.example.com) for most validation methods. Each subdomain needs its own validation unless you’re using a wildcard certificate.

---

Choosing the Right DCV Method for Your Needs

Match the method to your infrastructure:

Compare All DCV Methods at a Glance

Validation Method	Time to Complete	Automation Capability	Technical Skill	Wildcard Support	Reusability (OV/EV)	Best For
Email (Generic)	5-30 minutes	❌ Low	⭐ Minimal	✅ Yes	❌ No	One-off certificates, small deployments
Email (DNS TXT)	15-60 minutes	❌ Low	⭐⭐ Low-Moderate	✅ Yes	✅ Yes (397 days)	Teams with multiple certs, established email
DNS TXT Record	10-60 minutes	✅ High	⭐⭐⭐ Moderate	✅ Yes	✅ Yes (397 days)	Automation, wildcards, large deployments
DNS CNAME	15-60 minutes	✅ High	⭐⭐⭐ Moderate	✅ Yes	✅ Yes (397 days)	Domain prevalidation, CA-managed tokens
HTTP File	5-20 minutes	⚠️ Medium	⭐⭐ Low-Moderate	❌ No	❌ No	Direct server access, IP addresses
ACME (HTTP-01)	2-10 minutes	✅ Very High	⭐⭐⭐⭐ Moderate-High	❌ No	N/A (auto-renewal)	Full automation, Let’s Encrypt
ACME (DNS-01)	2-10 minutes	✅ Very High	⭐⭐⭐⭐ Moderate-High	✅ Yes	N/A (auto-renewal)	Full automation with wildcards

Method Selection by Scenario

Use email validation if:

• You have simple, one-off certificate orders
• Generic admin email addresses are monitored
• You don’t need automation

Use DNS TXT/CNAME validation if:

• You need wildcard certificates
• You’re managing multiple certificates
• You don’t have web server access
• You want automation capabilities

Use HTTP file validation if:

• You have direct web server access
• You’re validating IP addresses
• DNS changes are difficult in your organization

---

Common DCV Issues and Quick Fixes

Validation failures happen. Here are the most frequent errors you’ll encounter and how to resolve them quickly.

HTTP File Validation: “404 Not Found”

Error: “The system queried for a temporary file at http://example.com/.well-known/pki-validation/[filename].txt, but the web server responded with the following error: 404 (Not Found).”

Quick fixes:

• Manually create the directory structure: /public_html/.well-known/pki-validation/
• Set permissions: directories to 755, files to 644
• Check .htaccess rules that might block the /.well-known/ path
• If domain was just added, wait 24-48 hours for propagation
• Test accessibility: curl -v http://yourdomain.com/.well-known/pki-validation/test.txt

Common cause: The validation file path doesn’t exist or isn’t publicly accessible.

HTTP Validation: “Forbids DCV HTTP Redirections”

Error: “cPanel (powered by Sectigo) forbids DCV HTTP redirections.”

Quick fixes:

• Temporarily disable redirects to HTTPS during validation
• Exclude /.well-known/* path from redirect rules
• Check .htaccess, Cloudflare page rules, or server config for redirects
• If using CDN, temporarily disable or add exception

Common cause: Your site redirects HTTP to HTTPS or redirects to another domain, blocking the CA’s validation attempt.

DNS Validation: “No TXT Record That Matches”

Error: “The DNS query to ‘_dvsauth.example.com’ for the DCV challenge returned no ‘TXT’ record that matches the value ‘[expected-value]’.”

Quick fixes:

• Wait 1-24 hours for DNS propagation (depends on TTL)
• Verify the exact hostname and value: dig _dvsauth.example.com TXT +short
• Check for copy/paste errors in the validation token
• If using delegated DNS (NS records), add the TXT record at the correct provider
• Lower TTL to 300 seconds (5 minutes) before adding validation records

Common cause: DNS hasn’t propagated yet, or the record has typos.

DNS Validation: CAA Records Blocking Issuance

Error: “Certificate authority encountered a multiple perspective CAA check error.”

Quick fixes:

• Check existing CAA records: dig example.com CAA
• Add your CA to allowed issuers: example.com. CAA 0 issue “digicert.com”
• Verify CAA records resolve globally using ping.pe tool
• If no CAA records exist, you don’t need to add any (absence allows all CAs)

Common cause: CAA records restrict which CAs can issue certificates for your domain.

Email Validation: Email Not Received

Quick fixes:

• Check spam/junk folders first
• Verify these addresses exist and receive email: admin@, administrator@, webmaster@, hostmaster@, postmaster@
• Check MX records: dig example.com MX
• Whitelist the CA’s email sending domains in your spam filter
• Request email resend from the CA’s control panel

Common cause: Validation email caught by spam filters or admin addresses don’t exist.

Platform-Specific: cPanel AutoSSL Failures

Error: “Local HTTP DCV error: An internal error occurred.”

Quick fixes:

• Check WHM > Manage AutoSSL logs for details
• Wait 30 minutes and retry (often resolves automatically)
• Switch between Sectigo and Let’s Encrypt providers
• Clear AutoSSL queue: WHM > Manage AutoSSL > Clear pending queue

Quick Diagnostic Commands

Before contacting support, run these checks:

# Verify DNS propagation
dig yourdomain.com +short
dig _dvsauth.yourdomain.com TXT +short

# Test HTTP file accessibility
curl -v http://yourdomain.com/.well-known/pki-validation/test.txt

# Check CAA and MX records
dig yourdomain.com CAA
dig yourdomain.com MX

---

Simplify Your SSL Certificate Management with SSL Dragon

Getting domain control validation right is crucial for smooth certificate deployment. SSL Dragon offers certificates from trusted Certificate Authorities with all the validation methods you need, whether you prefer email, DNS, or HTTP-based verification.

Our team helps you navigate DCV requirements for Domain Validated, Organization Validated, and Extended Validation certificates. We’ll walk you through the validation method that matches your infrastructure and answer questions when validation issues come up.

Stop wrestling with certificate validation. Browse our SSL certificate options!