CAA Record Checker

Server assisted New DNS & Domains

Look up the CAA records of a host name and, when it has none, of each parent domain in turn, as a certificate authority does under RFC 8659. The checker shows which name's CAA set applies, which authorities may issue normal and wildcard certificates, the iodef address for violation reports, and parameters such as accounturi and validationmethods (RFC 8657).

Privacy: The name you look up is sent from the Mutqan server to the public DNS resolvers named in the results. Nothing is stored.

What is a CAA record?

A CAA record (RFC 8659) names the certificate authorities allowed to issue certificates for a domain: issue for ordinary certificates, issuewild for wildcards and iodef for where to report violations. Publicly trusted CAs must check it before issuing: they look at the name, then climb to its parent domains, and the closest CAA set found applies; when there is none anywhere, any CA may issue.

How to use CAA Record Checker

  1. Type the name the certificate is for — www.example.com, or example.com for a wildcard *.example.com.
  2. Optionally type a certificate authority's CAA domain to test it, such as letsencrypt.org.
  3. Press Check CAA and read which name's CAA set applies and who may issue.
  4. Read the findings; to change the policy, edit the CAA records at the name shown and check again.

CAA Record Checker features

  • The CAA climb of RFC 8659 run for you: the name first, then each parent domain until a CAA set is found
  • Which name's CAA set applies, with every record in it: flags, property, value and what it means
  • Who may issue ordinary certificates and who may issue wildcards, with issuewild taking precedence over issue as the RFC requires
  • An optional test of one CA: enter the domain it documents for CAA (letsencrypt.org, pki.goog, digicert.com…) to see whether it may issue
  • The settings that block issuance flagged: issue ";", malformed values and unknown properties marked critical
  • accounturi and validationmethods parameters (RFC 8657) and iodef report addresses shown as published
  • A failed lookup stops the climb and is reported as unknown, never as "no CAA" — and a request limit or a timeout on the way is shown as such, not as a fault of your DNS

Inputs and outputs

Inputs

  • Domain or host name — the name a certificate covers; for a wildcard (*.example.com) the climb starts at example.com, and a leading "*." is removed for you.
  • Certificate authority to test (optional) — the CA's CAA domain as the CA documents it, for example letsencrypt.org, pki.goog, sectigo.com or digicert.com.

Outputs

  • Summary — the name whose CAA set applies, and how many CAs may issue certificates and wildcard certificates, or "any CA".
  • Names checked — each name of the climb with its result: CAA records found, no CAA records, an alias without records, NXDOMAIN or a failed lookup.
  • CAA records that apply — every record with its flags, property, value and meaning.
  • Who may issue — the CA domains allowed for certificates and for wildcards, and the iodef addresses.
  • Findings and What to do next — the evaluation in plain language, including the answer for the CA you tested.

CAA Record Checker example

A subdomain covered by its parent's CAA set (docs.github.com, October 2026)

Input:

docs.github.com

Output:

CAA set that applies: github.com (found at a parent domain) · Certificates: 4 · Wildcard certificates: 3
Names checked: docs.github.com — no CAA records · github.com — CAA records found
Who may issue — Certificates: digicert.com, globalsign.com, letsencrypt.org, sectigo.com · Wildcard certificates: digicert.com, letsencrypt.org, sectigo.com · Violation reports (iodef): —
Findings: The name has no CAA records of its own; the set published at a parent domain applies to it — github.com

How to read the CAA Record Checker results

"any CA": no CAA set applies, or the set has no issue or issuewild record; CAA does not restrict issuance, and any publicly trusted CA that validates your domain may issue.

A list of CAs: only those CAs may issue for the name. A CA missing from the list must refuse — including one your CDN or hosting provider relies on.

"no CA": the set forbids issuance — issue ";" for ordinary certificates, issuewild ";" for wildcards, or a critical property the CA does not understand.

Found at a parent domain: the name has no records of its own and inherits the parent's set. Add records at the name only when it needs a different policy.

"unknown — a lookup failed": the resolver answered SERVFAIL, REFUSED or another error for one name of the climb. A CA that meets the same error may refuse to issue, so fix the DNS first.

"unknown — the check was not completed" or "unknown — the climb was cut short": a lookup was stopped by a request limit, a timeout or a network error, or the name has more than 20 levels. Nothing is concluded about the zone; run the check again, or check the next parent domain the page names.

When to use CAA Record Checker

  • Finding out why a CA refused to issue or renew a certificate with a CAA error.
  • Checking that a new provider — a CDN, a hosting platform, a managed certificate service — is allowed before you switch.
  • Limiting issuance to the CAs you use, and wildcard certificates to where you need them.
  • Reviewing subdomains run by other teams or vendors, which inherit the parent's CAA unless they publish their own.

Troubleshooting

  • A CA reports a CAA error although the domain lists it: check the exact CAA domain the CA documents (Google Trust Services is pki.goog, for example) and whether the name is a wildcard governed by issuewild rather than issue.
  • The name is an alias (CNAME) to a provider: the CAA answer comes from the alias target, and the climb continues to your parent domain only when that target has no CAA records. A restrictive set at the target can only be changed by its owner.
  • "unknown — a lookup failed": the authoritative servers answered the CAA query with an error. Some old DNS servers reject the CAA type; check them with the Nameserver Checker and update the DNS software or move to another provider.
  • The request-limit message: each name of the climb is one DNS query from your share of the DNS tools' budget; wait the seconds shown and try again. A limit reached part-way shows as "unknown — the check was not completed".

Frequently asked questions about CAA Record Checker

What happens when a domain has no CAA records?

CAA is opt-in. When neither the name nor any parent domain publishes a CAA record, every publicly trusted certificate authority may issue for it, as long as its domain validation succeeds.

Does a CAA record on example.com cover www.example.com?

Yes, unless www.example.com has CAA records of its own. A CA looks at the name first and climbs one label at a time to the parent domains; the first CAA set it finds is the one that applies, and the checker tells you which name that was.

What is the difference between issue and issuewild?

issue lists the CAs allowed to issue certificates for the name; issuewild lists those allowed to issue wildcard certificates (*.example.com). When there is no issuewild record, issue applies to wildcards too. A value of ";" allows no CA at all.

How do I allow a certificate authority in CAA?

Add a record with the domain the CA documents for CAA, for example 0 issue "letsencrypt.org" for Let's Encrypt or 0 issue "pki.goog" for Google Trust Services. Keep one issue record per CA you use, and remember that your CDN or hosting provider may issue certificates through its own CAs.

Does a CAA record affect certificates that already exist?

No. CAs check CAA only at the moment of issuance; certificates issued earlier stay valid until they expire or are revoked. CAA also cannot stop a CA that ignores the rule, which is why the iodef contact and Certificate Transparency monitoring are useful.

Technical notes

A CAA record (RFC 8659) has a flags byte, a property tag and a value. issue names a CA allowed to issue certificates for the name and its subdomains, with optional parameters after a semicolon; issuewild does the same for wildcard certificates and, when present, takes precedence over issue for them; iodef gives a mailto: or https: address for reports. Authorisations add up across records, an issue value of ";" names no CA, and a malformed value counts as an empty one.

Before issuing, a CA queries CAA for the name — its resolver follows a CNAME as for any lookup — and, while the answer is empty, for each parent domain in turn; the first non-empty set is the one that applies. A set without issue or issuewild does not restrict issuance, and an unknown property carrying the critical flag (128) forbids it. The CA/Browser Forum Baseline Requirements have obliged every publicly trusted CA to perform this check since September 2017.

The checker runs the same climb with one public DNS query per name, sent from the Mutqan server at the Cloudflare edge, for up to 20 names; the top-level domain itself is not queried, and a climb cut short at 20 names without finding records is reported as unknown. The CA you test is compared with the issue and issuewild values in your browser.

Limitations and methodology

The climb stops below the top-level domain, because single-label names such as com cannot be queried here. TLDs do not normally publish CAA records, but this check does not prove it.

At most 20 names are checked, a cap ordinary names stay far below. A deeper name that finds no records within those 20 is reported as unknown, never as "any CA may issue".

Records are read through Cloudflare's public resolver. A CA uses its own resolvers, usually with DNSSEC validation, and may see a different answer for a while after a change.

CAA is consulted only at issuance: the checker cannot tell whether existing certificates came from an allowed CA. The Certificate Transparency Lookup shows those.

Security and privacy

The name you enter and its parent domains go to the Mutqan server, which asks Cloudflare's public DNS over HTTPS for their CAA records. The CA you test is compared in your browser and never sent. Nothing is stored.

References