🔐 CAA Lookup Tool

🔍 What Is a CAA Record?

A CAA (Certification Authority Authorization) record, defined in RFC 6844 and later revised in RFC 8659, lets a domain owner publish a DNS-level whitelist of exactly which Certificate Authorities are permitted to issue SSL/TLS certificates for that domain. Before CAA existed, the trust model was structurally flat: any of the hundreds of CAs trusted by major browsers and operating systems could, technically, issue a valid certificate for any domain on the internet, regardless of which CA the domain owner actually intended to use. CAA introduces a domain-controlled restriction directly into that process, checked by the CA itself before issuance.

🔑 PKI & Certificate Authorities, Briefly

Public Key Infrastructure is the broader trust system underlying HTTPS: Certificate Authorities are trusted third parties that verify a domain's control and issue signed certificates vouching for that domain's identity, which browsers then trust based on the CA's own inclusion in a curated root trust store. This trust model has one structural weakness CAA directly addresses — trust in "a CA," generically, rather than trust in "a specific CA I've chosen" for any given domain.

📋 CAA Record Syntax

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issuewild "digicert.com"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

Each CAA record has three components: a flags field (an integer, where 128 marks the record "critical" — meaning a CA must refuse issuance entirely if it doesn't understand the tag, rather than ignoring it), a tag (issue, issuewild, or iodef), and a value (typically the authorized CA's domain, or a notification address for iodef).

🏷️ The issue, issuewild & iodef Tags

If issuewild isn't set at all, CAs fall back to checking the issue tag for wildcard requests too. Setting issuewild explicitly to a more restrictive list than issue — or even to "issuewild ;" (an empty value, explicitly denying all wildcard issuance) — gives domain owners fine-grained control specifically over wildcard certificates, which carry more risk if compromised since they cover every subdomain at once.

⚙️ How This Tool Queries CAA Data

🔒 How CAA Fits Into Certificate Issuance

When any publicly trusted CA receives a certificate request, it's required — under the CA/Browser Forum's Baseline Requirements, mandatory since September 2017 — to check the domain's CAA records immediately before issuance. If a CAA record exists and doesn't authorize that specific CA, issuance must be refused. If no CAA record exists at all, any trusted CA remains free to issue, since CAA is an opt-in restriction rather than a default-deny mechanism. This check happens at issuance time only — CAA has no bearing on certificates already issued before a restriction was added.

🌟 Wildcard Certificate Authorization

Wildcard certificates (covering *.example.com) carry meaningfully higher risk if compromised, since a single private key exposure affects every current and future subdomain simultaneously rather than one specific hostname. This is exactly why issuewild exists as a separate, independently configurable tag — an organization might reasonably trust several CAs for ordinary certificates while restricting wildcard issuance to a single, more tightly controlled CA relationship.

❓ What Happens With No CAA Record

A domain without any CAA record isn't insecure by default — it simply hasn't opted into this particular restriction, meaning any publicly trusted CA remains free to issue a certificate for it. This is worth understanding clearly: CAA absence is the historical default state every domain existed in before 2017, not a special vulnerability introduced by not configuring it.

🔒 CAA & DNSSEC

CAA records benefit meaningfully from DNSSEC, since without it, a network-level attacker capable of manipulating DNS responses could theoretically suppress or forge CAA records during the brief window a CA checks them, undermining the restriction's real-world security value. DNSSEC-signed CAA records give Certificate Authorities cryptographic assurance that what they're checking is genuine, closing this specific gap for any organization with signed DNS.

🏢 Enterprise & Multi-CA Strategy

Larger organizations frequently maintain relationships with more than one Certificate Authority deliberately, for redundancy against a single CA outage or unexpected distrust event, and CAA records let them formalize exactly which CAs are approved for use across their domain portfolio — turning an informal procurement policy into an enforced, DNS-level technical control that applies automatically to every issuance attempt, intentional or not.

☁️ Cloud, CDN & Hosting Examples

Many CDN and cloud platforms managing TLS certificates on a customer's behalf require the customer to add a specific CAA record authorizing that platform's chosen CA partner before automated certificate issuance or renewal can succeed — a common source of confusion when a customer has an existing, more restrictive CAA record from a previous setup that inadvertently blocks the new platform's certificate automation.

📊 Comparison Tables

issue vs. issuewild

Single CA vs. Multiple CA Authorization

🖥️ Automation & API Usage

Certificate automation tools (ACME clients like Certbot, and most cloud-managed TLS pipelines) increasingly validate CAA compatibility as part of pre-flight checks before attempting issuance, surfacing a clear error early rather than letting a CAA mismatch cause a confusing failure deep inside an automated renewal pipeline.

📋 Certificate Transparency & Compliance

CAA works alongside, not instead of, Certificate Transparency (CT) logs — CT provides after-the-fact public visibility into every certificate issued for a domain, while CAA works preventively at issuance time. Organizations with strict compliance requirements often use both together: CAA to restrict who can issue in the first place, and CT log monitoring to catch and respond quickly to any unauthorized issuance that somehow occurs despite CAA, whether from a CA error or an attack on the mechanism itself.

🔒 Security Considerations

CAA meaningfully reduces the practical attack surface for domain-validated certificate misissuance, whether from a compromised CA, a social-engineering attack against CA validation processes, or simple human error at a CA the domain owner never intended to use. It does not, however, protect against a compromise of a CA that is explicitly authorized — CAA restricts the field of trusted issuers, it doesn't add scrutiny to the ones you've actually authorized.

❌ Common Mistakes

✅ Best Practices

Add a CAA record for every domain and subdomain zone with independently issued certificates, explicitly authorizing only the CAs you actually use. Set issuewild independently and more restrictively wherever wildcard certificates aren't needed. Add an iodef tag pointing at a monitored security contact to catch unauthorized issuance attempts early. Enable DNSSEC on any zone where CAA enforcement matters seriously, closing the gap between publishing the restriction and a CA reliably seeing it unmodified.

📊 Pros & Cons

🔧 Troubleshooting

🎓 Expert Tips

🔗 More Ways to Investigate DNS Security

For general DNS records, use DNS Lookup. Verify an existing certificate directly with SSL Certificate Checker. Check mail authentication with SPF Lookup and DKIM Lookup, verify delegation with NS Lookup, and check zone administration with SOA Lookup.