CAA Record Checker Online Free

Q: What does a CAA record actually do?

A CAA record (RFC 8659 Hallam-Baker, Stradling & Hoffman-Andrews, 2019; obsoletes RFC 6844 from 2013) tells Certificate Authorities whether they are allowed to issue certificates for your domain. Since 8 September 2017 the CA/Browser Forum Baseline Requirements §3.2.2.8 (Ballot 187, version 1.4.3) require all publicly trusted CAs to check CAA before issuance — non-compliance can revoke a CA's trust anchor at the root program level. If your record allows only Let's Encrypt and someone requests a certificate from a different CA, that CA must refuse. Without a CAA record, any publicly trusted CA can issue for your domain, including an attacker who tricks a different CA via social engineering or relaxed validation.

Q: What's the difference between issue and issuewild?

The `issue` tag authorises a CA to issue standard certificates for the domain. The `issuewild` tag controls wildcard certificates (*.example.com) specifically. If you publish `issuewild` records, wildcards fall under that policy and ignore `issue` per RFC 8659 §4.3. If you publish only `issue` records, wildcards inherit it. A common pattern: allow Let's Encrypt for standard certificates via `issue`, but exclude all wildcards by publishing `issuewild` with the value `;` (empty parameter syntax) to refuse every CA.

Q: Does CAA apply to the apex or to subdomains?

CAA is inherited down the DNS tree. A CA checks the exact domain first, then walks up per RFC 8659 §3: `api.app.example.com` → `app.example.com` → `example.com`. The first zone with CAA records applies — that's why PingThat shows 'Policy inherited from X' when a subdomain has no records but an ancestor does. Publishing policy at the apex covers everything below it; subdomain-specific records override the apex policy for that branch only. The critical-bit flag (issuer-critical, value 128) makes CAs that don't recognise a tag refuse issuance — useful for forward-compatible policy deployment.

Q: What happens if I don't publish CAA?

Any publicly trusted CA can issue certificates for your domain. That's how most of the internet operates today, and for most sites it's acceptable because of Certificate Transparency — any mis-issuance gets logged publicly to CT logs (Chrome's policy since 2018 requires CT inclusion for all publicly trusted certs) and detection tools like crt.sh surface unexpected issuance. CAA adds a complementary prevention layer: five minutes of DNS configuration blocks an entire class of attacks involving misled or compromised CAs. Best practice is to layer both — CAA for prevention at issuance time, CT monitoring for detection after-the-fact.

Q: Can I restrict CAA to a specific ACME account or validation method?

Yes. RFC 8657 (Landau, November 2019) added two parameter extensions. The `accounturi` parameter restricts issuance to a specific ACME account URI: even if the CA is allowed by an `issue` record, only certificate requests originating from the exact account succeed. The `validationmethods` parameter limits which domain-validation methods (DNS-01, HTTP-01, TLS-ALPN-01) the CA may use — preventing an attacker who compromised your DNS but not your HTTPS endpoint from passing DNS-01. Both parameters appear after the CA name in the issue record, e.g. `0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123; validationmethods=dns-01"`. Adoption is still partial across CAs — Let's Encrypt's Boulder honours both since 2022.

CAA Record Checker — Authorise CAs, Block Rogue Issuance

CAA (Certification Authority Authorization, RFC 8659 Hallam-Baker, Stradling & Hoffman-Andrews 2019, obsoleting RFC 6844) is a DNS record type that lets domain owners specify which Certificate Authorities are authorised to issue certificates for their domain. Since 8 September 2017 the CA/Browser Forum Baseline Requirements §3.2.2.8 (Ballot 187, version 1.4.3) require all publicly trusted CAs to check CAA before issuance — a CA that ignores or misapplies CAA can lose its trust anchor at the root program level. The record syntax has three property tags: issue authorises a specific CA to issue any certificate, issuewild controls wildcard certificates separately, and iodef points to an incident-reporting endpoint (RFC 5070 IODEF format) where the CA reports policy violations. RFC 8657 (Landau, 2019) added accounturi and validationmethods parameters that further restrict issuance to specific ACME accounts and validation methods. This tool retrieves CAA records via Cloudflare DNS-over-HTTPS, walks up the DNS tree from the queried FQDN to the apex showing inherited policies, and flags the critical-bit (flags=128) when set.

How to check CAA records

Enter a domain name (FQDN or apex).
The tool queries the CAA record via Cloudflare DoH, then walks up the DNS tree if the FQDN has none — reporting inherited policies from ancestor zones (RFC 8659 §3).
Review the issue, issuewild, and iodef values; the critical bit (flags=128) is highlighted when set.
If the policy is empty or wrong, fix the DNS records before your next certificate renewal — issuance will fail per CA/Browser Forum BR §3.2.2.8.

Common use cases

Locking down certificate issuance to a single CA (e.g., Let's Encrypt) for a domain to reduce mis-issuance risk.
Debugging an ACME issuance failure that complains about CAA mismatches.
Auditing which CAs are authorised for a domain before a security review or compliance audit.
Adding iodef contacts (RFC 5070 IODEF) so unauthorised issuance attempts are reported to the security team.

Frequently asked questions

What does a CAA record actually do?

RFC 8659 (2019, obsoleting RFC 6844) lets a domain restrict which CAs can issue certificates for it. Since 8 September 2017 (CA/B Forum BR §3.2.2.8), all publicly trusted CAs MUST check CAA before issuance — a non-compliant CA loses its root-program trust anchor.

What's the difference between issue and issuewild?

issue authorises a CA to issue standard certificates. issuewild controls wildcards (*.example.com) specifically. If issuewild is published, wildcards follow it ignoring issue. Pattern: allow LE for standard via issue, exclude wildcards by publishing empty issuewild.

Does CAA apply to the apex or to subdomains?

Inherited down the DNS tree — checks exact name first, then walks up: api.app.example.com → app.example.com → example.com. First zone with CAA records applies (RFC 8659 §3). Publish at apex to cover everything below.

What happens if I don't publish CAA?

Any publicly-trusted CA can issue certificates for your domain. Most domains operate this way — Certificate Transparency logs catch mis-issuance after-the-fact via monitoring. CAA adds a prevention layer at issuance time.

Can I restrict CAA to a specific ACME account or validation method?

Yes — RFC 8657 (Landau, 2019) added accounturi and validationmethods parameters. accounturi restricts issuance to a specific ACME account URI; validationmethods limits which DV methods (DNS-01, HTTP-01, TLS-ALPN-01) the CA may use. Let's Encrypt Boulder honours both since 2022.

How the tree-climbing lookup works and how CAA layers with Certificate Transparency

Without a CAA record, any CA in the publicly-trusted root programs (browsers, OS root stores) can issue a certificate for your domain — the constraint is procedural (CA's own validation policy) rather than enforced. CAA tightens this to a procedural-plus-DNS check: the CA queries the CAA record before issuing, and refuses if the policy excludes them. The lookup walks up the DNS hierarchy: a request for mail.api.example.com first checks mail.api.example.com, then api.example.com, then example.com, stopping at the first zone with CAA records (RFC 8659 §3). This means publishing CAA at the apex covers everything below; subdomain-specific records override apex policy for that branch. The critical-bit flag (issuer-critical, value 128) tells unrecognised-tag-handling: if a CA encounters a tag it doesn't understand AND the critical bit is set, it MUST refuse issuance. Use this to deploy new tag types without breaking older CAs. CAA does not replace Certificate Transparency monitoring — CT logs (cross-referenced via tools like crt.sh) catch mis-issuance after-the-fact while CAA prevents it during issuance. The two layer well: CAA for prevention, CT for detection.

CAA record retrieval via Cloudflare DNS-over-HTTPS (RFC 8659)
Tree-climbing lookup from FQDN to apex (inherited policies surfaced)
Tags supported: issue, issuewild, iodef + RFC 8657 accounturi/validationmethods
Critical-bit flag detection (flags=128 unrecognised-tag enforcement)
Mandatory CAA check per CA/Browser Forum BR §3.2.2.8 (effective 2017-09-08)
Inheritance trace from subdomain to apex with explicit chain

Free. No signup. Browser tools (subnet, JWT, password strength) run locally; lookup tools query public APIs (Cloudflare DoH, RDAP, certificate logs). Full per-tool breakdown at /methodology/.

Sources (5)

Hallam-Baker, P., Stradling, R., & Hoffman-Andrews, J. (2019). DNS Certification Authority Authorization (CAA) Resource Record. RFC 8659, IETF (obsoletes RFC 6844).
Hallam-Baker, P., & Stradling, R. (2013). DNS Certification Authority Authorization (CAA) Resource Record. RFC 6844, IETF (original spec, obsoleted by RFC 8659).
Landau, H. (2019). CAA Record Extensions for Account URI and ACME Method Binding. RFC 8657, IETF (accounturi, validationmethods parameters).
CA/Browser Forum (2017). Baseline Requirements §3.2.2.8 — CAA Records (Ballot 187 v1.4.3). Effective 8 September 2017 (cabforum.org).
Danyliw, R., Meijer, J., & Demchenko, Y. (2007). The Incident Object Description Exchange Format (IODEF). RFC 5070, IETF (iodef tag context for incident reporting).

These are the IETF RFCs, NIST publications, and W3C standards the tool implements or queries. Locate them on the IETF Datatracker (datatracker.ietf.org) or the official standards body.

Related guides

SSL Certificate Monitoring — What to Watch and When to AlertPractical guide to monitoring TLS certificates — expiry thresholds, CAA records, OCSP stapling, and what actually breaks in production.

By Marco B. · Last verified June 2026 — runs in your browser