What Is a CAA Record, and How Does It Control SSL Certificate Issuance?

There are dozens of publicly trusted certificate authorities, and by default any one of them can issue an SSL/TLS certificate for your domain as long as the requester passes domain validation. That's a large attack surface. If an attacker can briefly control your DNS, intercept validation traffic, or exploit a weak validation process at a single CA anywhere in the world, they could get a valid certificate for your site. A CAA record shrinks that surface down to the CAs you actually use.

This article explains what a CAA record is, how certificate authorities evaluate it, the syntax of each tag, how to write CAA records for common providers, and how to avoid the mistakes that block your own certificate renewals. If you're automating certificates with Let's Encrypt, it pairs well with the guide on how the DNS-01 challenge works.

What Is a CAA Record?

A CAA record (Certification Authority Authorization), defined in RFC 8659, is a DNS record that specifies which certificate authorities are allowed to issue certificates for a domain. Before issuing a certificate, a CA must look up the CAA records for the domain and refuse to issue if it isn't authorized.

CAA checking has been mandatory for all publicly trusted CAs since September 2017, under the CA/Browser Forum's Baseline Requirements. So while publishing CAA records is optional for you, honoring them is not optional for the CAs.

A simple CAA record looks like this:

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

This says: only Let's Encrypt may issue certificates for example.com and its subdomains.

What CAA Does and Doesn't Do

CAA is a narrow control, and it's worth being precise about it:

1. It restricts issuance by compliant CAs. A CA not listed in your record must refuse to issue.
2. It doesn't affect browsers. Browsers don't check CAA when connecting to your site. A certificate issued before you added CAA, or by a CA that ignored it, would still be trusted.
3. It doesn't revoke existing certificates. Adding a CAA record has no effect on certificates already issued.
4. It only matters at issuance and renewal time. That's when CAs check it.

Think of CAA as a policy for certificate authorities, not a security setting for visitors. It complements other measures like Certificate Transparency monitoring and DNSSEC, which protects the CAA lookup itself from being forged.

CAA Record Syntax

Each CAA record has three parts:

name  TTL  IN  CAA  flags  tag  "value"

Field	Example	Meaning
Flags	0	A number from 0 to 255. Only one bit is defined: 128 marks the record as critical. Use 0 in almost all cases.
Tag	issue	What kind of property this record sets.
Value	"letsencrypt.org"	The value for that property, in quotes.

The tags

Tag	Purpose
issue	Authorizes a CA to issue any certificate, including wildcards (unless issuewild is present).
issuewild	Authorizes a CA to issue wildcard certificates only. If present, it overrides issue for wildcard requests.
iodef	A URL where CAs can report issuance requests that violate your policy, such as mailto: or https:.
issuemail	Authorizes a CA to issue S/MIME email certificates (RFC 9495). Separate from TLS issuance.

The critical flag

Setting the flags field to 128 tells CAs: "if you don't understand this tag, you must not issue." It exists so future tags can be enforced safely. For issue, issuewild, and iodef, which every CA understands, leave the flag at 0. Setting it to 128 on an unfamiliar tag can block all issuance.

How CAs Evaluate CAA Records

When a CA receives a request for www.shop.example.com, it doesn't just check that exact name. It walks up the DNS tree until it finds CAA records:

1. Look up CAA for www.shop.example.com. If records exist, use them.
2. If not, look up shop.example.com.
3. If not, look up example.com.
4. If nothing is found at any level (excluding the TLD itself), issuance is unrestricted.

This means a single CAA record set at your root domain covers every subdomain, unless a subdomain publishes its own records — in which case the subdomain's records replace (not add to) the parent's.

CAs also follow CNAMEs. If www.shop.example.com is a CNAME to a hosting provider's hostname, the CA checks CAA at the CNAME target as well, according to the rules in RFC 8659. That's why some hosting platforms' CAA policies can affect your issuance.

Empty issue values

A value of ";" means "no CA is authorized":

example.com.  3600  IN  CAA  0 issue ";"

This blocks all certificate issuance for the domain. It's useful for domains that should never have certificates, like parked domains — but disastrous if added by mistake to a live site.

CAA Examples for Common Setups

One CA for everything

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

Only Let's Encrypt may issue, for any name under example.com, including wildcards. Policy violations are reported by email.

Multiple CAs

Many setups use more than one CA — for example, Let's Encrypt for most sites and a commercial CA for an EV or OV certificate, or a CDN that uses several CAs. Add one issue record per CA:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "digicert.com"
example.com.  3600  IN  CAA  0 issue "pki.goog"

Every listed CA is authorized. Any CA not in the list must refuse.

Different rules for wildcards

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "digicert.com"
example.com.  3600  IN  CAA  0 issuewild "digicert.com"

Both CAs can issue regular certificates, but only DigiCert can issue wildcard certificates. To forbid wildcards entirely, use 0 issuewild ";".

A subdomain with its own policy

example.com.       3600  IN  CAA  0 issue "letsencrypt.org"
legacy.example.com. 3600 IN  CAA  0 issue "sectigo.com"

Because legacy.example.com has its own CAA records, only Sectigo can issue for that subdomain — Let's Encrypt is not inherited.

Common CA identifiers

Each CA documents the domain name it recognizes in CAA records. Some widely used values:

CA	CAA value
Let's Encrypt	letsencrypt.org
Google Trust Services	pki.goog
DigiCert	digicert.com
Sectigo	sectigo.com
Amazon (AWS Certificate Manager)	amazon.com
GlobalSign	globalsign.com

Always confirm the current value in your CA's documentation — some CAs accept several identifiers, and brands change after acquisitions.

Restricting by Account and Validation Method

RFC 8657 added two parameters that make CAA much more precise, and Let's Encrypt supports both:

• accounturi — only allow issuance from a specific ACME account.
• validationmethods — only allow specific domain validation methods.

example.com.  3600  IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"

With this record, even someone who can pass an HTTP challenge on your server can't get a Let's Encrypt certificate, because only DNS-01 validation from your specific account is allowed. Your account URI is shown in your ACME client's account data — with certbot, it's stored in the account files under /etc/letsencrypt/accounts/.

This is one of the strongest protections available against unauthorized issuance, but it ties issuance to one account. If you lose that account or move to a new ACME client, update the record first.

How to Check CAA Records

With dig:

dig CAA example.com +short

This prints each record's flags, tag, and value, for example 0 issue "letsencrypt.org". If it returns nothing, check the parent domains too, since CAs walk up the tree:

for name in www.shop.example.com shop.example.com example.com; do
  echo "== $name"
  dig CAA "$name" +short
done

The first name in that list that returns records is the one whose policy applies.

From Python:

import dns.resolver

for rdata in dns.resolver.resolve("example.com", "CAA"):
    print(rdata.flags, rdata.tag.decode(), rdata.value.decode())

dnspython exposes the three CAA fields as attributes, with tag and value returned as bytes. It raises dns.resolver.NoAnswer if the name exists but has no CAA records.

How to Add a CAA Record

Most DNS dashboards provide a CAA form with fields for flags, tag, and value. Some only offer a text field where you type 0 issue "letsencrypt.org". If you can't find CAA support in your provider's interface, see how to access DNS settings — some older control panels don't support CAA at all, which is worth knowing before you choose a DNS host.

On AWS Route 53:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com",
        "Type": "CAA",
        "TTL": 3600,
        "ResourceRecords": [
          { "Value": "0 issue \"letsencrypt.org\"" },
          { "Value": "0 issue \"amazon.com\"" },
          { "Value": "0 iodef \"mailto:security@example.com\"" }
        ]
      }
    }]
  }'

All CAA values for a name go in a single record set, with the tag value in escaped quotes.

Before you add one: find every CA you use

The riskiest part of CAA is forgetting a CA. Check:

• Your web server or ACME client (certbot, Caddy, Traefik, cert-manager).
• Your CDN or reverse proxy — Cloudflare, for example, issues edge certificates through more than one CA and adds the CAA records it needs automatically when you use its certificates.
• Managed platforms that issue certificates for custom domains, such as Vercel or Netlify.
• Load balancer certificates from cloud providers.
• Any commercial certificates bought for specific services.

Certificate Transparency logs are the best inventory. Searching your domain on a CT log search tool like crt.sh shows every certificate issued for it, and which CA issued it.

Common Mistakes and Best Practices

1. Leaving out a CA you rely on. The next renewal fails with a CAA error. Audit CT logs before publishing.
2. Adding issue ";" by accident. This blocks all issuance. Double-check before saving.
3. Assuming subdomain records add to the root's. They replace them. If a subdomain needs Let's Encrypt plus another CA, list both on the subdomain.
4. Using the critical flag unnecessarily. Leave flags at 0 unless you know you need 128.
5. DNS servers that fail CAA lookups. If your authoritative servers return SERVFAIL or time out for CAA queries, CAs will refuse to issue. This was common with older DNS software and is a frequent cause of DNS errors during renewal.
6. Forgetting iodef. It's optional, but it gives you a chance to hear about suspicious requests.

---

CAA Record FAQ

Conclusion

A CAA record is a short, low-maintenance way to tell the entire certificate ecosystem which CAs you trust to issue for your domain. Because CAs are obligated to check it, a correct CAA policy turns "any of dozens of CAs could be tricked into issuing for my domain" into "only the one or two I use can." With RFC 8657's accounturi and validationmethods parameters, you can tighten that further to a single account and validation method.

The main risk is self-inflicted: leaving out a CA your CDN, hosting platform, or load balancer depends on. Inventory your certificates through Certificate Transparency logs first, publish CAA at the root domain, verify with dig CAA, and revisit it whenever you add a new service that issues certificates for you.

Here are some useful references for going deeper on CAA records:

1. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record — the current CAA specification.
2. RFC 8657: CAA Record Extensions for Account URI and ACME Method Binding — defines the accounturi and validationmethods parameters.
3. Let's Encrypt: Certificate Authority Authorization (CAA) — how Let's Encrypt evaluates CAA records.
4. Cloudflare Learning Center: What is a DNS CAA record? — an overview of CAA with examples.
5. crt.sh: Certificate Transparency search — look up every certificate issued for your domain before writing a CAA policy.