A CAA (Certification Authority Authorization) record is a DNS entry that tells certificate authorities (CAs) “only these specific CAs are allowed to issue SSL certificates for my domain.” Any CA must check CAA before issuing. If their name isn’t listed, they must refuse. CAA defends against unauthorized certificates — including those an attacker might trick a CA into issuing. This guide explains what CAA does, when to add it, and how not to break your own SSL setup.
What CAA protects against
Without CAA, ANY of the ~80 trusted certificate authorities can issue a cert for your domain. If an attacker socially engineers one CA into issuing a cert for yourdomain.com (or compromises one), they get a valid SSL cert browsers will trust.
With CAA listing only Let’s Encrypt, any other CA receiving a request for your domain must refuse — even if they would have otherwise issued.
Required by the CA/Browser Forum since 2017. All major CAs check CAA before issuing.
CAA record syntax
yourdomain.com. IN CAA 0 issue "letsencrypt.org"
yourdomain.com. IN CAA 0 issuewild "letsencrypt.org"
yourdomain.com. IN CAA 0 iodef "mailto:security@yourdomain.com"
Components:
- flags (0 here) — Reserved; usually 0.
- tag — “issue” for regular certs, “issuewild” for wildcards, “iodef” for incident reporting.
- value — The CA’s identifier (a domain name).
Common CA identifiers
| Certificate authority | CAA identifier |
|---|---|
| Let’s Encrypt (AutoSSL default) | letsencrypt.org |
| Sectigo / Comodo | sectigo.com |
| DigiCert | digicert.com |
| GlobalSign | globalsign.com |
| GoDaddy / Starfield | godaddy.com, starfieldtech.com |
| Google Trust Services | pki.goog |
| ZeroSSL | sectigo.com (uses Sectigo backend) |
| Amazon | amazon.com, amazontrust.com |
| Cloudflare | letsencrypt.org, comodoca.com, digicert.com, ssl.com |
For iWebVault hosting
iWebVault uses Let’s Encrypt for AutoSSL. Minimum recommended CAA:
yourdomain.com. IN CAA 0 issue "letsencrypt.org"
yourdomain.com. IN CAA 0 issuewild "letsencrypt.org"
If you also use Cloudflare (proxied), add Cloudflare’s CAs:
yourdomain.com. IN CAA 0 issue "letsencrypt.org"
yourdomain.com. IN CAA 0 issue "comodoca.com"
yourdomain.com. IN CAA 0 issue "digicert.com"
yourdomain.com. IN CAA 0 issue "ssl.com"
Cloudflare uses various CAs for edge certs. Restricting to only letsencrypt.org breaks Cloudflare’s universal SSL.
Adding CAA via cPanel
- cPanel → Zone Editor.
- Add Record → Type: CAA.
- Name: yourdomain.com (or @).
- Flag: 0.
- Tag: issue.
- Value: “letsencrypt.org” (with quotes).
- Save.
- Repeat for “issuewild” if you use wildcard certs.
Some Zone Editors don’t show CAA type. Use Cloudflare or another DNS host that supports it if needed.
Verifying CAA is set
dig CAA yourdomain.com
Returns your CAA records. If empty, no CAA — meaning all CAs may issue.
Online tool: caatest.co.uk or sslmate.com/caa.
Common pitfall: AutoSSL stops renewing
Most common CAA disaster: you set CAA to allow “sectigo.com” (because you read about it elsewhere) but AutoSSL uses Let’s Encrypt. AutoSSL renewal fails because CA can’t issue.
Symptom: SSL/TLS Status in cPanel shows AutoSSL errors mentioning CAA.
Fix: add “letsencrypt.org” to CAA records.
Wildcard certificates require “issuewild”
“issue” allows regular certs; “issuewild” allows wildcards (*.yourdomain.com). They’re separate:
- Only “issue” set — wildcards refused.
- Only “issuewild” set — regular certs refused but wildcards OK.
- Both set — both allowed.
For full coverage, set both.
The iodef tag
yourdomain.com. IN CAA 0 iodef "mailto:security@yourdomain.com"
Tells CAs where to report attempts to issue unauthorized certs. If someone tries to get a cert for your domain from a non-authorized CA, they email your security address.
Useful for high-security sites. Optional.
Subdomain handling
CAA inherits down the tree. CAA on yourdomain.com applies to all subdomains UNLESS a subdomain has its own CAA record.
Override for specific subdomain:
blog.yourdomain.com. IN CAA 0 issue "digicert.com"
blog.yourdomain.com now allows DigiCert; the parent’s restriction doesn’t apply to it.
Empty CAA on subdomain blocks everything: subdomain CAA 0 issue ";" — useful to disallow ALL cert issuance for a subdomain.
When NOT to add CAA
- You don’t know which CAs your hosting uses. Wrong restriction breaks SSL renewal.
- You use multiple unrelated services on the same domain. Each may need different CAs.
- You frequently migrate hosting providers. New provider may use different CA.
For most small sites, simple CAA listing Let’s Encrypt (or no CAA at all) is fine. Real benefit comes when you’ve audited what cert authorities you actually use.
Common questions
“Is CAA required?” No. Sites without CAA work fine — any CA may issue. CAA is hardening.
“My AutoSSL stopped renewing after I added CAA.” CAA doesn’t list letsencrypt.org. Add it.
“How long does CAA changes take to apply?” Standard DNS propagation (typically minutes). CAs check at issuance time, so changes apply immediately to new cert requests.
“Can I list multiple CAs?” Yes — add multiple CAA records. Each is one allowed CA.
“My DNS host doesn’t support CAA records.” Switch DNS to a host that does — Cloudflare (free), iWebVault DNS (if supported by your edition), AWS Route 53. All major modern DNS providers support CAA.
“Does CAA matter if I use Cloudflare proxy?” Cloudflare manages edge certs separately. CAA still affects any cert issued at your origin for the domain.
What’s next
- SSL setup: Installing SSL.
- HSTS for HTTPS enforcement: HSTS.
- DNS basics: DNS records overview.
CAA is a small DNS addition with meaningful security benefit — once you know which CAs your stack uses. The disaster mode is forgetting Let’s Encrypt and breaking AutoSSL. For most iWebVault sites, the safe minimal CAA is just letsencrypt.org for both issue and issuewild; add others if and only if you actively use them.
Was this helpful?
Thanks for your feedback!