ClueDNSSearch

record · intermediate

CAA record reference

Understand DNS CAA certificate-issuance authorization, flags, property tags and values, caching, CNAME boundaries, and verification limits.

Published
Jul 28, 2026
Last verified
Review by
Risk
reversible
Provider
Provider-neutral

A CAA RRset lets a domain holder express which certification authorities may issue certificates for a name and where certain policy incidents can be reported. It influences new issuance; it does not revoke an existing certificate, configure TLS, or prove a certificate was issued correctly.

Purpose and type code

IANA registers CAA as type code 257 [1]. RFC 8659 defines the flags, property tag, property value, and certification-authority processing rules [2].

Registered property tags include:

  • issue: authorization for ordinary certificate issuance;
  • issuewild: authorization specifically for wildcard certificates; and
  • iodef: a reporting contact or endpoint for policy violations.

An empty issuer-domain-name value for issue or issuewild can deny that form of issuance. Copy only values documented by the intended certification authority.

Presentation format

example.com.  3600  IN  CAA  0 issue "ca.example"
example.com.  3600  IN  CAA  0 issuewild ";"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

The first field is an unsigned flags octet, the second is the property tag, and the quoted value contains the tag-specific property value. These examples use reserved names and do not authorize a real CA.

The issuer value is not necessarily the CA’s marketing hostname. Use the exact value from that CA’s current documentation.

Owner-name and coexistence rules

CAA can coexist with most ordinary RRsets at an owner but not with other data at a CNAME alias owner. Certification-authority processing follows CNAME and tree-climbing rules defined by RFC 8659. A record at one name does not automatically describe every independent delegated subzone.

Multiple CAA records at the selected owner form one policy RRset. They are not evaluated as first-match priorities. Preserve every required issuer and property when changing the RRset.

Unknown property tags with the critical flag set can prevent an issuer that does not understand the property from proceeding. Do not set flag bits without understanding the intended CA behavior.

Caching and changes

Resolvers and certification authorities can cache CAA according to DNS TTL and their compliant processing. Publishing a corrected RRset does not immediately erase an earlier restrictive or permissive answer already cached.

Lower a TTL only in advance of a planned change and wait for the previous TTL to age out. Keep exact prior values for rollback, but remember that rollback also has a cache-overlap period.

CAA changes should be coordinated with certificate renewal, automation, account-validation, and emergency-issuance owners. Do not remove an issuer until all intended certificate workflows have moved.

Security and operational limits

CAA reduces accidental or unauthorized issuance paths when issuers perform the required check. It does not:

  • stop a non-compliant attacker;
  • revoke or shorten an existing certificate;
  • authorize domain control by itself;
  • configure a web server or certificate chain;
  • guarantee that issuance or renewal succeeds; or
  • replace account protection and certificate monitoring.

A malformed or incomplete policy can block urgent renewal. Treat a change as reversible but operationally significant, especially near certificate expiry. DNSSEC can authenticate CAA data when the chain validates, but CAA does not require DNSSEC to be useful.

Verify

Use the DNS Lookup pathway to inspect CAA through named resolvers, then verify:

  1. the exact owner and any CNAME path;
  2. the complete CAA RRset, flags, tags, values, and TTL;
  3. direct answers from every intended authority;
  4. tree-climbing or delegation boundaries relevant to the certificate name;
  5. each issuer value against the intended CA’s official documentation;
  6. certificate automation in a non-destructive test when supported; and
  7. the current deployed certificate separately through the SSL Checker pathway.

A valid current certificate does not prove that the next renewal will pass the present CAA policy.

Next step

Use the safe DNS-change checklist before altering production issuance policy. After DNS verification, inspect TLS hostname coverage and chain behavior separately.