CAA Records: Controlling Who Can Issue Your SSL Certificates

A CAA record (Certification Authority Authorization), defined in RFC 8659, declares in DNS which certificate authorities are permitted to issue TLS/SSL certificates for your domain. Each record names a CA you authorize; a CA that isn't listed is, by policy, not allowed to issue.

It's worth being precise about the boundary of what CAA controls. A CAA record governs certificate issuance — the moment a CA decides whether to hand out a certificate. It says nothing about your addresses, your mail routing, or anything a visitor's browser sees. Think of it as a published instruction to the world's CAs: "these are the only authorities allowed to certify this name."

The trust model behind HTTPS has a structural weakness: any public CA can, in principle, issue a certificate for any domain. A browser trusts dozens of CAs, and it will accept a valid certificate for example.com from any of them. So if a single CA is tricked, compromised, or simply makes a mistake and issues a certificate for your domain to someone else, that attacker can impersonate your site with a certificate browsers fully trust.

CAA records are a defense-in-depth answer to exactly that risk — certificate mis-issuance. By publishing the short list of CAs you actually use, you instruct every other CA to refuse. A CA that's been socially engineered into issuing for your name is supposed to consult your CAA record, see it isn't on the list, and decline. It narrows the attack surface from "every CA in the world" down to "the handful you chose."

CAA only works because checking it isn't optional. Under the CA/Browser Forum Baseline Requirements, every publicly trusted CA must query your CAA records and honor them before issuing a certificate. A CA that ignores CAA and issues anyway is violating the rules that keep it in browsers' trust stores.

Two consequences follow from this. First, CAA is meaningful precisely because it's enforced by the CAs themselves, not by your DNS host or browsers. Second, the check happens at issuance time only — it constrains the act of getting a certificate, which is why CAA is a quiet but real security control rather than something users ever interact with.

A CAA record has three parts: a numeric flags field, a tag, and a value. It reads like this:

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

• Flags — usually 0. The only defined flag is "issuer critical" (128), which tells a CA it must reject the request if it doesn't understand the tag. Most records use 0.
• Tag — one of the three standard property tags below: issue, issuewild, or iodef.
• Value — a quoted string whose meaning depends on the tag: a CA's domain (such as letsencrypt.org) for issue/issuewild, or a contact URL for iodef.

Tag	What it controls
issue	Which CA may issue standard (non-wildcard) certificates for the domain. The value is the CA's domain, e.g. letsencrypt.org.
issuewild	Which CA may issue wildcard certificates (e.g. *.example.com). If present, it governs wildcards specifically and overrides issue for them.
iodef	Where a CA should report a request that violates your policy. The value is a mailto: or https: URL, e.g. mailto:security@example.com.

Here's a complete, realistic policy: allow exactly one CA to issue any certificate (standard or wildcard), and give CAs an address to report anything that doesn't fit:

• example.com. CAA 0 issue "letsencrypt.org"
• example.com. CAA 0 issuewild "letsencrypt.org"
• example.com. CAA 0 iodef "mailto:security@example.com"

Read together, these say: only letsencrypt.org may issue standard certificates for example.com, only letsencrypt.org may issue wildcard certificates, and if any CA receives a request it can't honor under this policy, it should report it to security@example.com. Every other CA in the world is, by this record, instructed to refuse.

You can list more than one authorized CA by adding additional issue records — one per CA you actually use. A CA is permitted to issue if it matches any of your issue entries (or issuewild entries, for wildcards).

Two special cases are easy to get wrong and important to understand.

Forbid everything. A value of a single semicolon means "no CA may issue." The record 0 issue ";" tells every certificate authority to refuse issuance for the domain entirely — useful for a domain that should never have a certificate, such as a parked or internal-only name.

No record means anyone may issue. If a domain has no CAA record at all, the default is fully permissive: any compliant public CA may issue a certificate for it. This is the original, pre-CAA behavior of the web. So the absence of a CAA record is not a restriction — it's the open default. Adding records is how you opt in to a restriction; removing them all returns you to "anyone may issue."

CAA isn't strictly checked at the exact name being certified. When a CA evaluates a request, it looks for CAA records starting at the relevant name and, if it finds none there, walks up the domain tree toward the apex, using the first set of CAA records it encounters.

The practical upshot: a CAA record at example.com covers subdomains like www.example.com and shop.example.com unless a subdomain publishes its own CAA records, which then take precedence for that branch. This makes an apex-level policy a sensible default for a whole domain, while still letting you set a tighter or looser policy on a specific subdomain when you need to.

CAA's failure mode is silent: a misconfigured record doesn't break your site for visitors — it breaks the next certificate renewal, weeks or months later, when an authorized CA discovers it's no longer on the list and refuses. Watch for these:

• List every CA you actually use. If you authorize one CA but your certificates are issued by another, the next issuance fails. Add an issue entry for each CA in play.
• Account for CAs your platform uses on your behalf. Hosting providers, CDNs, load balancers, and managed platforms often obtain certificates for you from a CA you never picked directly. If you publish a CAA record, that CA must be listed too, or your provider's automatic renewals will start failing.
• Don't forget wildcards. If you use wildcard certificates and have published an issuewild record (or rely on issue alone), make sure the CA issuing your wildcards is authorized for wildcards specifically.
• Mind the semicolon. An accidental issue ";" forbids all issuance — exactly the kind of typo that passes review and surfaces only at renewal.

The safe habit is to enumerate every CA touching your domain — including the ones your CDN or host uses for you — before you publish, and to re-check CAA whenever you change providers.

CAA is narrow on purpose. It's checked at issuance time and nowhere else: it does not revoke or affect already-issued certificates, and it has no effect on browsing — a visitor's browser never reads your CAA record. Tightening or removing a CAA record changes who can issue future certificates, not the validity of ones already out there.

CAA also complements, but does not replace, DNSSEC. CAA constrains which CA may issue; DNSSEC lets resolvers verify that your DNS answers — including your CAA records themselves — are authentic and unmodified. Because a CA reads CAA over DNS, signing your zone with DNSSEC makes the CAA check more trustworthy. They sit at different layers and are best used together.

To see a domain's CAA records, use the DNS lookup tool on who.is: enter the domain and look for its CAA entries to confirm which authorities are authorized (and whether any record exists at all). It's also worth reviewing the domain's WHOIS data to know who operates it.