CAA DNS records explained: control which certificate authorities can issue for your domain

By default, any publicly trusted certificate authority (CA) may issue a TLS certificate for your domain once it has validated that you control it. A CAA (Certification Authority Authorization) DNS record narrows that list to the CAs you actually use, so a validation mistake at some other CA cannot produce a valid certificate for your name.

CAA is defined in RFC 8659, with optional account and method restrictions in RFC 8657. The CA/Browser Forum Baseline Requirements oblige every public CA to check CAA before issuing.

How a CA reads CAA

• No CAA record anywhere above the name means no restriction: any CA may issue.
• Tree climbing. For www.shop.example.com the CA looks for CAA at that name, then shop.example.com, then example.com, and stops at the first name that has CAA records. A record on your registered domain therefore covers all subdomains unless a subdomain has its own.
• CNAMEs are followed. If a subdomain is a CNAME to a provider's hostname, the CAA records at the target apply.
• Records are additive. If any issue record names the CA, that CA may issue.
• Timing. The CA must issue within the CAA record's TTL or 8 hours after checking it, whichever is longer, so a change takes effect within roughly that window.

The three tags you need

Each record has a flag: 0 in almost all cases. Flag 128 marks the record as critical, which tells a CA that does not understand the tag to refuse issuance. An issue value of ";" (no CA name) forbids issuance, and a malformed value is treated the same way.

Before you publish anything

List every CA that issues certificates for your names today: your website, mail server, CDN or load balancer, and any SaaS service that serves content on one of your subdomains. A CAA record that leaves one out will not break anything immediately, but that certificate's next renewal will fail. Check the issuer of each live certificate:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer

The issuer name is not the value you put in CAA. Each CA documents its own CAA identifier in its policy documents; for Let's Encrypt it is letsencrypt.org, per its CAA documentation.

Examples

Allow only Let's Encrypt, forbid wildcard certificates, and ask for reports of refused requests:

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

Allow two CAs (records are additive), replacing ca2.example with the second CA's documented identifier:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "ca2.example"

Give one subdomain hosted elsewhere its own policy, which overrides the parent's:

api.example.com.  3600  IN  CAA  0 issue "ca2.example"

Locking to an account or validation method

RFC 8657 adds two parameters after the CA name. validationmethods limits how the CA may check domain control; Let's Encrypt recognises http-01, dns-01 and tls-alpn-01. accounturi limits issuance to one ACME account, so someone who briefly hijacks your web server or DNS cannot use their own account:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"

Today the Baseline Requirements say CAs SHOULD process these parameters; from 15 March 2027 they MUST. Use them only once your account URI and validation method are stable, because recreating the ACME account or switching from HTTP to DNS validation will then block renewals until you update the record.

Checking your records

dig example.com CAA +short
dig www.example.com CAA +short

An empty answer for www is normal; the CA will climb to example.com. To see what your DNS host is publishing without any resolver cache, ask one of your authoritative nameservers directly:

dig @ns1.your-dns-host.example example.com CAA +norecurse

Pitfalls that block issuance

• DNS servers that mishandle CAA queries. A nameserver must answer an unknown or empty query type with NOERROR. One that returns NOTIMP or SERVFAIL makes the CA unable to tell whether CAA allows it, and it will refuse.
• Broken DNSSEC. Since 15 March 2026 CAs must validate DNSSEC on CAA lookups and must not treat a validation error such as SERVFAIL as permission. Let's Encrypt notes that some signers produced bad signatures only for empty answers, which is exactly what most CAA queries return.
• A forgotten third party. A marketing platform or help desk tool that issues certificates for a subdomain you pointed at it will fail at renewal unless its CA is listed, or the subdomain is a CNAME and the provider's own CAA applies.
• Typos and critical flags. A malformed value forbids issuance; a flag of 128 on a tag a CA does not know stops that CA.

What you should do

• Inventory every CA that issues for your domain and subdomains before adding CAA.
• Start with a simple issue record per CA on the registered domain, plus issuewild ";" if you never use wildcards.
• Add an iodef contact you actually read.
• Verify with dig ... CAA against your authoritative nameserver, then test a renewal.
• Consider accounturi and validationmethods once your ACME set-up is stable.
• If you sign the zone with DNSSEC, monitor it: a validation failure now stops certificate issuance.

Sources

• rfc-editor.org/rfc/rfc8659.html
• rfc-editor.org/rfc/rfc8657.html
• letsencrypt.org/docs/caa
• cabforum.org/working-groups/server/baseline-requirements/documents
• github.com/cabforum/servercert/blob/main/docs/BR.md
• manpages.debian.org/trixie/bind9-dnsutils/dig.1.en.html