CAA Records for Let's Encrypt: What They Do and How to Configure Them

Overview

If you manage domains, DNS, or SSL for production websites, a CAA record is worth understanding even if your current certificate renewals are working. CAA stands for Certification Authority Authorization. It is a DNS record type that tells certificate authorities which issuers are allowed to create certificates for a domain.

In plain terms, a CAA record works like a permission list. When a CA supports CAA checking, it looks up your domain’s DNS before issuing a certificate. If your DNS says only specific authorities are allowed, a different CA should not issue one. That makes CAA a useful extra layer of control, especially for teams managing many domains, subdomains, environments, and renewal workflows.

For Let’s Encrypt users, the practical question is simple: if you want Let’s Encrypt to issue or renew certificates for your domain, your CAA policy must allow it. If your CAA policy excludes it, issuance can fail even when your A, AAAA, CNAME, HTTP challenge, or DNS challenge configuration is otherwise correct.

CAA is not a replacement for domain validation, secure DNS access, or good server hygiene. It does not stop all certificate-related mistakes. But it does reduce the chance of an unexpected CA being able to issue for your domain if someone tries to obtain a certificate through the wrong provider or an old automation path.

At a high level, a CAA record has three parts:

• Flags: usually 0 in common setups
• Tag: commonly issue, issuewild, or iodef
• Value: the CA you are authorizing, such as Let’s Encrypt

The most common tags are:

• issue — authorizes a CA to issue standard certificates
• issuewild — authorizes a CA to issue wildcard certificates
• iodef — provides a contact method for reports related to certificate policy issues

A basic example for allowing Let’s Encrypt may look like this:

example.com.  CAA 0 issue "letsencrypt.org"

If you also use wildcard certificates, you may need an explicit wildcard authorization as well:

example.com.  CAA 0 issuewild "letsencrypt.org"

DNS control panels present this differently. Some ask for Name, Flag, Tag, and Value. Others flatten it into one line. The underlying concept is the same: you are publishing a DNS policy that authorizes issuance.

A few practical points matter here:

• CAA records can be set at the root domain and inherited by subdomains unless overridden.
• If no CAA record exists, issuance is generally allowed unless another policy blocks it.
• If a CAA record exists, it must explicitly permit the CA you intend to use.
• Misconfigurations often appear only during renewal or migration, which is why CAA belongs in your DNS maintenance checklist.

If you are moving a site or changing certificate tooling, it helps to review your DNS policy at the same time. A migration that preserves A records but forgets CAA can lead to avoidable renewal failures. For related planning, see How to Migrate a Website to a New Host Without Breaking SSL or DNS.

When you add or edit a CAA record, keep the policy as narrow as your real environment allows. If Let’s Encrypt is your only CA, authorize Let’s Encrypt. If you intentionally use more than one CA, document why and list only those issuers you actively rely on. The goal is clarity, not complexity.

Maintenance cycle

The most useful way to think about CAA is not as a one-time DNS task but as a recurring review item. The record itself is small, but the environment around it changes: hosting providers change, automation changes, teams change, and renewal methods change.

A practical maintenance cycle for CAA records looks like this:

Monthly: lightweight verification

Once a month, or at the same cadence as your certificate monitoring review, confirm these basics:

• Your domain still resolves with the intended CAA values.
• Your active certificate renewal path still uses an authorized CA.
• No control panel or DNS provider migration has silently altered the record.

This does not need to be a long audit. For many teams, a quick DNS lookup and comparison against documented policy is enough.

Quarterly: policy review

Every quarter, review whether your current CAA policy still matches operational reality:

• Are you still using Let’s Encrypt for all covered certificates?
• Have you introduced a CDN, managed platform, or proxy service that handles certificates on your behalf?
• Are any old issuers still authorized even though they are no longer needed?
• Do wildcard and non-wildcard use cases still match your issue and issuewild settings?

This is also the right time to check whether your subdomains inherit the right policy or need their own records.

During every migration or DNS change

CAA records should be reviewed whenever you:

• move DNS to a new provider
• change registrars and re-create zones
• switch hosting platforms
• introduce a reverse proxy or CDN
• change ACME client tooling
• start using wildcard certificates

Because CAA is easy to overlook, it is a common source of “everything looks right except issuance fails” problems. Include it in your website migration checklist, not just your SSL checklist.

At renewal testing time

If you are serious about reliable HTTPS, do not wait for the real expiry window to learn whether CAA is correct. Test renewal behavior in advance as part of your normal certificate maintenance process. If you rely on Let’s Encrypt automation, pair your CAA review with your renewal verification. A useful companion guide is How to Renew Let’s Encrypt Certificates Automatically and Verify It Actually Works.

Document the policy

Many CAA problems are not technical so much as organizational. One admin adds a restrictive record for a good reason, then months later another admin changes certificate tooling and has no idea why issuance is failing. To avoid that, document:

• which CA or CAs are authorized
• why they are authorized
• which zones or subdomains inherit the policy
• who owns changes to DNS and certificate automation
• when the policy was last reviewed

A short note in your infrastructure repository or operations handbook is enough. The point is to make the record understandable to the next person who touches it.

Signals that require updates

You should revisit your CAA records any time there is evidence that your DNS policy and certificate workflow may have drifted apart. Some signals are obvious, such as a failed issuance attempt. Others are quieter and easier to miss.

The clearest signs that your CAA configuration needs attention include the following.

Certificate issuance or renewal suddenly fails

If Let’s Encrypt worked before but now fails without an obvious HTTP or DNS validation problem, inspect CAA early in the troubleshooting process. CAA-related issuance failures are especially common after DNS migrations, template-based zone imports, or security cleanups where old records were deleted and re-added selectively.

If your ACME client reports an authorization or policy-related error, compare the exact domain being requested with the exact scope of your CAA records. For deeper error interpretation, see Let’s Encrypt Error Codes Guide: What Common ACME Messages Really Mean.

You begin using wildcard certificates

Wildcard certificates often bring a separate CAA consideration. A policy that works for standard certificates may not be sufficient for wildcard issuance if you have not explicitly considered issuewild. Review your setup before rolling wildcard automation into production.

You add a CDN, proxy, or managed platform

Some platforms handle certificates for you. If that changes who requests certificates for your domain, your CAA policy may need revision. Even if your origin server still uses Let’s Encrypt, a fronting service might require its own authorized issuance path depending on your architecture.

You decommission an old CA or provider

Old authorizations tend to remain in DNS longer than necessary. If you no longer use another CA, remove it from CAA unless there is a documented reason to keep it. Narrower authorization is easier to audit and reduces ambiguity during incidents.

Your team changes DNS providers or zone management workflows

Not all DNS interfaces treat uncommon record types the same way. Whenever you switch control panels, export and import zones, or move to DNS-as-code, confirm that CAA records survived intact and retained the same meaning.

You notice inconsistent behavior across subdomains

One service renews fine while another fails. That often points to inheritance, delegation, or subdomain-specific records. The parent zone may authorize Let’s Encrypt while a child label overrides the policy, or a delegated subdomain may be managed elsewhere with different CAA records.

Search intent or platform guidance shifts

This article’s topic is also worth revisiting when operational practices change. For example, teams may move from server-based certificate handling to platform-managed TLS, or they may consolidate tooling around a different ACME client. Those changes do not make CAA less useful, but they can change how specific your policy should be and where you apply it.

Common issues

Most CAA mistakes are small configuration errors with large operational consequences. The good news is that they are usually easy to fix once you know where to look.

Problem: Let’s Encrypt is not authorized

This is the most direct failure mode. A CAA record exists, but it authorizes a different CA or no CA at all for the certificate type you need.

What to check:

• Does the zone include issue "letsencrypt.org" for standard certificates?
• If you use wildcard certificates, does it also include an appropriate issuewild value?
• Are you editing the correct zone and label?

Typical fix: add or correct the authorization for Let’s Encrypt, then allow time for DNS changes to propagate according to your TTL and provider behavior.

Problem: The record was added in the wrong place

Some DNS panels make it easy to confuse the root domain, a subdomain label, and a fully qualified name. If you add the record under the wrong hostname, the CA may not see the policy you intended.

What to check:

• Whether the record is attached to @, the apex domain, or a specific subdomain
• Whether the panel automatically appends the zone name
• Whether a delegated subdomain is managed in another DNS zone entirely

Typical fix: re-create the record at the correct label and remove the misplaced entry if it adds confusion.

Problem: Standard and wildcard policy do not match your use case

Teams often authorize a CA for normal certificates but forget the wildcard side of the policy. Later, an automation change requests *.example.com and fails.

What to check:

• Whether your tooling requests wildcard names
• Whether your zone has both issue and issuewild where needed
• Whether the wildcard is truly necessary or a standard certificate set would be simpler

Typical fix: align CAA policy with your actual issuance pattern.

Problem: DNS changes have not propagated yet

CAA updates are still DNS updates. If you modify a record and immediately retry issuance, you may be testing before the new policy is visible from the CA’s perspective.

What to check:

• Record TTL
• Whether your authoritative nameservers return the new value
• Whether caches still show the old state

Typical fix: wait for propagation, then test again. If you need a broader DNS troubleshooting workflow, a general dns propagation checker guide can help confirm whether authoritative and recursive answers agree.

Problem: A DNS provider import/export dropped CAA records

Because CAA is less common than A, MX, or TXT, it sometimes gets missed in manual migrations.

What to check:

• Old and new zone files side by side
• Provider support for CAA record type
• Any DNS templates that omit nonstandard records

Typical fix: restore the missing CAA entries and update your migration checklist so the record is verified next time.

Problem: The website is secure, but application behavior is still broken

CAA affects certificate issuance, not how your application loads resources or enforces HTTPS. It is possible to fix issuance and still have mixed content, redirect loops, or incomplete HTTPS hardening.

After CAA and issuance are working, continue with the rest of your HTTPS checks. Related reading: How to Force HTTPS Safely: Redirect Rules for Nginx, Apache, and Cloud Platforms and Mixed Content Errors After Installing Let’s Encrypt: Causes and Fixes.

Problem: You are using the right CA but the wrong assumptions

CAA can only authorize issuance. It does not guarantee that your ACME client is installed correctly, that your web server serves the challenge path, or that your DNS challenge automation works. If CAA is correct and issuance still fails, move on to validation path troubleshooting, server logs, and ACME client behavior. If you are choosing or changing tooling, Certbot Alternatives for 2026: When to Use acme.sh, Dehydrated, Win-ACME, or Caddy may help frame the operational trade-offs.

When to revisit

The simplest rule is this: revisit your CAA records whenever the answer to “who is allowed to issue certificates for this domain?” might have changed. In practice, that means you should review CAA on a schedule and during specific events.

Use this action-oriented checklist:

• Review every quarter to confirm the authorized CA list still matches reality.
• Review before certificate renewal windows if you have changed DNS, hosting, or ACME tooling since the last successful issuance.
• Review during any DNS provider or registrar migration so CAA is re-created intentionally rather than by accident.
• Review when adding wildcard certificates to confirm issuewild policy is correct.
• Review when adding a CDN, proxy, or managed TLS platform that may request certificates differently from your origin server.
• Review after security cleanups where old DNS records are removed or standardized.
• Review after incidents involving failed issuance, unexpected certificate requests, or unclear domain ownership boundaries.

If you want a durable baseline, keep a short domain security worksheet for each important zone:

1. List the DNS provider and where the authoritative zone is managed.
2. List the approved certificate authority or authorities.
3. Record whether wildcard certificates are used.
4. Record the ACME client or platform handling issuance.
5. Store the expected CAA records in documentation or infrastructure code.
6. Set a recurring reminder to verify DNS output and recent renewals.

That small amount of documentation pays off because CAA issues rarely happen during calm periods. They tend to appear during host changes, urgent renewals, or inherited environment cleanup. A documented policy turns a confusing DNS mystery into a straightforward verification task.

For ongoing operational health, it also helps to monitor expiry and renewal outcomes rather than treating certificate issuance as a background detail. See Let’s Encrypt Expiry Monitoring: Best Tools, Alerts, and Dashboard Options for a practical companion process.

The bottom line is that CAA records are small but important. If you use Let’s Encrypt, authorize it clearly. If you no longer use another CA, remove it. If you change platforms, recheck the policy before renewal day. That discipline keeps your DNS security posture tidy and reduces one more avoidable cause of SSL disruption.