Fixing cPanel/WHM AutoSSL "DNS DCV" Renewal Failures

Nothing generates panicked support tickets faster than an expired SSL certificate. A client navigates to their e-commerce store or corporate portal, only to be blocked by a massive, red "Your connection is not private" warning in their browser.

You log into your EPY Host dedicated server, navigate to WHM, and manually trigger the AutoSSL check for their cPanel account, expecting a quick fix. Instead, the process grinds to a halt, spitting out a massive block of red error text that looks something like this:

DNS DCV: The DNS query to “_cpanel-dcv-test-record.example.com” for the TXT record types failed.
WARN Local HTTP DCV error: The system failed to fetch the DCV file...
cPanel SSL renewal failed: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com

You are now facing a WHM AutoSSL DNS DCV error.

This error is incredibly frustrating because it is rarely a problem with the server's internal SSL configuration. Instead, it is almost always a failure of external trust. The Certificate Authority (like Let's Encrypt or cPanel/Sectigo) is trying to verify that your server actually controls the domain name, and something in the network or DNS zone is violently rejecting that verification.

In this comprehensive, step-by-step tutorial, we will break down exactly what Domain Control Validation (DCV) is, and we will walk you through the four most common culprits causing these failures: misconfigured IPv6 records, conflicting CAA records, nameserver mismatches, and overzealous firewalls.

What You'll Learn

Phase 1: Understanding the Enemy (What is DCV?)

Before we start deleting DNS records, you need to understand the mechanism that is failing.

When AutoSSL requests a free certificate, the Certificate Authority (CA) must cryptographically prove that the server making the request actually hosts the domain. It cannot simply take your server's word for it. To prove ownership, the CA performs Domain Control Validation (DCV).

AutoSSL automatically attempts two types of DCV simultaneously:

• HTTP DCV: The server creates a temporary, hidden text file in the website's public_html/.well-known/pki-validation/ directory. The CA attempts to visit that file over the internet using a standard web browser request.

• DNS DCV: The server creates a temporary TXT record in the domain's DNS zone file. The CA queries the global DNS system to read that TXT record.

If both of these checks fail, the CA denies the certificate, and you get the massive red error log. Because HTTP DCV often fails due to forced HTTPS redirects or .htaccess rewrite rules, WHM relies heavily on DNS DCV as the ultimate fallback. When DNS DCV fails, the renewal process is completely dead.

Here is how to hunt down the blockages and fix them.

Phase 2: The AAAA (IPv6) Record Trap

This is arguably the most common and least understood cause of a cPanel SSL renewal failed error, especially when using the Let's Encrypt AutoSSL provider.

Let's Encrypt heavily prioritizes IPv6. When it attempts to validate your domain, it first looks for an AAAA record (the IPv6 equivalent of an A record). If an AAAA record exists, Let's Encrypt will only attempt to connect to that IPv6 address. It will completely ignore your perfectly functioning IPv4 A record.

The Frustration

Clients often migrate their websites to your EPY Host dedicated server and update their IPv4 A record, but they forget to update (or delete) their old host's AAAA record. The website loads fine for most users (who fall back to IPv4), but when Let's Encrypt tries to run the HTTP DCV check, it connects to the old server's IPv6 address, fails to find the validation file, and crashes the renewal.

How to Fix the AAAA Record Conflict

1. Log in to WHM as the root user.

2. Navigate to DNS Functions > DNS Zone Manager.

3. Search for the failing domain name and click Manage.

4. Filter the records by selecting AAAA from the dropdown menu.

5. Look at the IPv6 address listed. Does your dedicated server actually use IPv6? If yes, is the address correct?

6. If the domain does not actively need IPv6 routing, or if the AAAA record points to an old hosting provider, click Delete next to the record.

By removing the stale AAAA record, you force the Certificate Authority to use your correct IPv4 A record for the validation check.

Phase 3: Removing the CAA Record Block

A Certificate Authority Authorization (CAA) record is a strict DNS policy. It is a security feature that allows a domain owner to specify exactly which Certificate Authorities are legally allowed to issue SSL certificates for their domain.

The Frustration

If a domain has a CAA record that says issue "digicert.com", and your WHM server is trying to use Let's Encrypt or the cPanel Sectigo provider, the validation will be instantly rejected. The Certificate Authority looks at the DNS zone, sees it is not on the VIP list, and aborts the operation, resulting in a CAA record SSL block error in your AutoSSL logs.

This frequently happens when clients migrate from enterprise environments or previous hosts that enforced strict CAA policies.

How to Fix the CAA Record Block

1. In WHM, navigate to DNS Functions > DNS Zone Manager.

2. Search for the failing domain and click Manage.

3. Filter the records by selecting CAA from the dropdown menu.

4. If a CAA record exists, review its value.

5. If you are using the cPanel AutoSSL provider (Sectigo), the CAA record must explicitly allow sectigo.com. If you are using the Let's Encrypt plugin, it must explicitly allow letsencrypt.org.

6. The easiest and most common fix is to simply Delete the CAA record entirely. Unless your client has strict corporate compliance requirements mandating a CAA policy, deleting it removes the restriction and allows any valid CA to issue the certificate.

Phase 4: Resolving NXDOMAIN and Nameserver Mismatches

Sometimes, the AutoSSL log will explicitly state: fix Let's Encrypt DNS problem NXDOMAIN.

NXDOMAIN translates to "Non-Existent Domain." This means when the Certificate Authority asked the global internet where your domain was, the internet replied, "I have no idea what you are talking about."

This happens when the DNS zone file exists locally on your WHM server, but the domain's actual registrar (e.g., GoDaddy, Namecheap) is pointing the domain to a completely different set of Nameservers (like Cloudflare or an old host).

When AutoSSL generates the temporary _cpanel-dcv-test-record TXT record, it places it in your local WHM DNS zone. But the Certificate Authority queries the public nameservers. If they do not match, the CA never sees the TXT record.

How to Fix Nameserver Mismatches

1. Open a new tab in your web browser and go to a public DNS checker tool (like intoDNS.com or mxtoolbox.com).

2. Enter the failing domain name.

3. Look at the NS (Nameserver) records reported by the global root servers.

4. Now, compare those nameservers to the ones configured on your EPY Host dedicated server (in WHM under Server Configuration > Basic WebHost Manager Setup).

Scenario A: The Client uses Cloudflare

If the domain is routed through Cloudflare, DNS DCV on your local server will always fail because Cloudflare controls the DNS.

• The Fix: You must ensure the cloud icon is temporarily "grey-clouded" (DNS only) in Cloudflare, OR you must rely entirely on HTTP DCV. If relying on HTTP DCV, ensure there are no .htaccess rules redirecting HTTP to HTTPS before the certificate is issued.

Scenario B: Stale Registrar Nameservers

If the registrar is pointing to ns1.oldhost.com, but your server uses ns1.epyhost.com.

• The Fix: You must contact the client and instruct them to log into their domain registrar and update the Nameservers to point to your dedicated server. Once the global DNS propagation completes (which can take 2 to 24 hours), the DNS DCV check will pass automatically.

Phase 5: Unblocking Validation IPs in Your Firewall

If your DNS records are perfectly clean, your nameservers match, and you are still failing the HTTP DCV fallback, you likely have a network block.

Security-conscious administrators often install ConfigServer Security & Firewall (CSF) or heavily configure Firewalld on their dedicated servers. If your firewall is configured to block traffic from specific countries, or if it aggressively bans IPs that scan your server, it might have accidentally banned the Certificate Authority's validation servers.

If the CA cannot reach your server's port 80 (HTTP) to read the validation text file, the certificate renewal will fail.

How to Fix Firewall Blocks in CSF

1. In WHM, scroll down to the Plugins section and click on ConfigServer Security & Firewall.

2. You need to ensure that the IPs used by Let's Encrypt or Sectigo are whitelisted.

3. Click on the Firewall Allow IPs (csf.allow) button.

4. While Let's Encrypt does not publish a static list of validation IP addresses (they purposefully validate from multiple global locations to prevent DNS spoofing), you must ensure that Port 80 is strictly open to the public.

5. Check your csf.conf file by clicking Firewall Configuration. Ensure that 80 is listed in the TCP_IN and TCP6_IN fields.

6. If you use GeoIP blocking (e.g., blocking traffic from Europe), you must disable it or whitelist the US and EU, as Let's Encrypt validation servers frequently operate out of these regions.

7. Restart the firewall by clicking csf -r to apply any changes.

Phase 6: Forcing the AutoSSL Check

Once you have deleted the conflicting AAAA record, removed the strict CAA policy, verified your nameservers, and opened your firewall, it is time to force WHM to try again.

Do not wait for the nightly cron job. You can manually push the queue to resolve the issue immediately.

1. In WHM, navigate to SSL/TLS > Manage AutoSSL.

2. Click on the Manage Users tab.

3. Use the search box to find the specific cPanel user experiencing the failure.

4. Click the Check “username” button.

5. Navigate back to the Logs tab in the AutoSSL interface. Select the most recent log file and click View Log.

Scroll past the initial setup lines. Instead of the massive red WARN blocks, you should now see glorious green text:

SUCCESS The system has installed the new certificate for the “example.com” domain.

Conclusion

The WHM AutoSSL DNS DCV error looks incredibly intimidating, but it is ultimately just a communication breakdown. The Certificate Authority wants to give you a secure lock for your website, but it needs to verify your identity first.

By systematically checking for stale IPv6 routing, removing restrictive CAA authorization rules, ensuring global DNS nameservers match your local zone, and keeping your firewall's port 80 open for HTTP fallback, you remove all the roadblocks preventing that verification.

SSL management is a critical component of dedicated server administration. If you have checked all these boxes and your certificates are still refusing to issue, there may be a deeper routing issue within your server's NAT configuration or .htaccess rewrite loops.