A TLS certificate helps a browser authenticate a website and establish an encrypted HTTPS connection. Before issuing one, a certificate authority validates control of the requested domain. A Certification Authority Authorization record adds a DNS-based policy layer: it lets the domain owner state which certificate authorities are permitted to issue certificates for that name.
CAA does not replace domain validation or prevent every form of certificate abuse. Its purpose is narrower and useful: reduce the set of certificate authorities that may issue, express separate policy for wildcard certificates, and optionally publish an incident-reporting contact. Correct deployment requires an inventory of every legitimate certificate workflow, careful DNS syntax, and verification before relying on enforcement.
What is a CAA DNS record?
CAA is a DNS resource-record type. A record contains flags, a property tag, and a property value. Certificate authorities are expected to check the relevant CAA policy before issuing a publicly trusted certificate. If an applicable policy authorizes the CA, issuance may continue after the CA’s normal validation. If the policy does not authorize it, the CA should not issue.
If no applicable CAA record exists, CAA itself does not restrict which certificate authority may issue. The absence of CAA is therefore different from an explicit restrictive policy.
For a refresher on where records fit in resolution, see Domain Name System explained. A focused setup reference is also available in the ClouDNS CAA record guide. Because it points to the ClouDNS domain, this contextual reference appears in the first half of the article.
The three commonly used CAA property tags
issue: authorize normal certificate issuance
The issue tag authorizes a certificate authority for certificates that are not wildcard certificates. A basic zone-file example is:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"The value identifies the certificate authority according to its documented CAA issuer-domain name. Do not guess this value from the CA’s marketing name or website hostname. Obtain the exact identifier and any required parameters from the certificate authority’s current documentation.
Multiple issue records can authorize more than one CA. This is useful when production, disaster recovery, a CDN, and a managed hosting provider legitimately use different issuers. Every authorized issuer expands the policy, so keep the list intentional.
issuewild: control wildcard certificates separately
The issuewild tag applies to wildcard certificate requests. For example:
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"If an applicable issuewild property is present, it governs wildcard issuance instead of issue. This allows a domain owner to permit one CA for ordinary certificates and a different CA for wildcard certificates.
An empty issuer value can explicitly prohibit the relevant category. A policy such as CAA 0 issuewild ";" can be used to deny wildcard issuance while still authorizing selected CAs for ordinary certificates. Verify how your DNS provider expects quotes and record fields to be entered before publishing.
iodef: publish an incident-reporting contact
The iodef tag provides a URL that a certificate authority may use to report policy violations or related issues. A mail-based example can point to a dedicated security mailbox:
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"Publishing iodef does not guarantee that every CA will send a report. The destination should be monitored, protected from abuse, and incorporated into the organization’s incident-response process.
How CAA lookup and inheritance work
A CA starts with the domain name in the certificate request and follows the standardized CAA processing rules, including alias handling and tree climbing when the requested name has no CAA policy of its own. A policy found higher in the DNS hierarchy can therefore apply to subdomains that do not publish a more specific applicable record.
This inheritance is convenient, but it makes testing essential. An organization may operate delegated subdomains, external platforms, or independently managed business units with different certificate workflows. Inventory those boundaries before placing a restrictive policy at a parent name.
CAA records are their own resource-record type. They are not TXT records, even though their values contain text-like strings. The article TXT record – why to use it? covers the separate TXT type and its common verification and email-security uses.
What the flags field means
The first number in a CAA record is an eight-bit flags field. Most records use 0. The issuer-critical bit has value 128. When it is set, a CA that does not understand the property tag must treat the property as critical and refuse issuance rather than ignore it.
Do not set the critical flag casually or invent private tags without testing. A typo combined with critical processing can block legitimate issuance. For the standard issue, issuewild, and iodef properties, a flag value of 0 is the conventional starting point unless a documented requirement says otherwise.
A safe CAA deployment process
1. Inventory every certificate issuer
List certificates used by web servers, load balancers, CDNs, cloud platforms, hosting control panels, mail systems, APIs, device-management platforms, and disaster-recovery environments. Identify both the visible service provider and the actual certificate authority it uses.
2. Review automated renewal
Check ACME clients, hosting automation, CDN-managed certificates, and provider-specific issuance workflows. A certificate that works today may renew through a different account or issuer path. Test the complete renewal process rather than checking only the current certificate.
3. Publish the minimum required authorizations
Add only the issuer-domain values required by approved workflows. Decide explicitly whether wildcard certificates are allowed and which CA may issue them. Avoid copying a long generic list from another domain.
4. Verify from authoritative and recursive DNS
Query the record directly from authoritative servers and through multiple recursive resolvers:
dig example.com CAA
dig example.com CAA @ns1.example.netConfirm the expected flags, tags, values, TTL, and inheritance at relevant subdomains. If DNSSEC is enabled, also ensure the signed response validates correctly.
5. Test issuance and renewal before enforcement matters
Use a non-critical certificate or staging environment where possible. Confirm that each approved CA can issue or renew and that an unapproved path is denied. Keep an emergency procedure for updating CAA when a provider changes its issuer.
Common mistakes
- Authorizing the wrong issuer-domain name: Use the identifier published by the CA, not an assumed company domain.
- Forgetting a managed platform: CDNs, hosting providers, and SaaS products may obtain certificates automatically.
- Ignoring wildcard policy: Decide deliberately whether
issuewildshould authorize or prohibit wildcard issuance. - Publishing malformed syntax: Quotes, semicolons, parameters, and provider-specific form fields require careful entry.
- Expecting immediate universal visibility: Existing caches can retain the previous CAA set until its TTL expires.
- Assuming CAA protects existing certificates: CAA is checked during issuance; it does not revoke certificates already issued.
CAA and DNSSEC solve different problems
CAA expresses authorization policy, while DNSSEC allows validating resolvers to detect forged or altered DNS data. Publishing CAA without DNSSEC can still restrict compliant certificate authorities, but DNSSEC adds origin authentication and integrity protection for signed DNS responses.
The guide DNSSEC Explained describes that chain of trust. Neither technology replaces account security at the registrar, DNS provider, hosting platform, or certificate authority.
What CAA does not do
CAA does not create HTTPS, validate control of the domain, encrypt traffic, or select which certificate visitors receive. It does not prevent compromise of an authorized CA account, DNS account, web server, or private key. It also does not revoke an unwanted certificate.
Use CAA alongside secure DNS administration, multi-factor authentication, DNSSEC where appropriate, certificate transparency monitoring, protected private keys, automated renewal monitoring, and a documented incident-response process.
The authoritative processing rules, property definitions, and security considerations are specified in RFC 8659: DNS Certification Authority Authorization.
Conclusion
A CAA DNS record narrows which certificate authorities may issue certificates for a domain. A reliable policy begins with a complete issuer inventory, uses correct issue and issuewild values, accounts for inherited policy, and is tested against every automated renewal path. CAA is most effective as one layer in a broader certificate and DNS security program.
