Quick answer
A CAA (Certification Authority Authorization) record names the certificate authorities allowed to issue TLS/SSL certificates for your domain (RFC 8659, which obsoletes the earlier RFC 6844). Each record holds a flags byte, a property tag, and a value, as in example.com. IN CAA 0 issue "letsencrypt.org". A CA is required to read your CAA records at the moment it issues a certificate and refuse the request if they do not authorize it. Publish no CAA record and any publicly trusted CA is free to issue for your domain.
The three property tags: issue, issuewild, iodef
RFC 8659 §4 defines three property tags, and every CAA record uses one of them.
issue authorizes a named CA to issue certificates for the domain. The value is the CA's identifying domain:
example.com. IN CAA 0 issue "letsencrypt.org"
That record says Let's Encrypt may issue for example.com. The presence of any issue property also carries a negative meaning: once you list one CA, every CA that is not listed is refused. To authorize two providers, publish two issue records. An issue ";" value (a lone semicolon) authorizes no CA at all.
issuewild works like issue but applies only to wildcard certificates such as *.example.com. When present, issuewild takes precedence over issue for wildcard requests, so you can let one CA issue ordinary certificates while restricting who may issue a wildcard.
iodef gives a CA a place to report a request that violates your policy. The value is a URL, commonly a mailto: address:
example.com. IN CAA 0 iodef "mailto:security@example.com"
A CA that supports iodef sends an incident report there when someone asks it to issue a certificate your CAA policy forbids. It is a monitoring channel, not an authorization control.
The issuer critical flag
The flags field is the number before the tag (the 0 in the examples above). Only one bit is defined: bit 0, the Issuer Critical Flag, which is the most significant bit and so carries the value 128 (RFC 8659 §4). Setting it makes the property critical. If a CA encounters a critical property whose tag it does not understand, it must refuse to issue rather than ignore the record. A flags value of 0 leaves the property non-critical, which is the normal setting for issue, issuewild, and iodef. You raise the flag to 128 only when you want a CA that cannot process a property you consider mandatory to decline instead of proceeding.
When a CA checks CAA (and when it does not)
CAA is enforced at certificate issuance, not during browsing. Before a CA signs a certificate it performs a fresh DNS lookup of your CAA records and honors what it finds; that check is mandated for publicly trusted CAs by the CA/Browser Forum Baseline Requirements, not by DNS itself. Browsers and TLS clients never look at CAA. A visitor's browser validating the certificate on an HTTPS connection does not query CAA and does not care what it says.
This has two consequences. A CAA record does not stop a browser from trusting a certificate that was already issued: if a CA issued a certificate before you published CAA, or in violation of your policy, that certificate keeps working until it expires. CAA constrains the act of issuance going forward, so a record you add today protects future issuance immediately but does nothing about certificates already in the wild. Unlike a TXT record, which holds free-form text a receiver interprets loosely, a CAA record has a fixed structure that CAs parse strictly, so a typo in the CA's domain silently authorizes nobody.
How resolvers find a CAA record, and whether you need one
CAA uses a tree-climbing lookup (RFC 8659 §3). When a CA needs the policy for www.example.com, it looks for a CAA record at that exact name first. If none exists, it walks up the parent labels (example.com, then toward the root) and uses the first CAA record set it finds. The search climbs the tree up to but not including the root. A CAA record at your apex therefore covers every subdomain that does not publish its own, so you usually set policy once at example.com rather than per host. The records live in your zone and are served by the same authoritative nameservers listed in your NS record set.
Do you need one? A CAA record is optional. With none published, any publicly trusted CA may issue for your domain, which is the default the web has run on for years. Publishing CAA narrows that to the CAs you actually use, so a mis-issued or fraudulently requested certificate from any other CA is refused at the source. If you issue exclusively through, say, Let's Encrypt and your hosting provider's CA, a short issue list plus an iodef address is a low-effort hardening step. For how CAA sits among the other record types in your zone, see DNS record types.