Domains & DNS

CAA Records – Controlling Who Can Issue SSL for Your Domain

CAA records tell certificate authorities which ones are allowed to issue SSL for your domain - what they do, when to add them, and how to avoid breaking AutoSSL.

5 min read

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 authorityCAA identifier
Let’s Encrypt (AutoSSL default)letsencrypt.org
Sectigo / Comodosectigo.com
DigiCertdigicert.com
GlobalSignglobalsign.com
GoDaddy / Starfieldgodaddy.com, starfieldtech.com
Google Trust Servicespki.goog
ZeroSSLsectigo.com (uses Sectigo backend)
Amazonamazon.com, amazontrust.com
Cloudflareletsencrypt.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

  1. cPanel → Zone Editor.
  2. Add Record → Type: CAA.
  3. Name: yourdomain.com (or @).
  4. Flag: 0.
  5. Tag: issue.
  6. Value: “letsencrypt.org” (with quotes).
  7. Save.
  8. 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

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?