A public certificate authority does more than validate control of a DNS name. Before issuing a certificate, a CA that follows the CAA specification also checks DNS for a Certification Authority Authorization policy relevant to each requested name. That policy can narrow the set of issuers permitted to create certificates for the domain.
CAA is an issuance control, not a replacement for domain-control validation. An authorized CA still has to apply its normal validation and issuance requirements. The record adds another decision: even after validation succeeds, is this issuer permitted by the domain’s published CAA policy?
The relevant CAA RRset sets the issuance boundary
CAA is DNS resource record type 257. A basic record has flags, a property tag, and a value:
example.net. CAA 0 issue "ca.example"The issue property authorizes the identified CA to issue non-wildcard certificates for names governed by that relevant RRset. In the absence of a separate issuewild property, issue also applies to wildcard issuance.
RFC 8659 defines the search for the relevant RRset. For a requested FQDN, the CA checks the name and then moves upward through its parent labels until it finds a CAA RRset, stopping before the DNS root. The first applicable RRset found by that procedure becomes the policy used for the request.
This inheritance lets a zone publish policy at a parent name without copying the same records to every child. A child can also publish its own CAA RRset, which becomes the closer policy for that name.
The effect is policy inheritance through the DNS name tree, not wildcard matching. That distinction matters when operators audit records across delegated names and service-specific subdomains.
issue and issuewild separate ordinary and wildcard issuance
The two principal authorization properties are issue and issuewild.
example.net. CAA 0 issue "ca-a.example"
example.net. CAA 0 issuewild "ca-b.example"With a relevant issuewild property present, wildcard requests are evaluated against issuewild rather than issue. This permits a domain to use one issuer for ordinary certificates and another for wildcard certificates.
Multiple properties of the same type are additive. If the relevant RRset contains several issue records, each listed issuer can be authorized according to the applicable processing rules. CAA therefore does not express a preference order among authorized CAs.
An empty issuer value can deny issuance for that property class:
example.net. CAA 0 issue ";"Such a policy can be useful for a name that should not receive ordinary public certificates. It has to be deployed deliberately, because a restrictive CAA change can also stop legitimate renewals.
Every requested name must pass the check
A certificate can contain several DNS identifiers. Authorization for one identifier does not authorize the others. RFC 8659 requires the issuer to verify CAA authorization for all FQDNs and wildcard names in the certificate request.
Consider a certificate request containing:
www.example.net
api.example.netA permissive policy relevant to www.example.net does not cancel a restrictive policy relevant to api.example.net. The CA has to reach an acceptable result for both names before issuance can proceed.
This property makes CAA relevant to automation. A renewal job can fail after a DNS policy change even when the ACME account, private key, and challenge mechanism are otherwise functioning. The issuance path depends on both domain validation and the current applicable CAA policy.
The critical flag protects semantics the issuer does not support
CAA reserves the most significant bit of the flags octet as the Issuer Critical flag. In presentation format its value is 128.
example.net. CAA 128 futuretag "policy-data"If a relevant property carries the critical flag and the CA does not support that property tag, a conforming CA must not issue for the affected name. The flag exists so a future CAA extension can mark semantics as mandatory rather than letting an issuer silently ignore an unfamiliar property.
Unknown properties without the critical flag do not automatically prohibit issuance. Reserved flag bits must remain clear under the current specification.
This is a compatibility mechanism with a fail-closed option. Setting the critical flag on a property that an intended CA cannot process can stop issuance, so it belongs in a controlled rollout rather than an experimental production change.
iodef provides a reporting contact, not issuer authorization
CAA also defines the iodef property for reporting information:
example.net. CAA 0 iodef "mailto:security@example.net"An iodef record does not authorize a CA to issue a certificate. It supplies a location to which an issuer can report policy violations or related events according to its supported procedures.
A relevant RRset containing only iodef records does not restrict issuance by itself. Issuance restrictions come from the authorization properties and their processing rules.
This distinction prevents a common configuration error: adding a reporting address is not equivalent to creating an issuer allowlist.
CAA narrows CA authorization but does not secure DNS by itself
CAA policy is retrieved through DNS. RFC 8659 defines issuer behavior around the relevant RRset, but publishing CAA does not add integrity protection to DNS responses. DNSSEC is the DNS mechanism designed to provide authenticated DNS data.
CAA also does not make certificate issuance impossible for every attacker. Its security value depends on issuers observing the constraints, the integrity and administration of the DNS policy, and the rest of the CA validation process. It is a policy control within the public certificate ecosystem, not a standalone certificate guarantee.
The practical benefit is narrower authorization. If an organization intends to use a specific public CA, a matching CAA policy can state that intent in a form conforming issuers must check before issuance.
Policy changes need the same care as certificate rotation
CAA records are cached according to DNS behavior. A policy edit is therefore not necessarily visible to every resolver or CA component at the instant it is published.
Before removing an issuer, operators need to account for active certificate automation and pending renewals. Before adding a new issuer, they need to ensure the new policy is visible where issuance will be evaluated. A multi-name certificate also needs consistent authorization across every requested identifier.
A useful operational review includes the effective CAA RRset for each certificate name, wildcard handling, DNS delegation boundaries, and the issuer used by renewal automation. That review should happen before a restrictive policy is activated.
CAA works best as a small, explicit issuance boundary: DNS publishes the acceptable issuer set, and the CA checks that boundary before creating the certificate. It reduces the number of public CAs that a domain intentionally accepts without changing the separate requirement to validate control of the requested names.