A CAA (Certification Authority Authorization) record is a DNS entry that names which certificate authorities are allowed to issue certificates for your domain. Any CA checking a CAA record before issuance — and every publicly trusted CA has been required to since 2017 — will decline to issue if your domain has a CAA record that doesn't list them.
Why this record exists at all
Before CAA records, any of the hundreds of publicly trusted certificate authorities could issue a certificate for any domain, as long as that CA's own domain validation check passed. A CAA record narrows that down: you name the specific CA (or CAs) you actually use, and every other CA is required to refuse a request for your domain even if they'd otherwise be willing to validate it. It's a preventive control against a specific, if uncommon, class of incident — an attacker who manages to pass domain validation with a CA you don't normally use.
What a CAA record in fact looks like
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "sectigo.com"
example.com. CAA 0 iodef "mailto:security@example.com"
The issue tag authorizes standard certificate issuance from a named CA. A separate issuewild tag exists exactly for wildcard certificates — a domain can authorize one CA for standard certificates and a different one (or none) for wildcards. The iodef tag is optional and gives a CA an address to report an attempted unauthorized issuance to, if one is ever detected.
What happens with no CAA record at all
No CAA record means no restriction — any publicly trusted CA can issue for your domain, which was the default, unrestricted behavior every domain had before this record type existed. Adding a CAA record is opt-in hardening, not something every domain is required to have, though for any domain where you know exactly which CA (or handful of CAs) you use, there's little downside to explicitly restricting the rest.
A mistake worth avoiding: authorizing a CA you've since stopped using
If you migrate from one CA to another — moving from a paid CA to Let's Encrypt, for instance — and forget to update your CAA record, the old authorization doesn't cause a problem by itself, but it does mean that CA (or anyone who somehow gained access to request through your old account there) remains a technically authorized issuer for your domain. Updating the record as part of any CA migration is a small, easy step worth building into the process rather than treating as optional cleanup.
Checking a domain's current CAA record
dig CAA yourdomain.com
An empty response means no CAA record is set. If you're troubleshooting a certificate issuance failure and suspect a CAA record might be the cause — a CA reporting it isn't authorized to issue for your domain, despite everything else about the request being correct — this is the first thing to check.
CAA records and subdomains
CAA records are inherited down the DNS tree unless a subdomain sets its own — a CAA record on example.com applies to blog.example.com too, unless blog.example.com has its own CAA record overriding it. This matters if different parts of your domain are managed by different teams using different CAs; each subdomain needing a different authorized CA needs its own explicit record rather than relying on the parent domain's.
See RFC 8659, the CAA record specification.