CAA Records Explained for Site Owners

CAA records tell certificate authorities which CAs may issue TLS certificates for your domain. Learn what issue and issuewild mean, why missing CAA matters, and how to review policy with Vulnify.

Back to Blog

TLS padlock linked to DNS CAA records showing issue and issuewild tags, with certificate authority icons behind a green approval gate

Most site owners think about TLS in terms of expiry dates and padlock icons. Certificate Authority Authorization (CAA) is the DNS control that answers a different question: which certificate authorities are allowed to issue certificates for your domain at all.

If you omit CAA, any publicly trusted CA can issue for your name unless other controls stop them. That gap matters when attackers request certificates for phishing subdomains or when a compromised CA workflow targets your brand.

What a CAA Record Does

CAA is a DNS record type published at your domain (or inherited from a parent zone). Certificate authorities check CAA before issuance. If policy forbids them, issuance should fail. The common tags are:

  • issue — which CA may issue standard certificates
  • issuewild — which CA may issue wildcard certificates
  • iodef — where to send violation reports (mailto or URL)

You might publish 0 issue "letsencrypt.org" if Let's Encrypt is your only issuer, plus a separate issuewild line if wildcards use a different CA. Exact syntax depends on your DNS host; the important part is expressing intent in DNS, not only in runbooks.

Why Missing CAA Is a Finding

Missing CAA is not an immediate breach. It is unnecessary exposure. Attackers who can complete domain validation at any CA have more options. Security teams also use CAA to prevent accidental issuance from shadow CAs when developers spin up certs outside central tooling.

CAA complements—not replaces—HSTS, certificate transparency monitoring, and strong access controls on DNS and CA accounts.

Inheritance and Effective Policy

CAA evaluation walks the DNS tree. Policy on a parent domain can apply to child names unless a closer record overrides it. That inheritance helps large organizations set baseline rules at the registrable domain, but it also surprises teams who add CAA at www while the apex stays empty.

The CAA record analyzer resolves effective policy, walks parent domains, and highlights issue, issuewild, and iodef entries. Use it after registrar migrations, when onboarding a new CA, or before enabling wildcard certificates.

How CAA Fits With Broader DNS Reviews

CAA appears alongside other TXT-based controls. Run the DNS record lookup for a full record inventory, then the dedicated CAA pass for issuance rules. Pair with TLS deep analysis on live sites to confirm certificates match the CAs you authorize.

Email and certificate teams share DNS ownership; coordinate changes so a CAA tighten does not block legitimate automation like ACME clients.

Rollout Tips

  1. List every CA and automation path that legitimately issues for your domain today.
  2. Publish CAA in staging DNS or a low-traffic zone first if your provider supports it.
  3. Add issue lines for each authorized CA; restrict issuewild if wildcards are rare.
  4. Add iodef if your security team will monitor violation reports.
  5. Verify with the CAA analyzer, then issue a test certificate from an authorized CA.

Our fix guide for missing CAA records includes copy-ready patterns and safe rollout notes.

Example CAA Records in Plain Language

A minimal policy for a site that only uses Let's Encrypt might publish two TXT records at the apex: 0 issue "letsencrypt.org" and 0 issuewild ";" to forbid wildcard issuance unless you add an explicit wildcard CA later. Multi-CA enterprises often authorize two issuers for redundancy: 0 issue "digicert.com" and 0 issue "letsencrypt.org" when different teams use different automation paths.

The leading 0 is a flags field defined by RFC 8659. Most deployments use zero. An iodef record such as 0 iodef "mailto:security@example.com" helps CA teams notify you when someone attempts unauthorized issuance—valuable for brands frequently targeted by phishing infrastructure.

Wildcard Certificates Need issuewild

Teams sometimes publish issue rules for the primary CA but forget issuewild. An attacker who can pass domain validation for a wildcard at an unauthorized CA could still obtain *.example.com if issuewild is absent or too permissive. If you never use wildcards, an explicit deny-style issuewild line documents that decision in DNS rather than relying on process alone.

When CAA Blocks a Legitimate Renewal

Post-incident stories often involve a new CA after a migration while old CAA still references the previous vendor. Symptoms include ACME failures with obscure CA error text and manual issuance tickets rejected by the CA's compliance team. Before cutover day, update CAA in the same change window as MX or CDN moves, then verify with the CAA analyzer and issue a test certificate from the new pipeline.

CAA and Multi-Brand Portfolios

Holding companies with many apex domains sometimes centralize CAA at the registrar DNS template level. That helps consistency but breaks when one brand legitimately uses a different CA. Tag each domain in your asset inventory with authorized issuers before applying blanket templates.

Certificate Transparency as a Companion Control

CAA limits who should issue; certificate transparency logs show what actually issued. Security teams monitoring CT feeds catch unauthorized certs even when CAA was missing or bypassed. Pair CAA audits with periodic CT review for brand domains and high-value subdomains used for customer login.

Staging vs Production CAA Changes

Test CAA tightening in a staging zone or low-traffic hostname before apex changes. Some ACME clients cache failure states aggressively—verify renewals after TTL propagation completes rather than assuming instant success.

Who Owns CAA in Your Organization

Certificate, DNS, and platform teams all touch issuance. Put CAA changes in the same change ticket as cert renewals or CA migrations. When ownership is unclear, CAA stays empty by default—that is the scenario this guide helps you close.

Next Steps

Audit effective CAA, align it with your real issuance pipeline, and schedule rechecks after infrastructure changes. For transport issues on live sites, continue with the SSL certificate checker and vulnerability scanning best practices as part of a broader launch or renewal cycle.

Frequently Asked Questions

Do I need CAA if I only use one certificate provider?

Yes, if you want DNS to enforce that policy. CAA tells all public CAs which issuers are allowed. Without it, any CA could theoretically issue after passing domain validation.

What is the difference between issue and issuewild?

The issue tag controls standard hostname certificates. issuewild controls wildcard certificates (*.example.com). Restrict both if wildcards are rare or use a different CA.

Can CAA block Let's Encrypt renewals?

Only if your CAA policy does not authorize the CA your ACME client uses. Always test renewals in staging after publishing or tightening CAA records.

Does CAA apply to subdomains automatically?

CAA is evaluated up the DNS tree. Parent-domain policy can apply to subdomains unless a closer record overrides it. Use the CAA analyzer to see effective policy per name.

Does CAA replace certificate transparency monitoring?

No. CAA restricts who may issue; CT logs help you detect certificates that were issued anyway. Use both for defense in depth on high-value domains.

Where do I publish CAA records?

Publish at the apex of the zone you want to protect, typically the registrable domain. Use the CAA analyzer to confirm effective policy for www and other delegated subdomains before relying on inheritance.

Is missing CAA a critical vulnerability?

It is a hardening gap, not an active breach. Prioritize missing CAA after critical injection or exposure findings, but do not ignore it on brands frequently targeted by phishing infrastructure.

Related Guides