CAA Records: Controlling Which Certificate Authorities Can Issue for Your Domain

By default, any publicly trusted certificate authority can issue a TLS certificate for your domain, provided whoever requests it can complete that CA's domain validation. That's a wider set of trust than most domain owners realize exists. A CAA record narrows it: it names the specific CAs allowed to issue for your domain, and every other CA is expected to refuse.

What a CAA record does

CAA (Certification Authority Authorization) is a DNS record type CAs are required to check before issuing a certificate. If your domain publishes a CAA record, a CA not named in it is supposed to decline the request, even if the requester could otherwise pass domain validation.

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

This example authorizes Let's Encrypt and Google Trust Services to issue standard certificates for example.com, and asks any CA that receives a request outside that list to report it to the listed address instead of silently refusing.

Reading the tags

issue — authorizes a CA to issue standard (non-wildcard) certificates for this exact hostname. The value is the CA's domain, not a company name; check the CA's own documentation for the exact string they expect (Let's Encrypt uses letsencrypt.org, DigiCert uses digicert.com, and so on).

issuewild — same as issue, but scoped to wildcard certificates (*.example.com) specifically. If issuewild is absent but issue is present, most CAs treat the issue tags as covering wildcards too. An explicit issuewild lets you authorize a different (often narrower) set of CAs for wildcards than for standard certificates, or block wildcard issuance entirely with issuewild ";".

iodef — an optional reporting address (mailto or https URL) that compliant CAs should notify if they receive an issuance request they're declining because of your policy. This turns a blocked issuance attempt into a signal you actually see, rather than a silent refusal you'd never know happened.

The leading 0 is a flags field, effectively unused in practice; it's almost always 0.

A CAA record with no issue value at all (0 issue ";") is valid syntax and means exactly what it looks like: no CA is authorized to issue a standard certificate for this hostname.

Why this exists

Certificate issuance for a domain is normally a race between whoever controls DNS or hosting for it and whichever CA that person or system happens to ask. Domain validation confirms the requester controls the domain (via a DNS TXT record, an HTTP file, or an email to a listed contact), but it doesn't ask whether the domain owner specifically trusts that CA over any other.

CAA closes that gap without requiring anything from the certificate requester. It's enforced entirely on the CA's side, as a mandatory check before issuance, which is what makes it effective against a scenario where someone other than the intended owner manages to pass domain validation, whether through a misconfiguration, a stale delegation, or a compromised account with a different CA than the one the domain normally uses.

Where this matters in practice

Standardizing on one CA. If your organization only ever issues certificates through a specific CA (say, as part of an automated ACME pipeline with Let's Encrypt), a CAA record makes that the enforced policy rather than just the convention everyone happens to follow.

Limiting exposure after a DNS incident. An unauthorized NS record change is dangerous partly because it can let an attacker pass a DNS-01 domain validation challenge and get a certificate issued for your domain. CAA doesn't prevent the NS hijack itself, but if the attacker's CA of choice isn't in your CAA record, that specific path to a fraudulent certificate is closed, even during the incident.

Getting notified of issuance attempts you didn't make. With iodef configured, an issuance request from a CA outside your allow-list generates a report, which can be the first sign that something's requesting certificates for your domain that shouldn't be.

Checking your CAA records

dig CAA example.com

No response means no CAA record exists, which is the default, permissive state: any publicly trusted CA can issue for the domain. This is fine for most domains, but if you've never deliberately decided this, it's worth knowing that's the current state rather than assuming otherwise.

To check whether a certificate was actually issued for your domain, and by whom, crt.sh searches Certificate Transparency logs, which every publicly trusted certificate is required to be recorded in. This is a useful complement to CAA: CAA controls who's allowed to issue, and Certificate Transparency logs let you audit who actually has.

A narrow record with a specific job

CAA doesn't replace TLS configuration, doesn't affect certificate renewal for CAs you've already authorized, and doesn't do anything for private/internal CAs that aren't part of the public trust model. What it does is close off one specific path: it stops a CA you haven't authorized from being able to issue a valid certificate for your domain at all, regardless of how they'd otherwise validate the request.

How DNS monitoring fits in

Because CAA records are set once and rarely touched afterward, an unexpected change is a meaningful signal on its own: either someone deliberately changed which CAs are trusted for the domain, or a record was removed, reopening the default permissive state. Either way, it's not something that should happen without someone on your team knowing about it.

OneDollarDNS monitors CAA records alongside every other record type on your domain, so a change to which certificate authorities are authorized shows up as an alert rather than something you'd only discover while investigating a certificate you didn't expect.