What Is a CAA Record (And Why It Can Silently Break SSL Renewal)

An SSL certificate renewal can fail for a reason that has nothing to do with your certificate, your DNS host, or your account with your certificate authority. It can fail because of a DNS record most people have never looked at, and never set, that quietly authorizes some certificate authorities and not others.

What a CAA record actually does

A CAA record, Certification Authority Authorization, is a DNS record that lists which certificate authorities are allowed to issue certificates for your domain. It looks like this:

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

Since 2017, checking CAA records before issuing a certificate hasn’t been optional for certificate authorities. It’s a mandatory requirement under the CA/Browser Forum’s Baseline Requirements, which every publicly trusted CA has to follow. If a CAA record exists and doesn’t name the CA attempting to issue, that CA must refuse.

The part that catches people out is the default. If a domain has no CAA record at all, any publicly trusted CA can issue a certificate for it. CAA is opt-in protection, not automatic. Most domains have never had one set, simply because almost nobody knows to look.

How a CAA record causes a silent renewal failure

The failure mode isn’t exotic. A domain sets a CAA record years ago, authorizing whichever CA was in use at the time. Later, the certificate setup changes: a migration to a new host, a CDN that manages certificates itself, a switch to a different automated issuance provider. The old CAA record never gets updated, because updating a DNS record isn’t usually part of anyone’s migration checklist.

The next renewal attempt from the new CA hits the CAA check and gets refused. If that renewal is automated, which most are, the failure often lands in a log nobody’s watching rather than an alert anyone sees. We’ve written before about how easy it is for certificate expiry to go unnoticed until a browser starts throwing warnings at visitors. A stale CAA record is one of the more avoidable ways to end up there, precisely because the record blocking the renewal has nothing to do with the certificate itself.

The issue, issuewild, and iodef tags

CAA records use three tags, and the interaction between two of them is where most confusion comes from.

issue authorizes a CA to issue standard certificates. If no issuewild record exists, this same authorization implicitly covers wildcard certificates too.
issuewild authorizes a CA specifically for wildcard certificates, and once it’s present, it fully overrides issue for wildcard requests. Setting issue alone does not restrict wildcards, it’s easy to assume it does and be wrong. Blocking wildcard issuance entirely requires an explicit issuewild ";" record, with a semicolon as the value, authorizing no CA at all for wildcards.
iodef doesn’t authorize anything. It specifies a URL or email address where a CA should report an issuance request that violated the policy, a notification channel for attempted mis-issuance, not an enforcement mechanism itself.

A more complete record set, using all three tags, looks like this:

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "digicert.com"
example.com. CAA 0 iodef "mailto:[email protected]"

That configuration allows Let’s Encrypt to issue standard certificates, restricts wildcard certificates to DigiCert specifically, and asks any CA that gets a blocked request to report it to the address given.

CAA lookups walk up the DNS tree, and can follow CNAMEs too

CAA checks aren’t limited to the exact name being requested. If there’s no CAA record at the exact domain, the check walks up to the parent domain, and keeps walking until it finds a record or runs out of parent zones. It’s the same tree-walk pattern we’ve covered before in the context of DMARC policy inheritance, applied here to certificate authorization instead.

It gets more specific for subdomains that are CNAMEs to a third-party service, a common setup with CDNs and managed hosts. In that case, the CAA check generally follows the CNAME to its target and evaluates CAA there instead of on your own zone. RFC 8659 simplified this from the more complex tree-climbing behavior of its predecessor, RFC 6844, and explicitly leaves the exact handling of CNAMEs and DNAMEs to each certificate authority’s own implementation rather than mandating one universal algorithm. In practice, that means a subdomain pointed at a third-party service can end up governed by that provider’s CAA setup rather than yours.

Does my domain need a CAA record if I only use one CA?

Yes. A CAA record isn’t just useful when juggling multiple providers. Without one, any publicly trusted CA can issue a certificate for your domain, which means a compromised or careless CA elsewhere on the internet could issue one for you without your knowledge. Naming your actual CA, or CAs, closes that door regardless of how many you use, and costs nothing but the DNS record itself.

A quick self-audit

Check whether your domain has a CAA record at all. Most don’t, by default rather than by choice.
If one exists, confirm it actually names every CA you currently use, including any CDN or host that issues and renews certificates on your behalf automatically. If a subdomain is a CNAME to a third-party service, check whose CAA record actually governs it, yours or theirs.
Check for an issuewild record separately if you use wildcard certificates. An issue-only record still permits wildcards from the same CAs, which may or may not be what you intended.
Add an iodef record if you want to hear about issuance attempts that get blocked, rather than finding out only when something you expected to renew doesn’t.

kant.au checks CAA records alongside certificate expiry for every domain you monitor, so a mismatch between what your CAA record allows and what’s actually trying to renew shows up before the certificate itself becomes the problem. Want to see what your domain’s CAA record actually says? Check it for free, or start a 14-day trial to monitor it alongside your certificates.

RFC 8659, DNS Certification Authority Authorization (CAA) Resource Record
RFC 6844, DNS Certification Authority Authorization (CAA) Resource Record (obsoleted by RFC 8659)