How to Set Up a CAA Record for Your Domain

A CAA (Certification Authority Authorization) record lets you specify exactly which certificate authorities are allowed to issue SSL/TLS certificates for your domain. If any other CA tries, it's supposed to refuse. It's a small record with a big security payoff, and it takes two minutes to add. This guide shows the exact values.

Why CAA matters

Any public CA can, in principle, issue a certificate for any domain — which is a problem if one is tricked or compromised. A CAA record narrows that down: you publish a list of approved CAs, and compliant CAs must check it before issuing. It doesn't replace DNSSEC or good key hygiene, but it closes off mis-issuance cheaply. For where CAA sits among records, see DNS records explained.

Anatomy of a CAA record

A CAA record has three fields packed into its value:

• Flags: usually 0
• Tag: issue (single certs), issuewild (wildcards), or iodef (a report address)
• Value: the CA's domain, e.g. letsencrypt.org

So a full record reads: 0 issue "letsencrypt.org".

Step 1: Decide which CAs to allow

Pick the CA(s) you actually use. Common values:

• Let's Encrypt / Certbot: letsencrypt.org
• Google Trust Services: pki.goog
• DigiCert: digicert.com
• Sectigo: sectigo.com
• Cloudflare (via its edge certs): comodoca.com, digicert.com, letsencrypt.org, pki.goog, ssl.com

If you get free certs with Let's Encrypt — as in free SSL certificates with Let's Encrypt — you at least want letsencrypt.org.

Step 2: Add the records

In your DNS panel, create a CAA record. Most panels give you separate fields for flags, tag and value:

• Type: CAA, Name: @, Flags: 0, Tag: issue, Value: letsencrypt.org

To also permit wildcard certs from the same CA, add:

• Type: CAA, Name: @, Flags: 0, Tag: issuewild, Value: letsencrypt.org

If your panel wants the raw record, it looks like:

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

Step 3: Optionally add an incident report address

example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"

CAs that see a request they can't honour will email that address.

Step 4: Verify

dig example.com CAA +short

You should see your issue/issuewild lines back. CAA is checked at the moment of issuance, so an existing certificate keeps working even if you tighten the record; the rule applies to the *next* issuance or renewal. Query tips: diagnosing DNS problems with dig and nslookup.

A common gotcha

If you add a CAA record listing only digicert.com but then try to get a Let's Encrypt cert, issuance fails with a CAA error. The fix is to add letsencrypt.org to the record. So: only list CAs you actually use, and remember to update CAA before switching providers. This bites people running free SSL for a custom domain.

issue vs issuewild

The two main tags do different jobs, and mixing them up causes surprises:

• issue authorises a CA to issue certificates for the exact domain and, by default, its subdomains.
• issuewild specifically governs wildcard certificates (*.example.com). If you set issuewild for one CA, only that CA can issue wildcards, regardless of issue.

If you never use wildcards, you can block them entirely — a nice hardening step — by publishing:

example.com. CAA 0 issuewild ";"

The semicolon means "no CA may issue wildcards." That stops an attacker who compromises a CA account from minting a *.example.com cert.

CAA and subdomains: inheritance

CAA uses a "closest ancestor" rule. If example.com has a CAA record but shop.example.com doesn't, the subdomain inherits the parent's policy. Add a CAA record directly on a subdomain only when it needs a *different* policy — for instance, a subdomain served through a CDN that uses a different CA. Otherwise a single record on the apex protects the whole tree.

Getting CAA right with Cloudflare and other edges

If your site sits behind Cloudflare's proxy (orange cloud), Cloudflare issues the public certificate at its edge using several CAs it rotates between. A CAA record that lists only letsencrypt.org can block Cloudflare from renewing, breaking HTTPS. Cloudflare's guidance is to allow the set it uses:

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "pki.goog"
example.com. CAA 0 issue "ssl.com"
example.com. CAA 0 issue "comodoca.com"
example.com. CAA 0 issue "digicert.com"

The rule of thumb applies everywhere: list every CA in your issuance path, including the ones your CDN or host uses on your behalf, or the *next* renewal fails. This pairs naturally with how to move your domain's DNS to Cloudflare and the broader hardening in how to enable DNSSEC on your domain.

FAQ

Is a CAA record required for SSL?

No — without a CAA record, any CA may issue. Adding one is a best-practice hardening step, not a prerequisite for HTTPS.

Does CAA affect existing certificates?

No. It's checked only at issuance/renewal time. Existing certs keep working; the next renewal must satisfy the record.

What if I use multiple certificate authorities?

Add one CAA issue record per CA. All listed CAs are permitted; any not listed is blocked.

Can I set CAA on a subdomain?

Yes. CAA on a subdomain overrides the parent for that name; otherwise subdomains inherit the closest ancestor's CAA policy.

Will a CAA record stop attackers getting a certificate for my domain?

It raises the bar but isn't a complete lock. A CAA record instructs compliant certificate authorities to refuse issuance unless they're on your approved list, which blocks the common attack of tricking an *unlisted* CA into minting a rogue certificate. It can't stop an attacker who somehow passes domain validation at a CA you *have* authorised, and it relies on CAs honouring the record — which public CAs are required to do. Treat CAA as one layer among several: combine it with DNSSEC to protect the DNS answers themselves, tight control over your DNS and CA accounts, and Certificate Transparency monitoring so you're alerted if any certificate is ever issued for your domain. Together those make mis-issuance genuinely hard rather than merely inconvenient.

CAA is one line of defence in a proper security posture. See what else to lock down on Nxeon's security page, and run your sites on a fast NVMe VPS with full root access.