CAA record checker

Type a domain or a subdomain: you see the CAA records that apply to it, where they are published, which certificate authorities may issue ordinary and wildcard certificates, and the errors that would make an authority refuse.

The DNS lookups go straight from your browser to public resolvers (Cloudflare, Google): we see nothing.

What the checker looks at

The records that apply: An authority looks for CAA records on the exact name, then on each parent up to the domain. The first name that has some decides; the others are ignored. The checker follows the same path (RFC 8659).
issue and issuewild: “issue” lists the authorities allowed to issue. “issuewild” overrides it for wildcard certificates; without it, wildcards follow “issue”. A value of “;” allows nobody.
iodef: Where an authority can report a request it refused: a mailto: or https: address. Optional, but it is how you hear about an attempt.
Syntax and flags: A record that cannot be read, or an unknown tag marked critical (flags 128), makes authorities refuse to issue for the name.

How to read the result

No CAA record anywhere: Any certificate authority may issue for the domain. Nothing is broken; you are only not using a free restriction.
A list of authorities: Only these may issue. Before changing certificate provider or enabling a CDN or a hosting platform, add its authority here first, or its certificates will fail to renew.
Records inherited from the parent: A subdomain without CAA records of its own follows those of the domain. A subdomain hosted elsewhere may need records of its own.

Errors people run into

The messages certificate authorities and platforms give when CAA stops a certificate, and what to do.

CAA record for example.com prevents issuance

Why. The CAA records that apply to the name do not list the authority that was asked, often after moving to a platform that uses another authority (Let’s Encrypt, Google Trust Services, Sectigo…).

Fix. Add an “issue” record with the name that authority documents (for example letsencrypt.org or pki.goog), on the domain or on the subdomain concerned, then ask for the certificate again.

SERVFAIL looking up CAA

Why. The authority could not get an answer to its CAA question: a DNS server that does not answer the CAA type, or broken DNSSEC. It then refuses in most cases, and always when the zone is signed with DNSSEC, even if no CAA record exists.

Fix. Check that every name server of the zone answers CAA queries (an empty answer is fine, an error is not), and that DNSSEC validates.

Wildcard certificate refused

Why. An “issuewild” record exists and does not list the authority, or says “;”: it replaces “issue” for wildcard names.

Fix. Add the authority to “issuewild”, or remove the “issuewild” records so that wildcards follow “issue” again.

Questions

Is a CAA record required?

No. Authorities must check it since 2017, but a domain without one is valid: anyone may issue. Publishing one limits the damage of a mistake or of a compromised account at an authority you do not use.

Does CAA affect certificates already issued?

No. It is read when a certificate is issued or renewed, not by browsers. An existing certificate stays valid until it expires.

Which name do I write for my authority?

The one the authority documents, not its brand: letsencrypt.org, pki.goog, digicert.com, sectigo.com, amazon.com… The checker names the authorities it recognises.

Do you send anything to our servers?

No. The lookups go from your browser to public resolvers (Cloudflare, Google); we see neither the domain nor the result.