--- title: CAA record prevents issuance? How to check CAA records with the CAA Record Lookup description: Let's Encrypt, your hosting panel or your CA refuses to issue a certificate with 'CAA record prevents issuance', or the normal certificate works and the wildcard fails. To check CAA records, look up the domain's issue and issuewild entries and confirm your CA's identifier is listed for the kind of certificate you want. Here's how to do it with the free CAA Record Lookup, a real domain with a split policy, and the exact records to add. canonical: https://watchfor.io/blog/how-to-check-caa-records --- # CAA record prevents issuance? How to check CAA records with the CAA Record Lookup 2026-10-04 · WatchFor Team · Guides · guides, ssl, dns Let's Encrypt, your hosting panel or your CA refuses to issue a certificate with 'CAA record prevents issuance', or the normal certificate works and the wildcard fails. To check CAA records, look up the domain's issue and issuewild entries and confirm your CA's identifier is listed for the kind of certificate you want. Here's how to do it with the free CAA Record Lookup, a real domain with a split policy, and the exact records to add. To check CAA records, look up the CAA set of the domain the certificate is for and read two tags: `issue` lists the certificate authorities allowed to issue normal certificates, and `issuewild` the ones allowed to issue wildcards. If the domain has CAA records and your CA's identifier (for example `letsencrypt.org`) isn't in the right list, issuance fails with "CAA record prevents issuance". If the domain has no CAA records at all, any CA may issue. The free [CAA Record Lookup](/caa-record-lookup) shows every CAA record of a domain, with flags, tags and TTLs, from a real WatchFor location. No signup. ## What this tool answers *Which certificate authorities may issue for this domain, and for which kind of certificate?* Reach for it when a certificate order or an automatic renewal fails with a CAA error, when you switch CAs or CDNs, when a wildcard certificate fails while a normal one works, or when a security review asks whether your domain restricts issuance at all. ## A real example ### Checking CAA records when only some CAs can issue A scenario behind many CAA tickets: a team adds a wildcard certificate from a CA it already uses for normal certificates, and the order is refused. The policy can allow a CA for one kind of certificate and not the other. We looked up a domain with exactly that kind of split policy. In the [CAA Record Lookup](/caa-record-lookup) we typed `github.com`, kept the resolver on **Auto** and pressed **Run lookup**: ![The CAA Record Lookup result for github.com: 37 ms, NOERROR, 7 records, each with flag 0, TTL 3600 and type CAA: issuewild digicert.com, issue sectigo.com, issue letsencrypt.org, issuewild sectigo.com, issue digicert.com, issue globalsign.com and issuewild letsencrypt.org](/blog/how-to-check-caa-records-result.webp) The lookup returned `NOERROR` with **7 CAA records** in 37 ms, all with flag `0` and a TTL of 3,600 seconds. Sorted by tag: | CA identifier | `issue` (normal certificates) | `issuewild` (wildcards) | | --- | --- | --- | | digicert.com | Yes | Yes | | sectigo.com | Yes | Yes | | letsencrypt.org | Yes | Yes | | globalsign.com | Yes | **No** | GlobalSign may issue a certificate for `github.com` itself, but not for `*.github.com`: because an `issuewild` set exists, it alone decides wildcards (RFC 8659), and GlobalSign isn't in it. Every other CA in the world is refused for both kinds. The certificate GitHub actually serves today comes from Sectigo, which both lists allow (see the command line section). **The answer:** a GlobalSign wildcard order for this domain would fail with a CAA error, and a normal GlobalSign certificate would succeed. For your own domain, find your CA's identifier in its documentation and check it appears under the tag you need. ## How to read the results | Field | What it means | | --- | --- | | **tag** | `issue`: may issue certificates for this name. `issuewild`: may issue wildcard certificates; when present, it overrides `issue` for wildcards. `iodef`: where CAs may report refused requests (a `mailto:` or URL). | | **value** | The CA's identifier, such as `letsencrypt.org`, `digicert.com`, `sectigo.com` or `pki.goog`. May carry parameters after a `;`. A value of `;` alone forbids all issuance for that tag. | | **flag** | `0` normally. `128` marks the record critical: a CA that doesn't understand the tag must refuse. | | **ttl** | Seconds the record may be cached (or what's left on a cached copy). | | **NOERROR, 0 records** | The name has no CAA records of its own. CAs then check the parent domain; if no level has any, every CA may issue. | | **Resolve time** | Green under 50 ms, amber under 200 ms, red above. | The rows appear in the order the resolver returned them; group them by tag when you read them. ## More ways to use it - **Before switching CAs or CDNs.** CDNs such as Cloudflare or Fastly issue certificates from their own CA partners. If your domain has CAA records, those CAs must be listed before you move. - **When automatic renewal suddenly fails.** Someone may have added CAA records since the last renewal, listing a different CA. The lookup shows the current policy in one step. - **Locking down issuance.** If your domain has no CAA records, any CA can issue for it. Adding `issue` records for the CAs you use reduces the risk of a mis-issued certificate. - **Getting reports.** An `iodef "mailto:security@example.com"` record asks CAs to tell you about refused requests. Support for it varies by CA. ## Tips and gotchas - **Subdomains inherit.** A name with no CAA records of its own uses the closest parent's set. `docs.github.com` has none, so a CA checks `github.com` and applies those seven records. - **CNAMEs are followed.** If a name is a CNAME, CAs look at the target's CAA records first. A vendor's CAA policy can therefore decide what may be issued for your aliased subdomain. - **Use the CA's exact identifier.** Let's Encrypt is `letsencrypt.org`, Google Trust Services `pki.goog`; Amazon publishes several (`amazon.com`, `amazontrust.com`, `awstrust.com`, `amazonaws.com`). The CA's docs list its own. - **Fix for "CAA record prevents issuance":** add `0 issue ""` at the domain (and `0 issuewild ""` if the domain has `issuewild` records and you need a wildcard), wait for the old records' TTL, then retry. - **CAs check at order time.** Since 2017 every public CA must check CAA before issuing. Removing a CA later doesn't revoke its existing certificates. - **Broken DNS blocks issuance too.** If the CAA lookup times out or returns `SERVFAIL`, CAs refuse, so a zone with broken nameservers can't get certificates. ## Check it from the command line too ```bash dig +noall +answer CAA github.com @1.1.1.1 | sort -k6 ``` ```text github.com. 3600 IN CAA 0 issue "digicert.com" github.com. 3600 IN CAA 0 issue "globalsign.com" github.com. 3600 IN CAA 0 issue "letsencrypt.org" github.com. 3600 IN CAA 0 issue "sectigo.com" github.com. 3600 IN CAA 0 issuewild "digicert.com" github.com. 3600 IN CAA 0 issuewild "letsencrypt.org" github.com. 3600 IN CAA 0 issuewild "sectigo.com" ``` A subdomain with no CAA records of its own returns an empty answer; dig doesn't climb to the parent, but CAs do: ```bash dig docs.github.com CAA @1.1.1.1 | grep -E "status|ANSWER:" ``` ```text ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46973 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ``` And the certificate in use, to compare its issuer with the policy: ```bash echo | openssl s_client -connect github.com:443 -servername github.com 2>/dev/null \ | openssl x509 -noout -issuer -enddate ``` ```text issuer=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV E36 notAfter=Nov 29 23:59:59 2026 GMT ``` ## Keep watching it CAA records rarely change, so a change is worth knowing about before the next renewal fails. A [DNS monitor](/dns-monitoring) on the **CAA** record type re-checks the set on a schedule, and with **Expected DNS Records** (one CA identifier per line, such as `letsencrypt.org`) it opens an incident when the policy no longer lists your CA. For the certificate itself, an [SSL monitor](/ssl-monitoring) warns before it expires. ## FAQ **What does "CAA record prevents issuance" mean?** The domain (or a parent) publishes CAA records, and the CA you ordered from isn't listed for that type of certificate. Add the CA's identifier with an `issue` record, or an `issuewild` record for wildcards, then retry once the old records' TTL has passed. **Do I need a CAA record?** No. Without one, any public CA may issue for your domain. Adding one limits issuance to the CAs you choose, which reduces the damage a mis-issuing CA could do. [How HTTPS works](/blog/how-https-works) covers certificates in general. **How do I add a CAA record for Let's Encrypt?** At your DNS host, add a CAA record on the domain with flag `0`, tag `issue` and value `letsencrypt.org`; add the same with tag `issuewild` if you use wildcard certificates and the domain already has `issuewild` records. Then check it with the [SSL certificate guide](/blog/how-to-check-an-ssl-certificate) once the certificate is issued. --- Canonical page: https://watchfor.io/blog/how-to-check-caa-records · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt