The Problem CAA Solves

Hundreds of Certificate Authorities (CAs) are trusted by major browsers. Any of them can, in principle, issue an SSL certificate for any domain β€” including yours. Most are well-run; a few have been compromised or misissued certificates over the years.

If a malicious or compromised CA issues a certificate for yourdomain.com, an attacker holding that certificate can impersonate your site without browsers warning users. This is the threat model CAA records address.

A CAA (Certification Authority Authorization) record is a DNS entry that explicitly lists which CAs are allowed to issue certificates for your domain. CAs are required to honor it β€” issuing a certificate for a domain whose CAA record forbids them is grounds for browser distrust of the CA itself.

What a CAA Record Looks Like

A typical record:

example.com. IN CAA 0 issue "letsencrypt.org"

Reading it: "The CA identifier is letsencrypt.org. Only Let's Encrypt may issue certificates for example.com or its subdomains."

You can specify multiple CAA records to authorize multiple CAs:

  • example.com. IN CAA 0 issue "letsencrypt.org"
  • example.com. IN CAA 0 issue "digicert.com"
  • example.com. IN CAA 0 issue "sectigo.com"

And to disallow wildcard issuance separately:

  • example.com. IN CAA 0 issuewild "letsencrypt.org"

The Three CAA Tag Types

  • issue: authorizes the named CA to issue regular certificates for this domain.
  • issuewild: authorizes the named CA to issue wildcard certificates (*.example.com).
  • iodef: specifies an email or URL for the CA to contact if a violation is detected.

The flag (the "0" in the examples) is technical β€” set to 0 unless you have a specific reason otherwise.

The "No CAs Allowed" Trick

To explicitly forbid ANY CA from issuing certificates for your domain (useful for parked domains or domains that should never serve traffic):

example.com. IN CAA 0 issue ";"

The semicolon means "no authorized CA." Any CA receiving an issuance request for this domain must refuse.

Why Adoption Is Low

CAA has been mandatory for CAs since 2017. Despite that, adoption among domain owners is still under 20% as of 2026. The reasons:

  • It is not visible β€” there is no UI element that says "you should add this."
  • It is not required for HTTPS to work β€” sites function fine without CAA.
  • It requires understanding which CAs your infrastructure uses, which most owners do not track.
  • Some early CAA implementations had bugs that broke certificate issuance, which made operators cautious.

The result: the protection is widely available and rarely deployed. Closing this gap on your domains takes 5 minutes.

How to Set Up CAA Records

Step 1: Identify Your CAs

Which Certificate Authorities currently issue certificates for your domain? Check:

  • Your CDN (Cloudflare typically uses Let's Encrypt or Google Trust Services).
  • Your hosting platform (Vercel, Netlify, Heroku β€” usually Let's Encrypt).
  • Any explicit certificates you bought (DigiCert, Sectigo, etc.).
  • Run crt.sh?q=yourdomain.com to see all certificates ever issued β€” this is the authoritative log.

Make a list. Most domains use 1–2 CAs. Some use 3–4 across CDNs and platforms.

Step 2: Add the CAA Records

In your DNS provider's dashboard, add CAA records for each authorized CA. Common identifiers:

  • Let's Encrypt: letsencrypt.org
  • Google Trust Services: pki.goog
  • DigiCert: digicert.com
  • Sectigo: sectigo.com
  • GlobalSign: globalsign.com
  • Cloudflare: cloudflare.com (for SSL on Cloudflare-managed domains, though Cloudflare typically delegates to LE/GTS)
  • Amazon (ACM): amazon.com

If you use Cloudflare's DNS UI, the CAA record type is in the dropdown. Same for Route 53, DNSimple, and most modern providers.

Step 3: Verify

Check your CAA records with:

dig CAA example.com

The output should show your configured records. If you see them, CAs querying for issuance authorization will see the same answer.

Step 4: Test Issuance

Try renewing your existing certificate (or trigger an issuance through your platform). It should succeed. If it fails with a CAA-related error, you have either omitted the actual issuer or used the wrong identifier β€” fix and retry.

The Trickier Cases

Wildcard Certificates

If you use wildcard certificates (*.example.com), you need an issuewild record in addition to issue. The wildcard authorization is separate from the regular authorization.

Subdomain CAA

CAA records cascade: a record on example.com applies to api.example.com unless api.example.com has its own CAA record. You can be more restrictive on subdomains than on the apex if needed.

Multiple CAs Across Properties

If your apex uses Let's Encrypt and a specific subdomain uses DigiCert, you need both authorized β€” either both at the apex (broader) or split between apex and subdomain CAA records (tighter).

Adding a New CA

If you start using a new CA (signing up for a new platform, switching CDNs), add its CAA record FIRST, then trigger issuance. Without the CAA update, the issuance will fail.

Common CAA Mistakes

  • Forgetting to authorize the CDN's CA. Your apex uses LE; you add CAA for letsencrypt.org. Then you put Cloudflare in front and Cloudflare uses Google Trust Services β€” and certificate provisioning silently fails.
  • Using the wrong CA identifier. Each CA has a specific string. Misspelling it disables the authorization. Reference the official list before configuring.
  • Setting CAA "no CAs" on a live domain. Locks out all certificate issuance. Renewals will fail, leaving you with an expired cert. Always test on a test domain first.
  • Forgetting issuewild for wildcards. Regular issuance works; wildcard issuance silently fails until you add the issuewild record.

Beyond CAA: Account-Level Restrictions

Some CAs (notably Let's Encrypt and DigiCert) support a more granular layer: account-level restrictions. You can configure CAA so that only certificates issued through your specific account at that CA are valid:

example.com. IN CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345"

Now even an attacker who somehow tricked Let's Encrypt cannot issue a cert under your domain unless they also have your account. This is a meaningful step up for high-value domains.

The 5-Minute Action

  1. Identify the 1–2 CAs your domain currently uses.
  2. Add CAA records for those CAs in your DNS provider.
  3. Verify with dig CAA yourdomain.com.
  4. Test by triggering or waiting for a certificate renewal.

That is the entire setup. The protection is real: an attacker who compromises a different CA cannot issue a valid cert for your domain. The cost is zero. The defense is one of the cheapest security wins on the modern web β€” and it is sitting unused on most domains.