What CAA records do
A Certification Authority Authorization (CAA) record is a DNS record type (RFC 8659) that specifies which certificate authorities are permitted to issue TLS certificates for a domain. Before issuing a certificate, CAs are required by the CA/Browser Forum Baseline Requirements to check the CAA records for the requested domain and refuse to issue if the CA is not listed.
Without any CAA records, any trusted CA can issue a certificate for your domain. There are over 100 CAs trusted by major browsers. A misconfigured or compromised CA — or one that was deceived by a convincing domain validation request — could issue a certificate for your domain that your organization did not request. CAA records reduce this attack surface to only the CAs you explicitly authorize.
Certificate misissuance has happened in practice: CAs have issued certificates for domains they should not have (DV validation mistakes, organizational errors, BGP-based domain validation attacks). CAA is one layer of defense against misissuance reaching production use.
Record syntax
A CAA record has three fields: a flag, a tag, and a value.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"- Flag (0 or 128): Flag 0 means "non-critical" — a CA that does not understand this tag should ignore it. Flag 128 marks the record as critical — a CA that does not understand the tag must refuse to issue. In practice, use 0 for all standard tags.
issuetag: Authorizes the named CA to issue regular (non-wildcard) certificates. The value is the CA's policy domain, not a URL — it is the domain that appears in the CA's Certificate Policy.issuewildtag: Controls wildcard certificate issuance specifically. If you have anissuerecord but noissuewildrecord, theissuerecord governs wildcards too. If you have both,issuewildtakes precedence for wildcards.iodeftag: Specifies a URI where CAs should send violation reports if they receive a request for a certificate that CAA would deny. Acceptsmailto:andhttps:URIs. Not all CAs implement this.
Multiple CAA records
You can authorize multiple CAs by publishing multiple CAA records with the issue tag — one record per CA. All authorized CAs form an allowlist:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "digicert.com"
example.com. CAA 0 iodef "mailto:security@example.com"To block all issuance (effectively making your domain un-certifiable by any CA), publish a single issue record with an empty string value:
example.com. CAA 0 issue ";"This is useful for domains that should never have certificates issued — internal-only domains, parked domains, or domains where you manage certificates entirely out-of-band. Be cautious: this will block Let's Encrypt auto-renewal as well.
To allow regular certificates from a CA but block wildcard issuance entirely:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"Common setups
- Let's Encrypt only:
CAA 0 issue "letsencrypt.org". This is appropriate for any domain using certbot, acme.sh, or ACME protocol automation. Let's Encrypt's policy domain isletsencrypt.org. - Let's Encrypt plus a paid CA: Add a second
issuerecord. Common in organizations that use Let's Encrypt for automation but DigiCert or Sectigo for EV or OV certificates. - Blocking all issuance:
CAA 0 issue ";"combined withCAA 0 issuewild ";". Use for domains where TLS should never be needed, to prevent any issuance mistakes. - Cloudflare-proxied domains: Cloudflare issues certificates using DigiCert or Let's Encrypt depending on the plan. Check your Cloudflare plan and set CAA accordingly if you also issue your own certificates for non-proxied hostnames on the same domain.
When in doubt, query your existing certificates to find which CA issued them (visible in the certificate's issuer field), then look up that CA's CAA policy domain from their Certificate Policy document or their public documentation.
CAA and DNSSEC
CAA records are DNS records and inherit all of DNS's weaknesses. Without DNSSEC, an attacker who can manipulate DNS responses between the CA and your authoritative server can substitute their own CAA records (or return NXDOMAIN to imply no restriction). CAs are required to check CAA but the check is only as trustworthy as the DNS infrastructure.
DNSSEC signs CAA records cryptographically. A CA performing DNSSEC-aware validation can verify that the CAA response is authentic and unmodified. Some CAs (particularly those performing Multi-Perspective Issuance Corroboration) query from multiple vantage points, making BGP-based DNS poisoning harder — but DNSSEC eliminates the attack entirely.
If you are publishing CAA records for security purposes (not just compliance), DNSSEC on your zone is the necessary complement.
How to verify
Query your CAA records directly:
example.com CAAVerify:
- The CA name in the record matches exactly what your CA expects (check their documentation — not all CAs use their main domain as the policy domain)
- If you use
issuewild, it covers the CAs that issue your wildcard certificates - The
iodefaddress is a monitored mailbox - No unexpected CAs are listed
A common mistake is CAA records that look correct but block auto-renewal: if your ACME client is Let's Encrypt and your CAA record says issue "digicert.com" with no Let's Encrypt entry, your next certificate renewal will fail silently until the certificate expires. Check that the CA name in your CAA record matches the issuer in your currently active certificate.
Relationship to DANE
CAA and DANE (TLSA records) are complementary but operate at different layers. CAA restricts who can issue a certificate — it is a pre-issuance control. DANE pins which specific certificate or key is valid for a hostname — it is a post-issuance control enforced by clients at connection time. A domain with both CAA and DANE provides defense in depth: CAA reduces the chance of a rogue certificate being issued, and DANE ensures that even if one is issued, clients that support DANE will not accept it. DANE requires DNSSEC to be meaningful.