CAA records explained

What CAA is for

There are many publicly trusted certificate authorities, and browsers trust a certificate from any of them equally. Each authority has its own way of checking that the person requesting a certificate controls the domain. If any one of those checks can be fooled, for example through a hijacked DNS record or a compromised mailbox, a certificate can be issued for your domain without your knowledge.

Certification Authority Authorization, defined in RFC 8659, lets a domain owner publish in DNS which authorities are permitted to issue. Authorities are required by the industry's baseline rules to check for a CAA record immediately before issuing, and to refuse if they are not listed. It does not make validation stronger at the authorities you allow; it removes all the others from the picture.

What a record looks like

A CAA record has three parts: a flags number, a tag and a value. The flags are almost always 0. The tag says what kind of statement the record makes, and the value is usually the domain name by which an authority identifies itself. Each authority publishes the name to use in its own documentation.

A domain may have several CAA records. Together they form the list. An authority may issue if it appears in any record with the relevant tag.

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

The three tags

The issue tag authorises an authority to issue certificates for the name. If no issuewild record exists, it also covers wildcard certificates.

The issuewild tag applies only to wildcard certificates. When at least one issuewild record is present, wildcard requests are judged by issuewild records alone and issue records are ignored for them. This lets you allow ordinary certificates from two authorities and wildcard certificates from only one, or from none.

The iodef tag gives an address where an authority may report a request that was refused because of the policy. Not every authority sends such reports, so it is useful where supported and not a monitoring system by itself.

Forbidding issuance

A value consisting of a single semicolon means that no authority is authorised. It is used for domains that should never have a certificate, and for forbidding wildcards specifically while allowing ordinary certificates.

; No authority may issue for this domain
parked-example.org.  CAA  0 issue ";"

; One authority for normal certificates, wildcards forbidden
example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issuewild ";"

How an authority looks the record up

The lookup does not stop at the exact name. An authority asked for a certificate for shop.eu.example.com first looks for CAA records at that name. If there are none, it looks at eu.example.com, then at example.com, and continues upward. The first name that has any CAA record decides the matter, and the search stops there.

Two consequences follow. A record on the main domain covers every subdomain that has no record of its own, so a single record protects the whole domain. And a subdomain can have a different policy simply by publishing its own records, which replace the parent's entirely rather than adding to them.

If a name is a CNAME, the authority follows it and checks the target as well. A subdomain that points to a hosting platform may therefore be subject to that platform's CAA records.

example.com.       CAA  0 issue "sectigo.com"
shop.example.com.  CAA  0 issue "letsencrypt.org"

Finding out which authorities you use

The risk in adding a CAA record is leaving out an authority that something depends on. Before publishing, find every authority that currently issues for the domain. Certificates are requested not only by you but by services acting for you: a CDN, a website builder, a load balancer, an email marketing platform that serves tracking links on your subdomain.

1. Search certificate transparency logs for the domain and list the issuers of every certificate from the past year.
2. Read the issuer of the certificate currently served on each hostname.
3. Check the documentation of each hosting, CDN and SaaS platform that serves content on one of your subdomains for the authorities it uses. Some use more than one and switch between them.
4. Ask whoever manages mail servers, VPN gateways and internal tools which authority their certificates come from.

dig example.com CAA +short
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer

Adding a record safely

With the list in hand, publishing is straightforward.

1. Write one issue record for each authority on the list, using the identifier that authority documents.
2. Decide about wildcards. If you do not use wildcard certificates, forbid them with an issuewild record containing a semicolon.
3. Add an iodef record with a monitored address.
4. Publish the records on the organisational domain.
5. Read them back from public DNS.
6. Trigger a test renewal on a non-critical hostname, or run the ACME client's dry run, to confirm issuance still works.
7. Watch the next real renewal on each platform.

How CAA breaks renewals

CAA is checked every time a certificate is issued, including every renewal. A record that was correct when it was written starts causing failures when something changes around it. The team moves to a different authority and nobody updates the record. A hosting platform changes the authority it uses. A new service is adopted that issues its own certificates for a subdomain.

The failure is quiet. The existing certificate keeps working until it expires, and the renewal error appears only in the ACME client's log or the platform's dashboard. This is one of the reasons to monitor certificate expiry from outside: the first visible symptom of a CAA problem is a certificate that did not renew.

A DNS failure can have the same effect. If an authority cannot get a definite answer to its CAA lookup, for example because the nameservers time out or DNSSEC validation fails, it must treat the result as a failure and refuse to issue.

Restricting to an account or validation method

Naming an authority allows any of its customers to request a certificate for your domain, provided they pass validation. An extension defined in RFC 8657 narrows this further with parameters added to the value. The accounturi parameter restricts issuance to one specific account at the authority, and the validationmethods parameter restricts which validation methods may be used.

Support depends on the authority. Where it is available, account binding is a strong control, because a third party who gains temporary control of a DNS record or a web path still cannot obtain a certificate from their own account. It also adds one more thing to update if the account ever changes.

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

A worked example for a typical small business

Consider a company whose website is on a hosting platform that issues certificates from one authority, whose shop runs on a SaaS platform using a second authority, and which uses no wildcard certificates. The inventory gives two authorities. The policy lists both for ordinary certificates, forbids wildcards, and names a mailbox for reports.

If the shop platform later announces that it is adding a backup authority, the record needs a third issue line before the platform starts using it. Subscribing to the platform's change notices is part of maintaining the record. A platform that changes authority without your record being updated will fail to renew, and the shop's certificate will run out on its normal schedule.

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issue "pki.goog"
example.com.  CAA  0 issuewild ";"
example.com.  CAA  0 iodef "mailto:security@example.com"

What CAA does not do

CAA is checked by certificate authorities at the moment of issuance and by nobody else. Browsers do not look at it. A certificate that was issued before the record existed, or issued in breach of it, is not rejected by any client because of CAA. It is a preventive control, not a detective one.

It also does not help against someone who controls your DNS, since they can change the CAA record along with everything else. DNSSEC makes the record harder to forge in transit, and registrar security protects the zone itself. To detect certificates you did not expect, watch certificate transparency logs; CAA and transparency monitoring cover different halves of the problem.

Checking a domain

A useful check answers three questions: is there a CAA policy for this name, which name does it come from, and which authorities does it allow for ordinary and wildcard certificates. The CloudSpex CAA Record Checker reads the records the way an authority would, including the climb to the parent domain, and reports the effective policy. It does not request certificates, so it cannot confirm that a particular authority's own account checks will pass.