Guides CAA
What is CAA?
CAA publishes intended issuer names for new certificates. Learn its DNS walk, wildcard and email rules, CA-dependent parameters, and scan limits.
CAA is a DNS publication stating which certificate-authority issuer names a domain intends to authorize. It constrains new certificate issuance; it does not revoke an existing certificate or prove what a particular CA will decide.
How the lookup works
Before issuance, a CA starts at the requested domain and checks each parent through the TLD. The first non-empty CAA RRset is relevant; a child RRset replaces rather than combines with a parent's records. If no relevant RRset exists, CAA publishes no restriction.
A CA that finds no matching authorization normally refuses issuance. The concrete request, CA support and any documented CP/CPS exception still determine the final decision.
The four useful tags
issue: issuer names for ordinary certificatesissuewild: issuer names for wildcard certificates; without it,issuealso governs wildcardsissuemail: issuer names for certificates covering email addresses; it is independent ofissueandissuewildiodef: a reporting URI; publication does not guarantee that a CA sends a report or that the endpoint works
An empty issuer, for example 0 issue ";", publishes no authorized issuer for that question.
Parameters and the critical flag
RFC 8657 defines accounturi and validationmethods for issue and issuewild. They restrict a request only when that CA explicitly supports and recognizes them; do not assume support from syntax alone. Parameters on issuemail are CA-specific.
Flag 128 makes a property critical. A CA that does not support that tag must not issue, even when the tag is registered. Use it only with documented CA support.
What DNS Radar can prove
DNS Radar compares publication routes through cached public DoH resolvers. It is not a CA and does not reconstruct the authoritative lookup a CA performs. Resolver AD is that resolver's validation assertion. The email result is the hypothetical RFC 9495 question for an address at the scanned domain. For iodef, the scan checks syntax and local endpoint shape, not delivery or reachability.
Setting it up
- List every CA and service that requests certificates for you
- Publish the issuer name documented by each CA
- Add
issuewildonly when wildcard policy should differ fromissue - Add
issuemailonly when you issue S/MIME or similar email certificates - Add RFC 8657 parameters or flag
128only after confirming support - Scan again and inspect both resolver routes and the selected RRset owner
Primary sources
Frequently asked questions
Does CAA revoke existing certificates?
No. CAA is evaluated for new issuance and renewal. Existing certificates remain valid until they expire or are revoked by another mechanism.
What if I use several CAs?
Publish one governing property per issuer name. Include hosting, CDN and other services that request certificates on your behalf.
How do ordinary, wildcard and email rules interact?
issue governs ordinary certificates and is the wildcard fallback when issuewild is absent. issuemail is independent and never falls back to either TLS tag.
Does a green scan guarantee issuance?
No. It proves what the sampled public DNS answers publish. CA identity mapping, parameter support, request validation and CP/CPS decisions remain outside the scan.