DNS Tools
CERTIFICATE POLICY DIAGNOSTICS

CAA Lookup

See which certificate authorities a domain allows to issue certificates, where in the DNS tree that policy comes from, and whether any property is malformed or unrecognised.

Run CAA records

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What a CAA record does

A CAA (Certification Authority Authorization) record lets a domain owner state which certificate authorities may issue certificates for the name. Before issuing, a public CA is required to look up CAA records and refuse to issue if the policy does not name it. The rules are in RFC 8659. CAA is a control on issuance only; it does not stop a browser from trusting a certificate that was already issued, and it is not a substitute for monitoring certificates.

A CAA record has a flag, a tag and a value. The tags that matter are issue (who may issue certificates), issuewild (who may issue wildcard certificates) and iodef (where a CA can report a request that violated the policy).

How the policy is found: the tree climb

CAA is not read only at the exact name. If the host name has no CAA record, the CA looks at its parent, then the parent of that, up to the top of the domain, and uses the first CAA record set it finds. So a policy at example.com covers www.example.com and shop.eu.example.com unless a closer name publishes its own set, which replaces the parent's rather than adding to it.

This tool performs the same climb and shows a table of every name it tried and what each returned, so you can see where the effective policy comes from.

How to read the result

  • Policy restricts issuance: the tool names the permitted CAs and the name where the policy was found. An issue value of ; alone means that no CA may issue.
  • No CAA anywhere in the tree: reported as a low-severity improvement. With no policy, any public CA may issue for the name. This is the default and is not an error.
  • CAA records without any issue property: informational. They exist but do not restrict who may issue.
  • Wildcard policy: if issuewild is present, it controls wildcard certificates separately. If not, the issue CAs may also issue wildcards.
  • iodef: a valid value is a mailto: or http(s): URL. The tool flags values in another form. Not every CA acts on iodef, so treat it as a courtesy channel.
  • Critical flag on an unknown tag: a record with the critical bit set and a tag the CA does not understand must stop issuance, so the tool reports it as something to improve.
  • A lookup failed during the climb: the effective policy is not concluded. A CA that cannot read CAA must not issue, so a persistent SERVFAIL at a parent can block certificate renewals, and the tool reports the failure rather than assuming there is no policy.

Common CAA problems

  • Policy blocks the CA you actually use: certificate renewals start failing after a CAA record was added that lists a different CA.
  • Forgot the second CA: an organisation that uses a CDN or hosting platform may have certificates issued by that provider's CA on its behalf, which also needs permission.
  • Wrong value format: the CA is given as a domain name, such as letsencrypt.org, in the issue property. A free-text company name does not work.
  • DNSSEC failures at the parent: CAA lookups that return SERVFAIL due to broken signatures prevent issuance entirely.
  • Subdomain override: a subdomain publishes its own CAA set and silently ignores the parent's policy.

How to publish CAA safely

A CAA policy can only block issuance, so the risk is a missed renewal. Start by listing every CA that currently issues certificates for the name and its subdomains, including those used by hosting platforms and CDNs. Then publish a policy that names all of them.

Add the records well ahead of a renewal, and test with the next real issuance or with a CA staging environment where one is offered. Do not add a policy on the same day as a certificate must be renewed.

  1. List the CAs that issue certificates for the domain and its subdomains.
  2. Publish issue entries for each, with issuewild only if wildcards are used.
  3. Optionally add an iodef contact you monitor.
  4. Run this lookup and check the tree climb shows the policy where you expect it.
  5. Confirm that the next certificate issuance or renewal succeeds.
  6. To roll back, delete the CAA records; with none in the tree, any CA may issue again.

Limits of the test

The tool reads DNS and reports the policy as a CA would see it. It cannot tell which CA has actually issued certificates, whether certificates exist for the name, or whether a CA obeys the policy. For issued certificates, use the certificate checks. Results are a single measurement from one scanner and from the system resolver, so a CAA set changed minutes ago can still appear old.

Frequently asked questions

Do I need a CAA record?

It is optional. Without one, any public certificate authority may issue for your name. A CAA record narrows that to the CAs you choose.

Does CAA affect existing certificates?

No. It is checked at issuance time. Certificates already issued stay valid.

Why does the tool look at parent names?

RFC 8659 tells CAs to climb the tree until a CAA set is found, so a policy on your domain covers its subdomains.

What does issue ";" mean?

It forbids issuance by every CA, which is a way to say a name should never get a certificate.

Can a failed CAA lookup stop my certificate renewal?

Yes. CAs must not issue when the CAA lookup fails, for instance with SERVFAIL, so DNS reliability matters.

Is CAA a complete security control?

No. It limits which honest CAs issue, but it is not a monitor for mis-issuance. Certificate transparency logs are the place to watch for that.

Written by DNS Tools editorial · Last updated 2026-10-09