CAA Records: Who May Issue Your Certificates

By Bill Hartzer, domain name expert and expert witness·August 10, 2026

What a CAA record does

A CAA record is a DNS entry that names which certificate authorities — the organizations browsers trust to issue TLS certificates — are permitted to issue certificates for your domain. RFC 8659 frames it as letting a domain holder "specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name," so that CAs can implement "additional controls reducing unintended certificate issuance risks."

Note the word unintended. It is in the RFC's own framing and it is the honest boundary of the control. CAA is a policy signal to compliant certificate authorities. It is not a cryptographic barrier. It does not stop a CA that ignores the record, it does not revoke certificates that already exist, and it does nothing about a certificate issued last year by a CA you have since removed from the list. What it does is close off the easy path: an attacker who has enough control to request a certificate for your name from an arbitrary CA finds that most of them are obliged to say no.

That matters because obtaining a valid certificate is a standard step in a serious domain attack, not an afterthought. CISA's Emergency Directive 19-01 of 22 January 2019 described an active campaign whose chain ran in three stages: compromising credentials of an account that can change DNS records, altering those records to redirect traffic, and "obtaining valid encryption certificates for an organization's domain names." CAA constrains the third stage.

The three property tags

A CAA record carries a property tag — the keyword that says what the record is asserting — and a value. RFC 8659 defines three.

issue authorizes a named CA to issue ordinary certificates for the name.
issuewild authorizes a named CA to issue wildcard certificates, meaning a single certificate covering *.example.com, and it takes precedence over issue for wildcard requests.
iodef gives a reporting endpoint — a mailto, http or https URL — at which a CA can report an attempted violation.

To forbid all issuance, the RFC provides for an issue property tag with no issuer domain name at all; its own example is nocerts.example.com CAA 0 issue ";". That is a useful and underused setting for names that will never legitimately carry a certificate — parked domains, defensive registrations, typo variants of a live brand — because those are exactly the names nobody is watching.

The iodef tag is worth setting only if someone reads the mailbox. An unmonitored reporting address is indistinguishable from no reporting address, except that it looks like diligence.

Tree climbing, and why the first record set wins

The set a CA acts on is what RFC 8659 calls the Relevant RRset: the set of CAA records produced by applying the standard's search algorithm to a specific name. The search is a climb. "The search for a CAA RRset climbs the DNS name tree from the specified label up to, but not including, the DNS root '.' until a CAA RRset is found."

Processing stops at the first level that has any CAA records. This is the part that surprises people, and it produces real outages. A CAA set at example.com covers www.example.com — unless www has CAA records of its own, in which case those replace the parent's outright rather than adding to them. Publish a single-CA record on a subdomain and you have not narrowed the parent's list for that subdomain; you have discarded it. Every CA you left out at the apex is now refused for that name.

RFC 8659 replaced RFC 6844 largely to simplify this algorithm. The older version processed CNAME and DNAME records inefficiently during the climb; the current one "only performs tree-climbing on the FQDN being processed." Tooling written against the older behavior may not describe what CAs actually do today.

Enforcement lives in the Baseline Requirements, not the RFC

An RFC defines a record format. It does not oblige anyone to obey it. What makes CAA operative is the CA/Browser Forum Baseline Requirements, the rules publicly trusted certificate authorities are audited against. Ballot 187 added section 3.2.2.8, requiring CAs to check CAA at issuance and to honor the issue, issuewild and iodef tags. The text is explicit that "this section is effective as of 8 September 2017."

The check carries a freshness window rather than being instantaneous: if the CA issues, it must do so "within the TTL of the CAA record, or 8 hours, whichever is greater." The practical implication is a lag. Change your CAA record to remove a CA and an issuance request already validated against the old record can still complete inside that window. If you are removing a CA because you suspect something is wrong, treat the record change as the beginning of the response and not the end of it.

Why CAA without DNSSEC is weaker than it looks

The Baseline Requirements allow a CA to treat a failed CAA lookup as permission to issue, but only when three conditions all hold: the failure is outside the CA's own infrastructure, the lookup was retried at least once, and "the domain's zone does not have a DNSSEC validation chain to the ICANN root."

Read the third condition carefully, because it is the whole argument for pairing the two controls. If your zone is unsigned, an attacker who can suppress or spoof the CAA lookup engineers exactly the failure the exception covers, and the CA may issue anyway. If your zone is signed and anchored, that route closes: an unanswered lookup is not the same thing as an absent record. DNSSEC is what makes the absence of a CAA record authoritative.

This is also the reason CAA is a weaker control than its placement in the stack suggests. It lives entirely in your zone file, with no registry or registrar involvement, which is convenient — and means that anyone who controls your DNS can rewrite it. An attacker who has already taken your DNS can add himself to the list before requesting a certificate.

Common mistakes

Publishing CAA and forgetting the CA that the hosting provider, CDN or email vendor uses, then discovering it at renewal when issuance silently fails.
Setting CAA on a subdomain and assuming it adds to the parent's list. It does not; the first RRset found in the climb wins outright.
Omitting issuewild when the certificate is a wildcard, so an issue-only record blocks a wildcard renewal.
Getting the issuer string wrong. The value is the CA's documented identifier, not its brand name or its website.
Treating CAA as a substitute for certificate monitoring. It constrains future issuance by compliant CAs, tells you nothing about certificates already issued, and raises no alert on its own unless iodef is set and read.
Deploying CAA on an unsigned zone and assuming it is enforceable, when the lookup-failure exception turns on exactly that.

What good practice looks like

Inventory every certificate you actually hold and every automated issuer — ACME clients, CDN, load balancer, mail gateway — before publishing anything. ACME is the automated protocol used by Let's Encrypt and others to request certificates without a human, and it is usually the issuer people forget.
Publish issue for each authorized CA, publish issuewild explicitly if wildcards are in use, and point iodef at a mailbox somebody monitors.
For high-value names, pin issuance to a single ACME account using the accounturi parameter from RFC 8657, so that a compromise of a different account at the same CA does not qualify.
Pair CAA with DNSSEC so that a suppressed lookup cannot be read as permission.
Pair CAA with Certificate Transparency monitoring — the public append-only logs of issued certificates — which catches the issuance that CAA did not prevent.
Change CAA before a CA migration rather than during it, and allow for the freshness window.

Prevention and detection are different jobs

CAA is a prevention control with no visibility, and Certificate Transparency is a detection control with no authority. Neither substitutes for the other, and the failure I see most often is treating the first as though it were both.

A CAA record that has been in place for a year gives you no evidence that it has ever refused anything, because a compliant CA that declines to issue is silent unless you set iodef. Meanwhile a certificate issued before the record existed, or by a CA that ignored it, or by a CA an attacker added to the list after taking your DNS, appears in the CT logs within a short window and is searchable by anyone. Watching those logs for your apex and your wildcards is the part that tells you something happened. CAA is the part that makes it harder to happen. Deploy both, and monitor the one that talks.

Frequently Asked Questions

Does a CAA record stop anyone from getting a certificate for my domain?

It stops compliant certificate authorities from issuing when they are not on your list, which is most of the publicly trusted ones, because checking CAA has been mandatory under the CA/Browser Forum Baseline Requirements since 8 September 2017. It does not stop a CA that ignores the record, it does not revoke certificates that already exist, and it does not help against an attacker who already controls your DNS and can simply add himself to the list. RFC 8659 describes the goal as reducing unintended issuance, and that is an accurate description of the scope.

Will a CAA record on my subdomain add to the one on my main domain?

No, and assuming otherwise is the most common way CAA breaks a renewal. A CA searching for CAA records climbs the DNS tree from the name it is checking upward, and stops at the first level that has any CAA records at all. Records at that level replace the parent's rather than combining with them. If your apex authorizes three CAs and you publish a record naming one CA on a subdomain, the other two are now refused for that subdomain. Publish the complete list at every level where you publish anything.

Do I need DNSSEC for CAA to work?

CAA functions without it, but it is materially weaker. The Baseline Requirements permit a CA to treat a failed CAA lookup as permission to issue when the failure is outside the CA's infrastructure, the lookup was retried at least once, and the domain's zone has no DNSSEC validation chain to the ICANN root. On an unsigned zone, an attacker who can suppress or spoof the lookup can manufacture that condition. On a signed zone, an unanswered lookup cannot be read as an absent record.

How quickly does a CAA change take effect?

Not instantly. Under the Baseline Requirements, a CA that has completed a successful CAA check must issue within the TTL of the CAA record or 8 hours, whichever is greater. An issuance request validated against your old record can therefore still complete inside that window after you have changed it. Plan CAA changes ahead of a CA migration rather than during one, and if you are removing a CA in response to a suspected problem, treat the record change as the first step rather than the remedy.

What CAA record blocks all certificate issuance?

RFC 8659 provides for an issue property tag with no issuer domain name, which requests that no issuance occur at all. The standard's own example is a record of the form CAA 0 issue ";" on the name in question. This is worth considering for names that should never carry a certificate: parked domains, defensive registrations, and typo variants of a live brand. Those names attract attention precisely because nobody is watching them, and a certificate issued for one is a plausible step toward a convincing phishing site.

Does CAA tell me when someone tries to get a certificate?

Only if you set the iodef property tag to a reporting endpoint, and only to the extent a given CA reports to it. CAA raises no alarm on its own; a compliant CA that refuses to issue is silent. Detection is a separate job, done by monitoring Certificate Transparency logs, which record publicly trusted certificates as they are issued and are searchable by anyone. CT catches what CAA did not prevent, including issuance that predates your record and issuance by a CA that disregarded it.

Which CAs should I list in my CAA record?

The ones you actually use, which is usually more than the ones you think you use. Before publishing anything, inventory every certificate you hold and every automated issuer in the environment: ACME clients on servers, the CDN, the load balancer, the mail gateway, and any managed platform that provisions certificates for you. Each CA publishes the identifier string that belongs in the record, and it is that documented identifier rather than the brand name. Getting the string wrong produces the same outcome as omitting the CA entirely.

CAA Records