Home/CAA Record Lookup
[ D.4 — CAA ]

CAA Record Lookup

Check which Certificate Authorities are authorised to issue SSL/TLS certificates for a domain — and whether wildcard issuance is restricted. Walks parent domains per RFC 8659.

Last reviewed: May 2026

// look up CAA records
Reads CAA records via Cloudflare DoH. If none at the exact name, walks up the parent labels until a record is found or the TLD is reached.
Try: google.com cloudflare.com github.com letsencrypt.org

What is CAA?

Certification Authority Authorization (RFC 8659) is a DNS record type that tells Certificate Authorities which of them are allowed to issue certificates for your domain. Before issuing, every publicly-trusted CA is required (since September 2017, per CA/Browser Forum baseline requirements) to check for CAA records. If your domain has a CAA record and the requesting CA isn't listed, the CA must refuse to issue.

It's defence in depth against misissuance. Certificate Transparency catches unauthorised certs after they're issued. CAA prevents them being issued in the first place. The two are complementary — see our CT log search for the after-the-fact side.

How CAA works

A CAA record has the format flag tag value. The flag is a small integer (the high bit, 128, means "critical" — CAs that don't understand the tag must refuse to issue). The tag is one of issue, issuewild, iodef, contactemail, or contactphone. The value depends on the tag.

When a CA needs to validate, it queries CAA at the exact domain. If no record exists, it walks up the parent labels — api.mail.example.com → mail.example.com → example.com — until a record is found or the public suffix is reached. The most specific record wins; once found, the walk stops.

The three tags that matter

  • issue — authorises a CA for regular (non-wildcard) certificates. Multiple issue records add multiple CAs to the allowlist. An empty value (issue ";") denies issuance for everyone.
  • issuewild — same idea, but for wildcard certificates (*.example.com). If issuewild is absent, wildcards follow the issue policy. To deny wildcards entirely while still allowing non-wildcards, set issuewild ";".
  • iodef — where to send incident reports if a CA encounters a policy violation. Usually a mailto: URL. Pair with contactemail / contactphone (RFC 9495) for the validation team.

Why set CAA records

Three reasons, in order of how often they actually matter:

  • Defence against compromised CAs. If an attacker tricks or compromises a CA's domain-validation process, a CAA check will still prevent that CA from issuing a cert for your domain — provided the CA isn't on your allowlist.
  • Defence against rogue issuance inside your org. A developer with access to one CA can't accidentally start cutting certs from another CA's portal, because the unauthorised CA will refuse the request.
  • Compliance / audit signal. Auditors and security questionnaires increasingly ask whether you have CAA records. Setting them is cheap signal that you take cert hygiene seriously.

Setting up CAA takes about 30 seconds in any DNS provider's web UI — one TXT-style record per authorised CA, plus an iodef for reports. The hard part is remembering to update it when you switch CAs.

What this tool doesn't do

We don't cross-reference the CAA policy against the certificate currently being served. For that, the SSL inspector shows the live cert and its issuer — eyeball it against the authorised CAs here. We also approximate the "stop at public suffix" rule by stopping one label before the TLD, which is correct for single-label TLDs (.com, .org) but conservative for two-label suffixes like .co.uk; for those, the walk stops one step early. In practice it's a non-issue because the relevant CAA records are almost always at the eTLD+1 anyway.