How to Set a CAA Record (and Why Almost Nobody Has One)

Without a CAA record, any publicly-trusted certificate authority in the world may issue a certificate for your domain to anyone who passes its validation checks. There are dozens of them. Your security therefore depends on the weakest validation process among all of them, which is not a comfortable place to be.

A CAA record fixes that by naming the authorities you actually use. It's a single DNS record, it takes about five minutes, and most domains still don't have one.

What CAA does

CAA — Certification Authority Authorization — is a DNS record listing the certificate authorities permitted to issue for your domain. Since 2017, CAs have been required to check it before issuing, and to refuse if they're not on the list.

That turns certificate issuance from "any CA will do it" into "only these CAs will do it". If an attacker tries to obtain a certificate for your domain through a CA you don't use, a compliant CA declines.

What to publish

A CAA record has three parts: a flag (almost always 0), a tag, and a value. The tags you'll use:

Tag	Purpose
issue	CAs allowed to issue normal certificates
issuewild	CAs allowed to issue wildcard certificates
iodef	Where to report policy violations

A typical record for a domain using Let's Encrypt:

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

Using more than one authority — say Let's Encrypt plus a commercial CA — means one issue line each:

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

To allow normal certificates but block wildcards entirely:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild ";"

A semicolon as the value means nobody. That's a genuinely useful tightening, because a wildcard certificate is the broadest thing an attacker could obtain, and most organisations don't need one.

To be told when someone tries and fails:

example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Reporting is best-effort — not all CAs send these — so treat it as a bonus rather than a monitoring strategy.

Getting the CA identifiers right

The value must be the CA's documented identifier, not its brand name or website. letsencrypt.org is correct; Let's Encrypt is not, and a wrong value fails in the worst possible way — issuance blocked for a CA you meant to allow.

Every CA publishes its identifier in its documentation. Look it up rather than guessing, and check it for each authority you use.

The trap: your CDN or host may issue on your behalf

This is where CAA goes wrong in practice. Set a record naming only Let's Encrypt, and then your CDN tries to provision a certificate through its own CA, and issuance quietly fails. Suddenly a service that renewed itself for two years stops.

Before publishing, list everything that issues certificates for you:

• Your CDN or reverse proxy
• Your managed hosting platform
• Any SaaS serving a custom domain for you
• Your own automated certificate tooling

Each of them needs its CA in the record. If you're unsure what's currently issuing for you, look at what's already been issued: our subdomain finder reads Certificate Transparency logs, which record the issuing authority for every certificate — an accurate inventory of the CAs actually in use across your domain and its subdomains.

Subdomains inherit — mostly

CAA checking walks up the tree. A CA asked to issue for api.example.com checks api.example.com first, and if there's no record there, falls back to example.com.

So a record on the apex covers everything beneath it, which is usually what you want. You can override for a specific subdomain by publishing a record on it directly — useful when one hostname is served by a platform with a different CA.

Two honest limits

CAA is worth setting, but it is not a lock, and it's better to be clear about that:

It constrains authorities, not attackers. CAA lives in your DNS. Anyone who controls your DNS can change it as easily as any other record — and someone who controls your DNS can pass domain validation anyway. CAA defends against a CA being tricked; it does not defend against your DNS being compromised.

It only binds CAs that follow the rules. Compliance is a requirement of the CA/Browser Forum baseline requirements, not a technical enforcement. A CA that ignores CAA can still issue; the record makes that a documented violation rather than a prevented one.

So CAA narrows the attack surface substantially and costs almost nothing — that's the case for it. It doesn't remove the need to know what's being issued.

Checking what you have

Our free WHOIS & DNS lookup shows a domain's CAA records alongside the rest of its DNS. Try it on your own domain — the likely answer is that there aren't any, which is the normal state of affairs and the reason this is worth five minutes.

Then, because CAA restricts issuance but doesn't report it, the complement is watching what actually gets issued. DomainChest monitors Certificate Transparency logs for your domains and alerts on newly-logged certificates, naming the hostnames and the issuing authority — see how to tell if someone issued a certificate for your domain.