DNS Certification Authority Authorization (CAA) records specify which certificate authorities (CAs) may issue certificates for a domain name. To configure CAA, publish each CA's exact identifier in an issue record and add issuewild when wildcard names need different permissions. Then check the CAA records that apply to every name on the certificate.

Public certificate authorities check CAA before issuing certificates. CAA does not revoke existing certificates, and browsers do not use current CAA records to validate certificates that have already been issued.

Understand the CAA Record Format

In a DNS zone file, a CAA record's data is written as three fields:

CAA <flags> <tag> <value>

A DNS provider may display these as separate fields. A generic record could appear as:

example.com. 3600 IN CAA 0 issue "ca.example"

The flags field is an integer from 0 through 255, but reserved flag bits must stay at zero. Use 0 for ordinary issue, issuewild, and iodef records unless a documented extension requires critical processing. The Issuer Critical flag has the presentation value 128; an unknown or unsupported critical property prevents a compliant CA from issuing.

The tag field identifies the property. The tags issue and issuewild control certificate issuance, while iodef specifies where reports can be sent.

The value field carries the issuer authorization or reporting URL. Use the exact issuer identifier and any optional parameters listed in the CA's current documentation. The identifier may differ from the CA's brand name or the address of its ordering website.

Authorize Certificate Issuers

An issue record authorizes the CA identified by its value, or a party acting with that CA's explicit permission, to issue for the domain name covered by the policy. A set can authorize more than one CA:

example.com. 3600 IN CAA 0 issue "ca-one.example"
example.com. 3600 IN CAA 0 issue "ca-two.example"

This example authorizes both placeholder issuers. Replace them with identifiers confirmed by the actual CAs before publishing. If an issuer requires account or validation-method parameters, use only the syntax that issuer documents.

An empty issuer identifier means that the record authorizes no CA:

example.com. 3600 IN CAA 0 issue ";"

An issue value with invalid syntax is also treated as an empty issuer identifier, which can unexpectedly block issuance. An empty issue record does not cancel another record's valid authorization; the CA can still issue if the other record permits it.

Set a Separate Wildcard Policy

The issuewild tag controls issuance for wildcard names, such as *.example.com. You only need a separate issuewild policy when wildcard names should have different permissions. If the applicable set has no issuewild record, issue controls issuance for both wildcard and non-wildcard names.

If the applicable set contains an issuewild record, the CA ignores issue when checking a wildcard name. For a non-wildcard name, the CA ignores issuewild.

To authorize one CA for non-wildcard names and another for wildcard names:

example.com. 3600 IN CAA 0 issue "ca-one.example"
example.com. 3600 IN CAA 0 issuewild "ca-two.example"

To allow one CA to issue for non-wildcard names while blocking issuance for wildcard names:

example.com. 3600 IN CAA 0 issue "ca-one.example"
example.com. 3600 IN CAA 0 issuewild ";"

To allow one CA to issue for wildcard names while blocking issuance for non-wildcard names:

example.com. 3600 IN CAA 0 issue ";"
example.com. 3600 IN CAA 0 issuewild "ca-two.example"

A set containing only issuewild leaves issuance for non-wildcard names unrestricted by CAA. Add an issue record if you also need to limit which CAs can issue for those names.

Add an Optional Reporting Destination

The iodef property gives the CA a destination for reports about certificate requests or issued certificates that violate policy. Although the property defines mailto, http, and https schemes, public TLS CAs are not expected to support plain HTTP reporting. Use a mailto address or HTTPS endpoint supported by the intended CA:

example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
example.com. 3600 IN CAA 0 iodef "https://reports.example.com/caa"

Publish only an address or endpoint that can receive and process the expected report format securely. The property requests reporting; it does not guarantee that a report will arrive. It also does not authorize or forbid an issuer by itself.

A set containing only iodef does not restrict which CAs may issue. Keep reporting records alongside the issuer restrictions that should apply at that name.

Plan for CAA Inheritance

A CA starts its CAA search at the domain name requested for the certificate. If no CAA records are found, the CA removes the leftmost label and tries the parent name. The first set found supplies the policy; the DNS root itself is not queried.

Without DNS aliases, a search for app.dev.example.com can examine:

  1. app.dev.example.com
  2. dev.example.com
  3. example.com
  4. com

If dev.example.com has any CAA records, that set becomes relevant and the search does not merge it with a policy at example.com. The child's records replace the inherited policy for any name whose lookup reaches that set. Include all required issuer restrictions when creating the child set, even if your immediate goal is to add a reporting destination.

For a wildcard request such as *.dev.example.com, the search starts at dev.example.com, without the *. prefix. The CA then applies the issuewild rules to the set it finds.

Follow DNS Aliases at Each Name

Each CAA query follows DNS aliases, including CNAME records. If app.dev.example.com points to service.example.net and that lookup returns CAA records, the returned set becomes the relevant policy. The alias target can therefore supply a different policy from the one at example.com.

If the completed alias lookup returns no CAA records, the next query is for dev.example.com, the parent of the name that was queried. The search does not automatically move to the alias target's parent. Repeat the lookup and parent step until a CAA set is found or the search reaches the DNS root.

CAA data and a CNAME record cannot coexist at the same owner name. If another service manages the alias target, check that target's CAA records before choosing a CA.

Configure the Complete Policy

  1. List every CA that needs to issue for each name, including the CAs used by certificate automation services.
  2. Obtain each issuer's exact CAA identifier and required parameters from current official documentation.
  3. List the wildcard and non-wildcard names needed on each certificate, including requests for more than one name.
  4. Choose where to publish CAA records, checking whether child records or alias targets will change the policy that applies.
  5. At each chosen name, publish the complete list of allowed issuers and any optional iodef records.
  6. Verify authoritative and recursive answers before requesting a certificate, allowing previous cached records or negative answers to expire.

A certificate request can include several names, and CAA is checked separately for each one. For example, a certificate containing both example.com and *.example.com needs permission for both names; passing the wildcard check does not authorize the non-wildcard name. A restriction or invalid record affecting one name can stop the entire request. Lowering a record's new TTL does not shorten the remaining lifetime of an answer already cached with an older TTL.

Verify the Relevant CAA Set

Query each name where you published CAA records:

dig -r example.com CAA
dig -r dev.example.com CAA

These commands query the configured resolver and show the full response, including the status in its header. To check an authoritative server directly, replace AUTH_IP with that server's IP address:

dig -r @AUTH_IP example.com CAA +norecurse

Repeat the direct query for every authoritative server for the zone containing the name you are checking. Confirm the authoritative-answer flag and compare the CAA flags, tags, values, and TTL. A referral or an answer from a server that is not authoritative for that name does not confirm that the CAA records were published correctly. For an alias target in another zone, query that zone's authoritative servers separately.

Follow aliases and walk upward from every certificate name until the first non-empty CAA set is found. For wildcard names, check issuewild when present and otherwise check issue; for non-wildcard names, check issue. Verify that issuer identifiers and parameters match current CA documentation.

Then compare answers from recursive resolvers with the authoritative data to identify stale cached policy. A public TLS CA must validate DNSSEC during its primary CAA lookup and must not treat a DNSSEC validation error as permission to issue. A timeout or SERVFAIL is not evidence that no CAA restriction exists; investigate the lookup failure before retrying the certificate request.

Keep the DNS server address, query time, answers, requested certificate names, and CA response without including private account credentials. If the request is rejected, use the CA's diagnostic message to investigate the cause. Receiving a certificate confirms that it was issued, but does not by itself show which DNS response or CAA check the CA used.

Update CAA When Issuers Change

Update CAA before changing issuers or certificate automation. Removing the only authorized issuer can block renewal, while leaving an unused issuer authorized broadens the policy beyond current need.

CAA helps prevent unauthorized certificate issuance when CAs follow the published rules, but an authorized CA can still issue a certificate incorrectly. Protect access to DNS settings, use DNSSEC where appropriate, limit who can use CA accounts, and monitor certificate transparency logs as separate controls.