CAA Records Explained: Stop Them From Blocking Your SSL

You renew a certificate, AutoSSL says it succeeded, and the browser still shows an error — or worse, issuance fails outright with no obvious reason. Nine times out of ten when this happens on a domain that's been migrated or had DNS touched by a previous host, the culprit is a CAA record nobody remembers adding. It's one line of DNS, and it can silently veto every certificate authority except the one it names.

What a CAA Record Actually Does

CAA stands for Certification Authority Authorization. It's a DNS record that tells certificate authorities (CAs) which of them are allowed to issue SSL/TLS certificates for your domain. If a CA isn't listed, it's required by industry rule (the CA/Browser Forum baseline requirements) to refuse issuance — no warning email, no error on your end, it just fails.

Before 2017 this record type barely mattered because almost nobody set one. Today it matters a lot more because AutoSSL, Let's Encrypt, Cloudflare, and most managed SSL tools issue and renew certificates automatically in the background, and a stray CAA record can quietly break that automation for months before anyone notices.

Symptom: Certificate Renewal Fails With No Clear Reason

What this usually looks like in the wild:

• cPanel's AutoSSL history shows a failure for one domain or subdomain, with a message like CAA record prevents issuance or rejected by CAA policy.
• A Certbot renewal on a VPS fails with urn:ietf:params:acme:error:caa in the ACME error response.
• The main domain renews fine but an addon domain or subdomain fails, because it inherited a CAA record from a prior DNS provider or a wildcard rule that wasn't updated.
• You switched CAs (say, from Sectigo to Let's Encrypt, or vice versa) after a migration, and issuance that used to work now doesn't.

The frustrating part is that everything else about the domain looks normal — A record resolves, the site loads over the old certificate, DNS propagation checks come back clean. CAA failures don't show up in a typical DNS lookup unless you specifically query for them.

Cause: A Restrictive or Stale CAA Record

A CAA record has three parts: a flag, a tag, and a value. The tag is what matters most day to day:

A record like this:

example.com.  CAA  0 issue "sectigo.com"

...means only Sectigo can issue standard certificates for example.com. If your host's AutoSSL uses Let's Encrypt (the default on most cPanel servers now) and nobody added letsencrypt.org to the record, every renewal attempt gets rejected. If there's no CAA record at all, every CA is implicitly allowed — which is why domains that have never had one set almost never see this problem, and domains that inherited one during a migration are the usual victims.

Two other things trip people up:

• Wildcards need issuewild, not just issue. If you're requesting a wildcard cert (*.example.com) and only an issue record exists, some CAs will still refuse it even if the same CA is listed, because the wildcard tag was never added.
• Subdomains can carry their own CAA record. DNS resolvers walk up the tree, so if shop.example.com has no CAA record of its own, the CA checks example.com's record instead. But if someone added a restrictive record directly on the subdomain, it overrides the parent — and that's easy to forget it's there.

Fix: Check the Record, Then Correct It

Start by actually looking at what's published. From any machine with a terminal:

dig CAA example.com +short

Or on Windows:

nslookup -type=CAA example.com

If that returns nothing, CAA isn't your problem — look elsewhere (DCV failures, rate limits, or a firewall blocking port 80/443 validation traffic are the other common AutoSSL culprits). If it returns a record naming a CA other than the one your host uses, that's your fix target.

In cPanel:

1. Log in to cPanel and open Zone Editor under the Domains section.
2. Select the domain, click Manage, then look for existing CAA type records.
3. To allow Let's Encrypt (the CA most cPanel AutoSSL setups use by default), add or edit a record with tag issue and value letsencrypt.org. If you also issue wildcards, add a second record with tag issuewild and the same value.
4. If an old restrictive record is pointing to a CA you no longer use, delete it rather than trying to layer a new one on top — multiple CAA records are additive (any CA listed in any of them is allowed), so an outdated one won't block you, but a leftover typo'd or overly narrow one still can.
5. Save, then wait for the TTL to expire (see the propagation note below) before re-running AutoSSL.

On a VPS managing DNS elsewhere (Cloudflare, Route 53, your registrar's DNS), the process is the same conceptually — add a CAA record via that provider's DNS panel with the same tag/value pairs. Cloudflare in particular ships a CAA record wizard that lists common CAs by name, which avoids typos.

Once the record is updated, force a retry instead of waiting for the next scheduled run:

# cPanel/WHM, as root
/usr/local/cpanel/bin/autossl_check --user=cpaneluser

# Certbot on a plain VPS
certbot renew --force-renewal -d example.com

Prevention: Don't Let This Bite You Twice

• Audit CAA records after any DNS or host migration. They're one of the few record types that don't get regenerated automatically by most migration tools, so they either come across stale or get dropped and silently default-allow, which is usually fine but worth confirming.
• If you don't need to restrict CAs, don't add the record at all. A lot of the tickets we see are self-inflicted — someone added a CAA record years ago for a compliance push and forgot about it. Unless you have a specific reason to lock issuance to one CA, an absent CAA record is the lowest-maintenance option.
• If you do restrict CAs, list every CA you actually use — including both the primary and any backup (some hosts fail over from Let's Encrypt to a paid CA automatically if rate limits are hit).
• Set a reasonable TTL (3600 seconds is a good default) on CAA records specifically, so that if you do need to change the policy in an emergency, it doesn't take a full day to take effect.

CAA is a small record with an outsized ability to break automated SSL renewal quietly. A five-minute dig check is usually all it takes to confirm whether it's your problem — and if it is, the fix is a one-line DNS edit, not a support ticket.