CAA record

A CAA record is a published instruction to every public certificate authority: these are the only CAs allowed to issue certificates for this domain. A CA that would otherwise issue checks CAA first; if the requesting CA is not authorised, issuance fails.

Type code 257, defined in RFC 8659 (which obsoletes RFC 6844). Publicly trusted CAs are required to check CAA under the CA/Browser Forum Baseline Requirements, in effect since September 2017.

What it is

Three fields: a flags byte, a property tag, and a value. The common case looks like this:

example.com.  3600  IN  CAA  0  issue  "letsencrypt.org"
|              |    |   |    |  |      |
|              |    |   |    |  |      └─ the value (CA identifier)
|              |    |   |    |  └─ the tag (issue, issuewild, iodef)
|              |    |   |    └─ flags byte (usually 0)
|              |    |   └─ record type (CAA = 257)
|              |    └─ DNS class
|              └─ TTL
└─ owner name

The tags

Tag	Meaning	Example
`issue`	Who may issue standard certs for this domain (and subdomains).	`0 issue "letsencrypt.org"`
`issuewild`	Who may issue wildcard certs. Falls back to `issue` if not set.	`0 issuewild "letsencrypt.org"`
`iodef`	Where to report policy violations. Mostly advisory; few CAs actually use it.	`0 iodef "mailto:security@example.com"`

A special empty value ";" means no CA is allowed to issue. Useful for a domain that should never have a public cert:

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

The tree walk

When a CA is asked to issue a cert for api.example.com, it does not just look for a CAA record at that exact name. It walks up the DNS tree until it finds a CAA RRset.

Tree walk for CAACA issuing cert for api.example.com

api.example.comno CAA
no CAA here, walk up
example.com0 issue "letsencrypt.org"
found. stop the walk.
comno CAA
would have been next; never reached
. (root)no CAA
would have been next; never reached

The CA walks from the leaf upward. It stops at the first zone that publishes a CAA RRset. Only that CAA decides. Parents above it are never consulted.

This means a single CAA at your zone apex covers every subdomain under it. You rarely need CAA on individual subdomains unless you want to override the parent for a specific host.

Issuer identifiers

The value inside an issue or issuewild record is the CA's published identifier. Each CA declares theirs in its Certification Practice Statement.

Issuer identifiersvalue to put in issue / issuewild

letsencrypt.orgLet's EncryptISRG; the default for most new sites

digicert.comDigiCertenterprise; also covers GeoTrust, Thawte, RapidSSL

sectigo.comSectigoformerly Comodo

pki.googGoogle Trust Servicesdefault on Google Cloud, YouTube, etc.

amazon.com, amazontrust.com, awstrust.com, amazonaws.comAmazonACM-managed certs on AWS

globalsign.comGlobalSignenterprise and IoT

buypass.comBuypassACME-capable, Nordic-focused

entrust.netEntrustenterprise

If you renew your certs through more than one CA (primary + backup, for example), list each of them as a separate CAA record. The issue tag is additive: every listed CA is authorised.

Tightening with RFC 8657

RFC 8657 adds two parameters for tighter binding:

accounturi: restrict issuance to a specific ACME account. Even if your CAA authorises Let's Encrypt, only certs requested from your registered ACME account at that URI are allowed.
validationmethods: restrict which domain-control validation methods may be used. dns-01, http-01, or tls-alpn-01.

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

This is the strongest practical CAA pattern. An attacker who steals control of your DNS cannot just request a new cert: they would also need your ACME account key. Worth the setup time on high-value domains.

What CAA is not

Not a technical block. Nothing stops an untrusted CA from issuing a rogue cert. CAA is an instruction; enforcement comes from browser root-program audits. A CA caught issuing against CAA risks distrust.
Not certificate pinning. CAA tells CAs what is allowed; it does not tell browsers what to expect.
Not a replacement for monitoring. Pair CAA with Certificate Transparency monitoring: if a rogue cert does get issued, CT logs will catch it.

Common mistakes

CAA excludes the CA you actually renew with

Publishing issue "digicert.com" on a domain that uses Let's Encrypt. Next renewal fails with no clear error. Audit before you publish.

missing issuewild for wildcard certs

If you rely on wildcards, some CAs require an explicit issuewild. issue alone does not cover wildcard issuance when both tags are present.

wrong issuer identifier string

Each CA has one specific identifier. Putting letsencrypt.com (wrong TLD) silently locks Let's Encrypt out. Check the CA's documentation, not your memory.

CAA on apex, CNAME chain at subdomain

Most CAs follow CNAMEs during the tree walk, some do not. If the subdomain is a CNAME to a third-party origin and you want CAA to apply, put it at the apex.

no CAA at all

Default behaviour: any publicly trusted CA may issue. Not wrong, but a missed defence-in-depth opportunity. Publishing CAA takes a minute and costs nothing.

Check whether your domain publishes CAA, whether it matches the CA that actually holds your live cert, and whether it uses the tighter RFC 8657 parameters: scan your domain.