A customer wrote in last week convinced their domain was cursed. AutoSSL kept failing, Let's Encrypt's own certbot on their VPS threw a cryptic urn:ietf:params:acme:error:caa error, and nothing in cPanel or their DNS looked obviously wrong. The culprit turned out to be four lines in their DNS zone that almost nobody adds on purpose: a CAA record left over from a previous host, quietly telling every certificate authority except one that it wasn't allowed to issue for that domain.
CAA records are one of the least understood DNS record types, mostly because everything works fine until the one day it doesn't. Here's what they actually do and how to fix them when they get in the way.
Symptom
You're dealing with a CAA problem if you see any of these:
- cPanel's AutoSSL log shows a Domain Control Validation (DCV) failure even though the domain resolves correctly and the A record is right
- Certbot on a VPS fails with
Error creating new order :: Policy forbids issuing for this name :: CAA record for <domain> prevents issuance - One certificate authority (say, Sectigo through your host) issues fine, but Let's Encrypt on a different service fails for the same domain
- SSL worked for months, then failed right after a DNS migration or a domain transfer between registrars
Cause
A CAA (Certification Authority Authorization) record is a DNS entry that lists which certificate authorities are allowed to issue SSL/TLS certificates for a domain. It was made mandatory for CAs to check back in 2017 — if a CAA record exists and doesn't name the CA trying to issue a cert, that CA is required to refuse, full stop. No override, no manual bypass on their end.
Most domains have no CAA record at all, which means any CA may issue. Problems start when one gets added — often by a previous hosting provider, a security-conscious admin locking things down, or a domain reseller's default template — and then forgotten. Common triggers we see:
| Situation | What Happens |
|---|---|
| Old host added a CAA record naming only their CA | AutoSSL or certbot from a new host gets silently refused |
| CAA record lists letsencrypt.org but domain moved to Sectigo-backed AutoSSL | cPanel's default AutoSSL provider fails DCV |
| Record only covers the apex domain, not www or subdomains | Wildcard or subdomain certs fail while the main domain succeeds |
| Typo in the CA hostname (e.g. letsencrpyt.org) | Every CA gets rejected because the record is technically present but names nothing valid |
Fix
First, check whether a CAA record even exists. From any machine with dig:
dig CAA yourdomain.com +shortNo output means no CAA record — the issue is elsewhere. If you get a line back like:
0 issue sectigo.comthat domain can only get certificates from Sectigo. Anything else, including Let's Encrypt, will be rejected.
To fix it in cPanel:
- Log in to cPanel and open Zone Editor under the Domains section
- Select the domain, click Manage, then look for existing CAA entries
- Edit or delete the record so it authorizes the CA you actually need. For most SkyServer AutoSSL setups (Let's Encrypt/Sectigo depending on your package), add:
yourdomain.com. CAA 0 issue letsencrypt.org
yourdomain.com. CAA 0 issue sectigo.com
yourdomain.com. CAA 0 issuewild letsencrypt.orgA few things that trip people up here:
issuecovers regular certificates;issuewildcovers wildcard certificates — you need both if you use a wildcard cert anywhere- List every CA you actually use. If you run AutoSSL through cPanel and a separate certbot instance on a VPS pointed at the same domain, both CAs need an entry
- An empty CAA value written as a semicolon means no CA may issue — useful for a domain that should never get a public cert, dangerous if added by accident
- You can add an iodef tag to get notified of policy violations, pointing it at a mailto address — optional, but handy if someone tries to issue a rogue cert against your name
If you're on a VPS managing your own DNS (BIND, PowerDNS, or an external provider like Cloudflare), the syntax is the same three fields — flag, tag, value — just added through whatever zone file or dashboard you use instead of cPanel's Zone Editor.
After saving, DNS changes for CAA typically propagate within the record's TTL — usually under an hour if the zone was already set to a short TTL. Re-run AutoSSL manually from WHM (SSL/TLS Status → select domain → Run AutoSSL) or re-run certbot once you've confirmed the record with dig again.
Prevention
- Check for a stray CAA record any time you migrate a domain between hosts or registrars — it's easy to forget it exists since it causes no visible problem until a renewal is due
- If you don't have a specific reason to restrict certificate authorities, it's simplest to have no CAA record at all rather than maintaining one
- When you do keep one, review it whenever you change SSL providers, add a wildcard cert, or add a new subdomain that needs its own certificate
- Bookmark an online CAA checker or just keep the dig CAA command handy — it takes ten seconds and saves a support ticket
Frequently Asked Questions
Do I need a CAA record at all?
No. Most domains work perfectly fine with none — that's treated as any CA may issue. Only add one if you specifically want to restrict which certificate authorities can issue for your domain, usually for compliance or security policy reasons.
Why did AutoSSL work for years and then suddenly fail?
Usually because something changed on the CA side or your side that wasn't touched in a long time — a certificate authority renamed or reorganized (Sectigo used to be Comodo CA, for instance), your host switched providers, or the record was added by a previous provider and only became a problem the next time a renewal ran.
Does a CAA record affect existing certificates?
No, it only affects new issuance and renewals. An already-issued certificate keeps working until it expires; the CAA check happens at issuance time, not at every page load.
Can a CAA record block subdomains but not the main domain?
Yes, if you only set it on the subdomain's own record and it differs from the apex. CAA records are inherited down the tree unless overridden, so a subdomain without its own CAA entry follows the parent domain's rule — but an explicit, different record on the subdomain takes precedence.
How do I know which CA my host actually uses for AutoSSL?
Check WHM under SSL/TLS or ask your host directly — cPanel installs typically use Let's Encrypt or Sectigo depending on the license and configuration. If you're not sure, the safest fix is to authorize both in your CAA record rather than guessing wrong.
