CAA: who is allowed to issue your certs

$ dig @1.1.1.1 letsencrypt.org CAA

What to publish#

CAA record reference has the record shape and field syntax. The policy decision is this checklist:

• [ ] issue for every CA you use. Nothing here means any public CA is authorized to issue (RFC 8659 §1).
• [ ] issuewild too, if you issue wildcards. Without it, issue covers wildcards by default (RFC 8659 §4.3).
• [ ] iodef (optional) for misissuance reports. CAs SHOULD send them, not MUST, and only to a mailto: or https: address (CA/Browser Forum Baseline Requirements §4.2.2.1).
• [ ] accounturi= (optional) to pin issuance to one ACME account (RFC 8657); any CA can implement it, ACME or not.

Check it#

Query a public resolver directly, past any local cache, with the dig example on the CAA record reference. Confirm DNSSEC covers the answer too (DNSSEC) since the Baseline Requirements have required CAs to DNSSEC-validate their own CAA lookup since 2026-03-15, and to treat a validation failure as deny, never as permission (BR §4.2.2.2.2, §4.2.2.2.5).

Gotchas that bite#

• The tree climb. No CAA at the exact name sends the CA up to each parent until it finds one or runs out of tree (RFC 8659 §3). A record on the wrong label does nothing.
• CNAME targets. CAA is checked at the CNAME target, not the CNAMEd name; if the target has none, the climb continues at the original name's own parents, never the target's (RFC 8659 §3). A subdomain CNAMEd to a SaaS provider inherits that provider's policy, not yours.
• Managed DNS providers can widen your policy. Some providers auto-inject CAA records for their own edge-certificate partners once a zone has any CAA record of its own, for example Cloudflare's documented set. Your effective policy is the union of what you wrote and what the provider added; check what your provider does before trusting your own records as the whole picture.
• issue ";" at the apex blocks the whole zone, renewals included (RFC 8659 §4.2). Test it on a subdomain first.
• Checked once, at issuance. Checking CAA has been mandatory for publicly trusted CAs since 8 September 2017 (CA/Browser Forum Ballot 187). Browsers never check it, and tightening your policy does not invalidate certs that already exist (RFC 8659 §1).

See also#

• TLSA: pinning the cert itself in DNS
• DoH and DoT
• nslookup and dig
• CNAME
• All record types
• Query types
• RFC 8659
• RFC 8657
• CAA check: the records a CA reads, from a public resolver