← Back to the CAA Record Checker
"CAA record prevents issuance" (or "Blocking CAA record(s) found") is one of the most-repeated error messages on certbot's own GitHub issue tracker and Let's Encrypt's community support forum. It has four distinct causes, and fixing one does not fix the others — a domain can have more than one of these problems layered on top of each other, so work through all four before assuming the record is clean.
A certificate authority does not check only the exact hostname you're requesting a certificate
for. Per RFC 8659's processing rules, if that name has no CAA records of its own, the CA walks up
to its parent domain — then that domain's parent, and so on — until it finds a domain that
publishes a CAA record set, or runs out of domain entirely. A restriction on
example.com applies to staging.example.com,
app.staging.example.com, and every other name under it, unless one of those
subdomains publishes its own CAA record that overrides it.
This tool's "found at" line names the actual domain in the tree the applicable record set lives at — which is frequently a parent domain you weren't thinking about when a subdomain's renewal started failing.
If a CAA record set exists at the applicable name and lists one or more CAs, and the CA you're
trying to use isn't one of them, that CA is required to refuse issuance. This is CAA working
exactly as designed — the fix is adding an issue record naming the CA you actually
want to use (by its own documented issuer domain, e.g. letsencrypt.org for Let's
Encrypt or pki.goog for Google Trust Services), or removing the CAA record set
entirely if you no longer need the restriction.
An issue record whose value is a lone semicolon — 0 issue ";" —
explicitly authorizes no certificate authority at all for non-wildcard
certificates. An issuewild record with the same value does the same specifically for
wildcard certificates. Both are easy to introduce by mistake while hand-editing a zone file (a
stray semicolon left over from a template, or a "block everything while we set this up properly"
placeholder that never got removed), and the fix is simply deleting or replacing the record.
RFC 8659 defines exactly three standard property tags: issue, issuewild,
and iodef. A record can mark any tag — including a custom one, or a typo of
a standard one — with the "critical" flag. When it does, a compliant CA that does not specifically
implement that exact tag must refuse to issue for the domain at all, regardless of any
issue records also present in the set. Since no public certificate authority
implements an arbitrary custom tag, a critical flag on one effectively blocks every CA until the
record is fixed — and it is invisible in a plain record listing that doesn't specifically apply
this rule. This tool flags it explicitly rather than only showing the raw record text.
It reads the CAA record set your DNS publishes and applies the rules above — that is evidence about your DNS configuration, not a guarantee that a specific CA will actually issue. The CA still applies its own domain-validation, rate-limit, and account checks on top of CAA authorization.