CAA: certificate authority authorization

Who can mint TLS certificates for this name? CAA records restrict which CAs are authorized to issue for a domain. Every publicly trusted CA must check CAA before issuing (CA/Browser Forum Baseline Requirements §3.2.2.8); a CA not listed refuses the request.

What it holds#

example.com.  CAA  0 issue       "letsencrypt.org"
example.com.  CAA  0 issuewild   "letsencrypt.org"
example.com.  CAA  0 iodef       "mailto:security@example.com"

• issue "ca.example": that CA is authorized to issue any cert.
• issuewild "ca.example": that CA is also authorized to issue wildcards. Without this tag, issue covers wildcards too (RFC 8659 §4.3).
• issue ";": no CA is authorized to issue (RFC 8659's deny form).
• iodef "mailto:...": where a CA should send misissuance reports. See "Gotchas."

When to use it#

At the apex, and at any name that needs a different issuance policy than its parent, for example blocking wildcard issuance in production while allowing it in staging.

When not to use it#

Rarely a reason to skip it. The only cost is locking out a CA you still use, by mistake.

dig example#

$ dig @1.1.1.1 caa.example.isitdns.net CAA

DNSSEC#

CAA at isitdns.net is signed: a validating resolver returns AD=1 once the CAA RRset checks out against the chain (dnssec). Since 2026-03-15 the Baseline Requirements also require CAs to DNSSEC-validate their own CAA lookups back to the root trust anchor, and to treat a validation failure as "do not issue," never as permission (§4.2.2.2.2, §4.2.2.2.5).

Gotchas#

• A CNAME target's CAA applies, not the CNAMEd name's. RFC 8659 §3 leaves CNAME handling to the resolver's normal lookup, so a CAA query for a CNAMEd name returns the target zone's records. If the target has none, the search climbs the original name's own parents, not the target's: RFC 8659 dropped RFC 6844's CNAME tree-climbing.
• issuewild overrides issue for wildcards once it exists. A lone issue record authorizes that CA for wildcards too (RFC 8659 §4.3). Add any issuewild record and every CA you want issuing wildcards must appear there explicitly.
• iodef reports are best effort. The Baseline Requirements only say a CA SHOULD dispatch misissuance reports there, not that it must, and only mailto:/https: URLs are expected (BR §4.2.2.1). Skip iodef and misissuance attempts have no return address at all.
• Managed DNS providers can auto-inject CAA records. Cloudflare, for example, adds records for its own certificate partners once a zone has any CAA record of its own. Partner sets can drift: isitdns.net still carries entries for a provider partner no longer on that list.
• issue ";" locks out every CA, including renewals. Test it on a subdomain first.
• CAs get 8 hours minimum to see a change, even at a 1h TTL. The Baseline Requirements let a CA that already fetched your record issue "within the TTL of the CAA record, or 8 hours, whichever is greater" (BR §4.2.2.1).

See also#

• CNAME: the chain-walking behavior CAA inherits
• TLSA: pinning the certificate itself in DNS, a step beyond CAA
• DoH and DoT: querying DNS over encrypted transports
• The CAA lesson: full walkthrough with examples
• All record types: cheat sheet
• Query types: how resolvers ask for specific record types
• CAA check: the records a CA reads, from a public resolver