Support Library
CAA Records – Deep Dive
What CAA records do, how issue, issuewild and iodef work, how CAs search for CAA, and the mistakes that block certificate issuance.
The short answer
A CAA (Certification Authority Authorization) record, defined in RFC 8659, names the certificate authorities that may issue TLS certificates for your domain. Publicly trusted CAs must check the relevant CAA RRset before issuing. When its applicable issue or issuewild properties restrict issuance, the CA must be authorized by them; unknown critical properties can also prevent issuance. An RRset containing only iodef does not restrict issuers (RFC 8659).
$ dig +short CAA example.com
0 issue "letsencrypt.org"
0 issuewild ";"
0 iodef "mailto:security@example.com"CAA is optional. Without it, any public CA may issue for your domain after validating that you control it, which is the normal default rather than an error. Adding CAA narrows that choice, so a mistake or compromise at a CA you never use cannot produce a certificate for you.
The three common tags
| Tag | What it controls | Example |
|---|---|---|
| issue | Which CAs may issue certificates for this name, including wildcards unless issuewild is also present | 0 issue "digicert.com" |
| issuewild | Which CAs may issue wildcard certificates. When present, it replaces issue for wildcard requests only. | 0 issuewild ";" forbids wildcards from every CA |
| iodef | Where a CA may report a request it refused because of CAA. It does not restrict anything. | 0 iodef "mailto:security@example.com" |
Several issue records are additive: each one authorizes another CA, and any of them may issue. A value of ";" authorizes nobody. The leading number is the flags field; 128 marks a tag as critical, which tells a CA that does not understand the tag to refuse rather than ignore it. CAs may also support parameters, such as the accounturi and validationmethods parameters from RFC 8657, which tie issuance to one ACME account or validation method.
How a CA finds the record
The CA looks for CAA at the exact name in the certificate. If there is none, it climbs one label at a time towards the root and uses the first CAA record set it finds. So a record at example.com also covers www.example.com and shop.eu.example.com, unless one of those names, or a name between them, has its own CAA records. If a name is a CNAME, the CA checks the CNAME target's CAA as part of the same search.
That climbing behavior is useful for delegating control: a team that runs api.example.com with a different CA can publish its own CAA there without loosening the apex policy for everyone else.
Mistakes that block issuance
- Forgetting a CA you use. CDNs, email security platforms and hosted services often obtain certificates for your names from their own CA. Check every provider's documentation for the identifier it needs before you publish CAA.
- Wrong identifier. The value is the CA's published domain, such as letsencrypt.org or sectigo.com, not a product name.
- A CAA at a CNAME target you do not control. If shop.example.com is a CNAME to a SaaS host that publishes restrictive CAA, your CA may be refused even though your apex allows it.
- Lookup failures. If the CAA query fails for a DNSSEC-signed zone, for example with SERVFAIL from a broken chain, CAs must not treat that as permission, so issuance stops. The CA/Browser Forum rules allow other failures to count as permission only under narrow conditions, such as a retried lookup failing outside the CA's own infrastructure.
How DNS Panopticon helps
Domain Visualizer looks up CAA at the apex on every scan and lists any records it finds. When there are none it reports a best-practice finding, rated medium when the apex has addresses and low otherwise. That rating reflects DNS Panopticon's view that CAA is worthwhile hardening, not a claim that the domain is broken. Visualizer does not check CAA at subdomains or CNAME targets, so check those names with dig CAA before a certificate request.